Hi,
I'm currently evaluating s6 in a series of init/supervision suites.
Finally I stumbled over a very naive ./configure which misses:
* tell exactly what it does and which failure it stumbles
* externally override bogus (from target perspective) settings
*
https://skarnet.org/software/skalibs/crosscompile.html
I did a few talks regarding how to write configure stage checks,
and one rule I always try to transport:
==> DO NOT RUN CREATED ARTIFACTS <==
When you want to know a value (e.g. definition of __BYTE_ORDER, use
a test whether ((__BYTE_ORDER)-(__LITTLE_ENDIAN)==0), then test whether
((__BYTE_ORDER)-(__BIG_ENDIAN)==0) and so on.
When __BYTE_ORDER isn't defined, you can also assume, network byte
order is big endian (arpa/inet.h> - you require The Open Group Base
Specifications Issue 7 ^^).
So when following code compiles:
--------
#include <stdio.h>
#include <arpa/inet.h>
const unsigned long ul = 0xdeadbeefUL;
const int byte_order_is_big_endian[ul-htonl(ul)+1] = {1};
int moin(void) {
return 0;
}
--------
you're building for a big endian platform (since htonl is likely
optimized out of the way).
And if neither __BYTE_ORDER is properly defined not it's big endian,
and you're in cross compiling or shall not run for other reason,
then have a slightly bigger fallback code and determine it during
initializing the runtime once.
That's very unlikely and you can maybe use __builtin_expect(!!(x), 0) :)
Similar for nullispointer check: When you want to evaluate an vla, you
can use an array:
--------
const int prove_array[1+(int)NULL];
const int test_array[sizeof s[0]];
--------
This compile will simply fail when
https://www.openwall.com/lists/musl/2013/01/09/13 is true :)
(I tried clang on macos which let both be an integer const expression).
So - as you can see - the problem isn't the lack of autotools ability to
pass your generated code into a qemu - the lack is finding the right test.
Also: I do not see which extra information gives running trypipe2 beside a compile
test whether the function is available.
Now to "Bypassing the build-time tests"
> This is the hardest part of cross-compilation, and very few build systems get it right. (GNU autotools does not, which is one of the reasons why skarnet.org packages do not use autotools.)
>
> Native build procedures usually perform build-time tests: they compile executables and run them (on the build platform, which is the same as the target platform) to check for features and system quirks.
GNU autotools do it much better than skalibs. It supports for any check it executes
a variable 'ac_cv_$check' which can be set from outside to define exactly the result
of that check.
You can, for example, have a look at
https://github.com/libstatgrab/libstatgrab/blob/master/m4/ax_types.m4
which determines sizes and format details of everywhere else different formatted types.
I definitively know that GNU autotools are not perfect - not even close. But comparing
to all other attempts out there, they're the best on the market.
Long story short: suggesting running ./configure on any target we might want to
support with openembedded or Yocto is at the same craziness level as the Perl5
guys thought - but the did it 15 years earlier and 3 years ago they accepted
(not understand) that it was wrong.
I will be really happy adding s6 and other skaware to
https://github.com/meta-layer/meta-sysinit
to allow embedded people booting quickly and supervising their services, but out-of-the-box
cross-compiling is mandatory.
I'm happy to help, just drop a note. But mind NIH is deadly broken for configure stages :)
Cheers
--
Jens Rehsack - rehsack_at_gmail.com
Received on Fri Sep 13 2019 - 17:18:47 UTC