[Aboriginal] GCC - messed up search dirs

[Rob Landley]

On 01/21/2012 02:28 PM, Paul Onyschuk wrote:
> First a bit of the background (apologies for my poor english writing).
> I'm trying to bootstrap pkgsrc under chrooted Aboriginal Linux.

What... ah, you mentioned the version and target info at the end of the
message, got it.

>  That
> should be pretty easy, beside chroot image pkgsrc needed also zlib,
> ncurses and groff (I used mdocml instead).

The static-tools.hdc native build does zlib, the bootstrap-gentoo.hdc
does ncurses, and the lfs bootstrap does groff.  So all of those have
built under aboriginal before.

>  Small fix in bootstrap
> script was also needed: busybox awk fails at some point, so pkgsrc
> should build own version (nawk).

Which bootstrap script?  (When you chrooted, did you run /sbin/init.sh
to enter the chroot?)

Fails how?  I've built the whole of linux from scratch under a chrooted
aboriginal linux, using the above hdc builds.  (All of them are at
http://landley.net/aboriginal/control-images).

> Problems starts here, C preprocessor fails on conftest.c in one of the
> packages (bmake):

I presume you're referring to:

  http://www.linuxfromscratch.org/hints/downloads/files/bmake.txt

>> cpp: error trying to exec 'cc1': execvp: No such file or directory

Oh right, I forgot to wrap the preprocessor with ccwrap.c (all the Linux
stuff just uses "gcc -E" instead of ever calling cpp).  The easy thing
to do is replace cpp with a shell script:

  #!/bin/bash

  gcc -E "$@"

(I have no idea why the preprocessor would try to execute cc1, but ok.)

> As it turns out GCC cannot point to proper cc1 location:

I use a wrapper binary that takes all the path logic decisions out of
gcc's hands, adjusting the $PATH and rewriting the gcc command line to
start with --nostdinc --nostdlib and then adding -I and -L for
everywhere it should look, explicitly.

However, cpp != gcc.

>> $ gcc -print-search-dirs
>> install: /usr/bin/../
>> programs: /usr/bin:/usr/bin/../tools/bin:/usr/kerberos/sbin: \
>>   /usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin
>> libraries: /usr/bin/../cc/lib/:/usr/bin/../lib/:/usr/bin/../cc/
>>
>> $ gcc -print-prog-name=cc1
>> cc1
>>
> 
> 
> This can be fixed by setting:
> 
>> $ export GCC_EXEC_PREFIX=/usr/i586-unknown-linux/bin/

That's going behind the wrapper's back and telling gcc explicitly where
to look at stuff.  That works, but there's a dozen things you need to
adjust and many of them are conditional on what you're trying to do.

Bascially, I got the toolchain to work portably as a cross compiler
(from wherever it's currently installed) by using the wrapper, and then
I just did the same thing for the native toolchain.  Mostly it just
works and you don't have to pay attention to it, but I missed wrapping
the cpp binary because nothing in Linux ever seems to use it.

My bad.

> In the end, others problems are showing up (still regarding C
> preprocessor) like missing limits.h header.

This is honestly the first time in several years I've encountered
something using cpp (apparently bsd uses it but linux doesn't), but I'll
fix it now it's pointed out.

I'll take a stab at this tomorrow and check it into the repo.  Either
the above wrapper script to use gcc -E for cpp, or by applying ccwrap.c
to the cpp binary.

> I don't like idea of
> adding another few environment variables just to point GCC to own files.

Neither did I.

I spent a long time trying to fix gcc's path logic.  The only way to fix
it is to RIP IT OUT ENTIRELY, and that was over a 10,000 line patch.

> I'm using root-filesystem-i586 image [1] and the questions are:
> 
> (A) Am I doing something wrong (chroot setup and so on)?
> (B) Are additional setps needed before using GCC under Aboriginal?
> (C) Is there something wrong with GCC under Aboriginal?

The answer is C) something finally used the cpp binary, which I forgot
to wrap.  My bad.  (I acually encountered in this in 2009 and put it on
my todo list, but I forgot I hadn't actually done it yet.  And I only
noticed because I was playing with a compiler other than gcc, not
because a package used it...)

Rob

 1327204578.0