[Aboriginal] aboriginal linux

[Rob Landley]

On 09/25/14 16:49, stephen Turner wrote:
> On Wed, Sep 24, 2014 at 11:19 PM, Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On Wed, Sep 24, 2014 at 4:55 PM, stephen Turner
>     <stephen.n.turner at gmail.com <mailto:stephen.n.turner at gmail.com>> wrote:
>     > I had no idea, not sure how i missed it either. I will join that in a bit as
>     > i'm sure there is more fun posts to follow there.
>     >
>     > Right now i think i'm having issues with my headers. I rebuilt a successful
>     > aboriginal clone (just the programs not scripts) and GCC is able to compile
>     > code but the a.out file created is unreadable to some extent as the file
>     > reports not there when you try to run it (don't you love linux saying a file
>     > cannot be found just because it cant be run when it exists and is present?)
> 
>     The file that can't be found is either the dynamic linker or the
>     program interpreter. Lemme guess: you're not using ccwrap.c.
> 
> 
> Is ccwrap.c something i need to turn on? I didnt disable it and GCC is
> in the /bin dir while i still call ./configure and while running
> ./configure i receive this output:
> 
> "configure error cannot run c compiled programs."

It's not part of gcc:

http://landley.net/hg/aboriginal/file/tip/sources/sections/ccwrap.sh

The path logic in gcc is utterly horrible. I tried fixing it properly
once but when my patch removing bad logic passed 10,000 lines I decided
I didn't want to try to maintain that. (This was before the project
switched licenses to GPLv3 and I stayed with the last GPLv2 release.)

http://landley.net/notes-2006.html#15-11-2006

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

> Now checking the config.log i see
> 
> ./conftest
> ./configure: line 3900: ./conftest: no such file or directory
>  
> For the sake of argument i decided to perform the old hello world test.c
> test. I did so and recieved a a.out file which clearly had some data in
> it. trying to run that a.out file returned the error "file not found " 
> 
> 
>     > I found a snippet on the web that when using musl libc you may need to patch
>     > the headers as well as gcc. gotta do more home work to see what needs to be
>     > done there.
> 
>     You're building with MUSL=1 ? That's still a bit buggy. I need to dig
>     into the toolchain to figure out why -Bsymbolic-functions isn't
>     reliably working. (It seems to for some symbols, but not for all.)
> 
> Im using musl 1.1.3 gcc 4.6.4 musl patched

Ah. I meant aboriginal has partial built-in musl support, which I really
need to finish soonish.

>     > I gotta say man, building a mini distro is fun even if it doesn't go
>     > mainstream! and what a learning experience!
> 
>     Long ago I gave a BOF talk about why gcc path logic sucks. It's
>     probably on http://landley.net/talks or some such.
> 
>     > If you run into any problems rebuilding your system for musl let me know, i
>     > might already know a work around.
> 
>     You know what's wrong with dynamic linking with the last GPLv2 version
>     of binutils fished out of git (between 2.17 and 2.18, just before the
>     change to the license file went in) with regard to
>     -Bsymbolic-functions? It only affects dynamic linking, not static
>     linking. Might have something to do with weak symbol binding, haven't
>     spent a weekend to track it down yet...
> 
> 
> I am trying to dynamic link, i also have binutils 2.24 and i couldnt
> find any other data on musl patching the headers which doesnt make sense
> to me. why would linux headers version 3.16 need to be musl patched?
> headers dont 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 heades. 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).

>  
> 
>     Rob
> 
>     P.S. Nobody ever wants to cc their messages to the aboriginal linux
>     mailing list. I has a sad.
> 
> 
> Fixed that for you :) no more cc

Yay!

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whack2.sh
Type: application/x-shellscript
Size: 492 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20140926/40599c4b/attachment-0002.bin>