On 9/14/2019 2:11 PM, Jens Rehsack wrote:
I don't have such a database and such a database is imposible to have.
That's a real shame, because it's the *only way* cross-compilation can ever work. You praise autotools for supporting ac_cv_$check variables, that can be supported from the outside. This is the correct mechanism indeed, and the _exact same mechanism_ skalibs uses, albeit with a different syntax. skalibs calls those variables "sysdeps". However, the difference is that skalibs forces you to provide the sysdeps for your target architecture, whereas autotools does not. If there is no sysdeps database for various architectures, how does autotools work when you do not provide appropriate ac_cv_$check variables? It guesses. That's how. And guesses can be wrong. In the absence of a sysdeps database, it is likely that a project that uses autotools will be *broken* when you cross-compile for an exotic system, because autotools will take guesses, and some of those guesses will be wrong. You *cannot* avoid this issue, no matter what build system you use. It's an inherent problem with cross-compiling. Autotools does not have divination powers, it cannot magically know the quirks of the target architecture if you don't provide them. Projects that use autotools make the choice of being buildable without much effort from the packager, at the cost of probably being buggy on lesser known systems. skarnet.org projects make the choice of being correct everywhere, even if it requires more effort from the packager's part. I want my software to be included in distributions, in Yocto, everywhere possible. I really do. But I will *not* compromise on correctness. I don't care what everyone else does, when you build skalibs, you'll have something that works, period.
This is a more or less hopeless attempt to ride a dead horse.
This horse is very much alive; and the problem of knowing the quirks of a target architecture when cross-compiling is, as of today in 2019, unsolved. You may think autotools has solved it, but that does not mean that it has. And I don't think the problem can really be solved without a sysdeps database. Now, let's be constructive and go into details. Ccing Éric Le Bihan who has done some similar work to integrate s6 to Buildroot, and I'd like his input. There are 3 ways skalibs computes sysdeps: A. a compilation test, B. a linking test, C. a running test. You can see, more or less, all the tests that skalibs does by grepping for 'choose' in the configure script. (It's a bit more complex than that because some symbols are defined in different libraries depending on the OS and the libc, and the related tests don't use the 'choose' function, but unless I'm mistaken they all fall in category B.) Case A is 'choose c', case B is 'choose cl', and case C is 'choose clr'. Case A is not a real problem for cross-compilation: it's mainly about testing whether macros are defined. All those sysdeps could arguably be replaced with #ifdef forests in the skalibs headers. I just chose to make them sysdeps instead because I dislike #ifdef forests - they slow down compilation time for *every* TU that includes headers, and they're ugly. But if case A is the only kind of sysdeps that remains, it's possible to do away with them. Case B is the majority. Unlike case A, those sysdeps need to be addressed at build time (instead of just adding logic to headers), but they're not really problematic because they only require an executable to be linked, and the result is just success/failure of the compilation+linking phase: that can be done when cross-compiling. Case C is the real issue, where testing requires building an executable *and running it* in order to know the behaviour of the target system. And that, obviously, is what can't be done when you cross-compile. skalibs doesn't have a lot of those, but unfortunately, those few are really necessary, because they're about actual behaviour of a function, and not just whether the function exists or not. For instance, how do you test whether malloc(0) returns a null pointer or not, without actually running malloc(0) on your target? With some effort on my part, the amount of sysdeps that really *need* to be manually provided could be reduced to 8 or 9; and everything else could be automatically tested. However, there will always be a few inveterates that have to be there, and we need to decide what to do with those. Guessing is not an option; but I'm open to other solutions. -- Laurent
