[Aboriginal] aboriginal linux

[stephen Turner]

>
>
>
> 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
running ./configure.


>
>
> > 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
me know.

Is the regex file the patch for grep -e?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20140926/6c49666e/attachment-0002.htm>