> Am 17.09.2019 um 20:38 schrieb Jens Rehsack <[email protected]>: > > > >> 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 ;)
BTW: It was seriously meant offering help in doing the conversion. And I have no inhibition using AC_RUN_IFELSE where necessary. But unlikely for if(pipe2(...) < 0) ... There will AC_CHECK_FUNC or maybe a AC_CHECK_DECL should do. Cheers -- Jens Rehsack - [email protected]
signature.asc
Description: Message signed with OpenPGP
