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 - [email protected]
signature.asc
Description: Message signed with OpenPGP
