> Am 17.09.2019 um 20:11 schrieb Laurent Bercot <ska-skaware_at_skarnet.org>:
>
> 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 - rehsack_at_gmail.com
Received on Tue Sep 17 2019 - 18:38:55 UTC