[Aboriginal] Build error when system has a cross compiler already

[Rob Landley]

On 01/05/14 02:22, Bobby Bingham wrote:
> I'm running into a build error with aboriginal that seems to be related
> to the fact that I already have an SH4 cross-compiler toolchain
> installed on my system.

After host-tools.sh runs, none of the host binaries should be in the 
$PATH except 7 cherry picked native compiler binaries (which are 
symlinked from the new $PATH).

In addition, I wrap my compiler with a binary that parses the command 
line and rewrites it to start with --nostdinc --nostdlib and then 
manually adds back each build component explicitly on the command line 
so gcc doesn't do ANY SEARCH, because it's really bad at it.

It also adds the correct ld and cc1 and all that as the first entry in 
the $PATH. But of course having that be the first entry in the $PATH 
doesn't mean that gcc won't randomly flail around and find unrelated 
crap, why would I think that?

(At one point, I tried patching gcc to remove the layers of bad path 
logic they'd accumulated over time. When my patch passed 10,000 lines of 
code removed, I gave up and did the wrapper.)

> First, the error itself.  When aboriginal tries to compile the kernel:
>      sh4-ld: unrecognized option '--build-id'
 >
> Digging around in the kernel makefiles a bit, it looks like it does try
> checking if the linker supports the --build-id flag.  Looks like the
> check amounts roughly to:
>      build/simple-cross-compiler-sh4/bin/sh4-gcc -Wl,--build-id -nostdlib -x c /dev/null -o /tmp/foo
 >
> Which on my system produces this output:
>      /usr/libexec/gcc/sh-superh-linux/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000d8
>
> Note the path to ld -- the sh4-gcc built by aboriginal is apparently
> running the SH4 linker I have installed on my system, which is from
> binutils 2.24, which supports the --build-id option.  That explains why
> the kernel thinks the linker supports it.

And it found a binary that's not in the $PATH at runtime. How? It's not 
in the $PATH when simple-cross-compiler.sh runs, is it? Because 
host-tools.sh ran already and populated build/host and the next script's 
include.sh should see that and trim the $PATH to point _just_ to that...

Right, obviously I'm not currenty reproducing this here. Where did you 
get this toolchain? I have no idea how to reproduce it?

My first wild guess at fixing it would be the attached file. Put it in 
"sources/patches" and see if that fixes it? But... how would it find it 
there either? (How does gcc know this binary exists in the first place?) 
All I know about that patch it didn't _break_ anything obvious in my 
build...

Another potential fix would be to tell it to make the second stage cross 
compiler, which it does with the original $PATH removed. But again, if I 
don't understand what's going wrong, I have no idea if that fixes it...


> But then the kernel build
> actually uses the sh4-ld built by aboriginal to link,  and this is from
> an older version of binutils and doesn't support --build-id.
 >
> Indeed, uninstalling the SH4 toolchain on my system fixes the aboriginal
> build.  I don't have the first clue how gcc decides what linker to run,
> but I'm hoping someone here has some insight how to fix this, short of
> uninstalling my toolchain.

My ccwrap binary rewrites the kernel command line to start with 
--nostdinc --nostdlib and then manually tells it where all the headers 
and libraries live for what the rest of the command line is doing. 
(Because otherwise I couldn't _stop_ it from looking in crazy places.)

So a _third_ approach I could try is making ccwrap plug this leak. 
Except if it's a hardwired absolute path it's looking at (which is what 
that DEFAULT_CRAP did, I grepped for instances of "ld" and that looked 
most dubious), even the wrapper couldn't stop it short of ptracing the 
child process and vetoing the syscall (not going there).

Please try the patch, and if that doesn't fix it I'm going to need more 
information. (Preferably a way to reproduce it here.)

Thanks,

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-core-stopdefaults.patch
Type: text/x-patch
Size: 888 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20140105/103b28ab/attachment-0003.bin>