[Aboriginal] aboriginal linux
stephen.n.turner at gmail.com
Fri Sep 26 09:44:22 PDT 2014
> The problem with cross compiling is not just getting it to look in the
> right place(s) but not to look in the WRONG places. If it leaks host
> headers or libraries into the target build, it can subtly break stuff.
> Getting gcc to _not_ hallucinate new paths to check is a serious
> challenge. (These days there's sysroot, which does a strncmp() on the
> start of the hardwired paths backed into the thing at build time and
> replaces the ones that match with what you fed to it in the --sysroot
> command line argument. No really, that's how they implemented it.)
Tell me about it! I have been writing down notes and on the first page in
big bold letters DO NOT USE SYSROOT!
I found shortly after getting GCC to mostly work that Sysroot did as you
say and hardcoded links to the full path! I had to recreate the
path/to/build/dir and link it to / as a temp fix. similiarly how i have
done my current system to account for the "missing" headers. That however
should be a easy fix i just need to check the documentation and find the
libdir= and includedir= etc to properly place the directories/files when
> > I am trying to dynamic link, i also have binutils 2.24 and i couldn't
> > find any other data on musl patching the headers which doesn't make sense
> > to me. why would linux headers version 3.16 need to be musl patched?
> > headers don't even deal with the libc do they?
> Headers (/usr/include/*.h files) are compile time, libraries
> (/lib/blah.so and /usr/lib/blah.*.a and so on) are link time, and in
> some cases runtime. They're separate things.
> Musl produces its own headers. You can add kernel headers to the ones it
> provides (locally I use the attached script to build new versions for
> local testing with their supplied wrapper).
I install the linux headers first and musl headers over (if any get
replaced) the kernel headers. this wont be an issue for a all musl
environment do you think? The more i learn about linux the more i realize
how little i know. This is a very good breakdown of the pages i was reading
on the topic several days ago, thanks for helping establish a clear picture
of how that works!
>I have a musl patch for the grep -e thing.
>The "rm -r dir" failure is currently being discussed on the toybox list.
>(Dalias insisted it's not a musl bug, and that the Linux man page is
>wrong. I told him to pull the other one, it's got bells on. That was on
>irc, discussion has now gone to the list...)
I'm on the toybox and musl lists as well. I've been seeing a bit of
discussion about that. I'm not familiar with posix standards yet but do
they have anything to say about the behavior of applications?
Since you bring it up, I ran into this issue just yesterday with the rm -r
dir bug. I'm using the static linked busybox and toybox binaries (toybox as
the primary, busybox for everything else) in a chroot environment with musl
libs and standard 3.16 kernel headers (with musl headers) if that helps you
with the issue at all. if there is anything i can do to narrow it down let
Is the regex file the patch for grep -e?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Aboriginal