> Am 17.09.2019 um 20:38 schrieb Jens Rehsack <rehsack_at_gmail.com>:
>
>
>
>> 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 ;)
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 - rehsack_at_gmail.com
Received on Tue Sep 17 2019 - 19:52:46 UTC