> 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 amount
> 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 specific
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
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 specific -l flags and a list of kernel issues
to a database you then read
sed 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.
&g
- 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
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 C is the real issue, where testing requires building an
executable *and running it* in ord
> Am 13.09.2019 um 23:22 schrieb Colin Booth :
>
> 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
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
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 (from target perspective) settings
* https://skarnet.org/software/skalibs/cr
11 matches
Mail list logo
