> Am 21.09.2019 um 00:22 schrieb Laurent Bercot :
>
>> What I *can* do, though, is change the skalibs build system so that
>> on cross-compilation, you only need to provide the few sysdeps that
>> cannot be probed at all.
>
> I spent today on this, and managed to bring down the necessary
> Am 18.09.2019 um 09:50 schrieb Laurent Bercot :
>
>
>>> 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 ;)
>
> You mean... like adding
The thread of cross-compile skalibs reminds me that I forget to
forward a trivial patch to fix cross-compile other packages.
Take execline for example,
package/deps.mak lists -lskarnet as a makefile dependency.
This is one of the few areas where make is architecture-dependent. It
will look up
What I *can* do, though, is change the skalibs build system so that
on cross-compilation, you only need to provide the few sysdeps that
cannot be probed at all.
I spent today on this, and managed to bring down the necessary amount
of manually provided sysdeps to one (1).
The skalibs git head
d 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, CCLDFLAG
ils 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
on+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 lo
On Fri, Sep 13, 2019 at 07:18:47PM +0200, Jens Rehsack wrote:
> Hi,
>
> I'm currently evaluating s6 in a series of init/supervision suites.
>
> Finally I stumbled over a very naive ./configure which misses:
> * tell exactly what it does and which failure it stumbles
> * externally override bogus
