> Am 17.09.2019 um 20:11 schrieb Laurent Bercot <[email protected]>: > > 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.
It's a difference whether you have to run the entire configure stage for a new target on the target first or know maybe platform, cpu, library or kernel issues before and can "cache" these ;) I've chosen the examples a bit by relevance ... the question whether pipe2() is available or not can be known for the library you intend to use - regardless of the CPU type. > If there is no sysdeps database for various architectures, how does > autotools work when you do not provide appropriate ac_cv_$check > variables? As described ;) > 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. Maybe - but it's a question on maintainers effort. We(tm) at libstatgrab think, we covered most those issues - but we're happy to be told where we're wrong. > skarnet.org projects make the choice of being correct everywhere, > even if it requires more effort from the packager's part. I agree on this part. It requires the packager interaction. But not for the entire answer list, only for a few or maybe none. > 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. On this point we will always agree ;) I wouldn't take a deeper look otherwise. >> 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. It heavily depends. I say, as a packager you might know when e.g. musl does something weird and you can in case of musl defining 1..3 ac_cv_$check variables - the rest can safely be guessed. > 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 A and B are seriously no problem when the configuration script respect CPP, CPPFLAGS, CC, CFLAGS, CXX, CXXFLAGS, LD, LDFLAGS, LDDLFLAGS, CCLD, CCLDFLAGS, ... for HOST_*, BUILD_* and TARGET_* skaware doesn't - so the first failure came by not respecting --sysroot=/path/to/... options for cc and ld etc. Further, checks _tell_ (e.g. to config.log) what they do, what succeeds and what fails with what error message. It's easier to figure out what failed (the root issue, not the probe line). > 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? Yes, that is probably a real question. OTOH - why do you care? Is it, because you might call malloc(0) and the returned MULL is handled as an error? Is there a sane way to handle the memory management by not relying on that quirk? Would it be sane to just provide those sysdeps you can't probe? > 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. 8 or 9 which can be reasonable be specified on command line (not by running a configure on a existing system) is sane. That's why I suggested autoconf. By default, anything is guessed. And those which can't, can be provided by flags or ac_av_$check. Everything is logged, variables as CC, CFLAGS (sysroot etc.) are handled correctly - it's a dream for packagers ;) Cheers -- Jens Rehsack - [email protected]
signature.asc
Description: Message signed with OpenPGP
