Cross-compilation (was: Thank you for not using autoconf)

[Rob Landley]

On 06/10/2013 03:39:21 PM, Rich Felker wrote:
> On Fri, Jun 07, 2013 at 01:46:38PM +0200, Laurent Bercot wrote:
> > > So, basically what I'm saying is that if you need to probe  
> _behavior_
> > > of an interface, that probing should be in your application  
> itself,
> > > and it should be done when the application is run, rather than  
> being
> > > part of the application's configure process.
> >
> >  Ah, OK, now I understand your stance on the matter - but I very  
> much
> > disagree. You cannot ask applications to do run-time tests ! That is
> > totally dodging the main cross-compilation issue. Detecting
> > peculiar behaviours and making sure the application runs correctly  
> is
> > not the application's job

It's not the build's job either, it's the distribution's job to provide  
a working build environment.

> > - can you imagine the duplicated code and wasted cycles here ?

Yes, it's called "autoconf".

> > The application's job is to run, end of story.
> > Making sure it runs well on a system is clearly a job for the
> > compilation/installation process, which does require running some
> > tests, which is precisely why cross-compiling is hard.

No, http://landley.net/writing/docs/cross-compiling.html is why cross  
compiling is hard. Autoconf and libtool and other FSF brain damage are  
diseases projects catch.

> I agree with you to a point. Putting ridiculous amounts of run-time
> tests all over the place is ugly and harmful. But most of the time --
> think of the examples you cited above, like POLLHUP, pipe EOF, etc. --
> the least expensive solution is just to write your application in such
> a way that it's agnostic to the behavior that varies from system to
> system. I'm sure you can find counterexamples where relying on a
> non-portable behavior that's only detectable at runtime could give you
> major performance benefits, but I believe such cases are exceptions,
> not the typical case.

An awful lot of the time "fix your build environment" is the correct  
response. We have standards like posix and c99 now that _specify_ all  
sorts of stuff, and we have open source operating systems that can be  
_fixed_. (Even on things like android you can statically link against  
musl instead of bionic.)

90% of autoconf usage is crap like:

   http://landley.net/notes-2010.html#20-08-2010
   http://landley.net/notes-2010.html#09-08-2010
   http://landley.net/notes-2011.html#26-10-2011
   http://landley.net/notes-2011.html#06-09-2011

And there's just no excuse for that anymore. Humoring broken build  
environments (instead of forcing them to fix their breakage) just  
perpetuates the breakage. It's codependent enabling, the _opposite_ of  
helping.

If it doesn't work properly on SGI irix or DEC ultrix SCO unixware or  
Oratroll's pet OS (or the Jorg Schillinged fork thereof) this is not my  
problem. Making the common case horrible in hopes of placating some  
known-broken system that I haven't got a regression test environment  
for anyway? Not my problem. Running it on cygwin? You get to keep the  
pieces.

If all else fails, there's qemu. I'm happy to fix actual bugs, but  
special cases where your build environment is not standards compliant  
are not bugs in _my_ code.

Rob