cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: cross-compiling curl for PPC -- successful but weird

From: Robert P. J. Day <rpjday_at_mindspring.com>
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