[Aboriginal] aboriginal linux

[Rob Landley]

On Fri, Sep 26, 2014 at 11:44 AM, stephen Turner
<stephen.n.turner at gmail.com> wrote:
>>
>>
>> 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.

My ccwrap is a horrible solution to a horrible problem. Here's how it works:

1) Parse incoming command line. Figure out whether we're linking or
preprocessing or what, and if so whether it's static or dynamic or
what.

2) Create a new command line starting with --nostdinc --nostdlib

3) Explicitly add all the headers and paths you should be looking in.

4) If we're linking, add all the implicit libraries and .o files (like
libcrt1.o).

5) Add everything else that was on the command line back in.

Except there are ordering dependencies so the above is an
oversimplification. But that's the theory.

Even doing all that, we still need some patches so that --nostdlib
really _means_ it, most recently:

http://landley.net/hg/aboriginal/rev/ba28c96cba42

>> > 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?

Given that musl doesn't use the exported kernel headers (and
vice-versa), it shouldn't matter what order you do it in.

P.S. Don't get me _started_ on fixincludes:

http://ewontfix.com/12/

> 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 mentioned the compiler BOF I led at OLS 2008. (There is, inexplicably, video.)

(I went there to learn but everybody kept wanting me to talk instead.
I even wandered away from the front of the room and leaned against a
side wall, and the darn camera followed me...)

I tend to rant about things in passing in my blog. Alas, filtering the
wheat from the chaff there is kinda hard. The path logic stuff is
mentioned here though:

http://landley.net/notes-2009.html#21-11-2009

Oh hey, I gave a tutorial on this stuff once. I remember that!

http://landley.net/ols/ols2007/cross-compiling.html

(Google found that. I'd totally forgotten about it...)

I wonder if there was video?

A longer version of the rant I was giving about that time (which I
never cleaned up into a formal presentation or article, with the
possible exception of said tutorial) is at:

http://marc.info/?l=pcc-list&m=119189519922940&w=2

Alas, "how it should work" and "how it does work" are completely
unrelated when it comes to gcc. (Sadly, llvm is overengineered, pcc is
stalled, and I haven't had time to look at http://landley.net/qcc in
years.)

>>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?

POSIX-2008 is here:

http://pubs.opengroup.org/onlinepubs/9699919799/

(Posix-2013 is a dot release for posix-2008, the tweaks are trivial.
2001->2008 was a big deal, 2008->2013 is not.)

Note that you can (legally!) download a tarball copy for personal use from:

http://pubs.opengroup.org/onlinepubs/9699919799/download/index.html

The "utilities" subdirectory (shell and utilities in top left window,
utilities in lower left) gives you all the command line stuff, about
which I grumbled at:

http://landley.net/toybox/roadmap.html#susv4

The "system interfaces" part (system interfaces->system interfaces the
same way) lists all the libc functions and headers, that's the bit
musl uses.

There's also a bunch of stuff on shell scripting language and the
whole "base definitions" section is full of all sorts of useful random
info about environment variables and process context and so on...

The whole thing is a multi-day read, but not bad.

The other big spec is the Linux Standard Base:

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/

Which is an _appallingly_ bad standard, but it's the only thing that
even tries to define "mount", so toybox has to care about at least
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/cmdbehav.html
of it.

(I note it defines a recommended filesystem layout, which I largely
ignore. Mine was derived from an earlier version of Linux From
Scratch, which derived some of what it was doing from LSB so it's
there in the ancestry somewhere.)

But computer history is a hobby of mine, thus I tend to track down WHY
various things got done that way:

landley.net/writing/hackermonthly-issue022-pg33.pdf

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

It's that faccessat() says (in the man page) that I can feed in
AT_SYMLINK_NOFOLLOW and it works fine (albeit "is ignored") on glibc
and uclibc, but in musl they explicitly check for unknown flags and
return -EINVAL. To clarify: this owrks on _klibc_ but not in musl
because the maintainer went out of his way to break it. And when I
called him on it he said the man page should be changed to match his
opinion.

The fix I coded up that evening boiled down to adding a stanza to
portability.h something like:

#ifdef __MUSL__
// Long explanation of why musl is wrong.
#include <someheader.h>
#define faccessat(A, B, C, D) faccessat(A, B, C, 0)
#endif

And then doing an echo "#define __MUSL__" to the end of features.h
during the musl build in aboriginal. But I didn't check it in, and
since then he's posted to the toybox list. (Which you'd never know
because the web archive only updates like twice a week, I need to poke
dreamhost about that but @dreamhostcares on twitter just says to use
the web interface to open a ticket. It's on the todo list...)

> Is the regex file the patch for grep -e?

Yes. Internally grep is doing "REGEX1\|REGEX2\|REGEX3" to glue 'em
together, and tre only supported | in extended regex mode, not as an
escape in normal regex. So I fixed that.

(I'll think about writing entirely posix compliant toybox code when
somebody can tell me how to implement ps or losetup that way. Until
then, linux has man pages that say we can do things, and I believe
them.)

Rob

 1411764130.0