curl-library
Re: cross-compiling curl for PPC -- successful but weird
Date: Wed, 20 Jul 2005 13:13:41 -0400 (EDT)
On Wed, 20 Jul 2005, Tim Sneddon wrote:
> Dan Fandrich wrote:
> > On Tue, Jul 19, 2005 at 06:17:29AM -0400, Robert P. J. Day wrote:
> >
> > > i've noticed this "problem" in trying to cross-compile other programs,
> > > such as "lftp". of course, it makes sense that, if you're
> > > cross-compiling, it's pointless to be checking for file existence.
> > > but wouldn't it make more sense to just skip the check, rather than
> > > aborting the configure?
> > >
> > > "lftp" was particularly bad about this -- it simply bailed. why not
> > > something like
> > >
> > > if cross-compiling ; then
> > > echo "Skipping check for /dev/urandom, deal with it."
> > > else
> > > ... processing for /dev/urandom ...
> > > fi
> > >
> > > wouldn't that be a cleaner approach?
>
> I certainly think so.
>
> > What's the executable supposed to do when it doesn't have a random
> > device to work with? Sure, you could make it compile successfully
> > without it,
>
> Same as it would if it wasn't there due to some sort of unforseable
> error; exit gracefully with appropriate information to allow the
> user to understand what the problem is and find a solution.
personally, i think the logic for a build should take into account
what has to change when you're cross-compiling. if you're doing a
native build, of course you can do various checks for things like the
existence of special device files and bail if they're not there.
for a cross-compile, however, i'd think it makes more sense to simply
print something like:
"Warning: cross-compile build assumes the existence of /dev/blah on
the target system. That's *your* job. Movin' on ..."
or something like that.
i ran into the same annoyance with trying to cross-compile lftp.
rday
p.s. in fact, as i think more about it, it's not clear that even a
*native* build should fail for that reason. you might be building for
a similar architecture on another host, on which that device file
*does* exist.
so maybe *all* such checks should just be warnings. unless they
actually break the *build*, the build should be allowed to continue,
with warnings as to what you have to fix before actual execution.
thoughts?
Received on 2005-07-20