How to compile gcc toolchain with special sysroot correctly?

How to compile gcc toolchain with special sysroot correctly?

[Johannes Lorenz]

Hello,

after posting at unix.stackexchange.com [1] (where no one knew an answer), I hope it is ok if I post the question here.

I tried to install binutils, gcc and glibc. My idea was: First compile binutils, then compile a gcc which is linked with the new binutils, and finally, these two compile a new glibc (without need of my system's glibc of /usr/lib). Maybe this is conceptually wrong?

What exactly did I try? Since I can not be root, I installed it all in ~/local. First, I set these variables:

    PREFIX=~/local && export PREFIX
    PATH=~/local/bin:$PATH && export PATH

I built binutis, gcc and glibc (in exactly this order), with this configuration:

    ../binutils-2.22/configure --prefix=$PREFIX --with-sysroot
    ../gcc-4.7.3/configure --prefix=$PREFIX
    CC='gcc --sysroot=~/local' ../glibc-2.15/configure  --prefix=$PREFIX

However, after binutils and gcc were compiled and installed correctly, gcc fails to compile a simple program while configuring glibc:

    int main() { return 0; }

Output (shortened):

    > gcc --sysroot=~/local/ test.cpp -o test
    ld: cannot find crt1.o: No such file or directory
    ld: cannot find crti.o: No such file or directory
    ld: cannot find -lc
    ld: cannot find crtn.o: No such file or directory

However, this displays no files:

    find ~/local -name crti.o

Notes: My system is a server running a 64 bit Ubuntu 12.04 ("precise"), but I think it is not system related. The versions of the three toolchain components should fit each other, since openSuSE 12.2 has this combination.

Thanks very much for any replies.

Kind regards,
Johannes

[1] http://unix.stackexchange.com/questions/102511/how-to-compile-gcc-toolchain-with-special-sysroot-correctly
-- 
Diese E-Mail wurde aus dem Sicherheitsverbund E-Mail made in
Germany versendet: http://www.gmx.net/e-mail-made-in-germany

Re: How to compile gcc toolchain with special sysroot correctly?

[Andrew Haley]

On 11/27/2013 08:18 AM, Johannes Lorenz wrote:
> However, this displays no files:
> 
>     find ~/local -name crti.o

So you have to populate your sysroot with with some files and headers.
crti.o is part of glibc.

Andrew.

Aw: Re: How to compile gcc toolchain with special sysroot correctly?

[Johannes Lorenz]

> > However, this displays no files:
> > 
> >     find ~/local -name crti.o
> 
> So you have to populate your sysroot with with some files and headers.
> crti.o is part of glibc.

Ok, but the problem occured when I tried to compile glibc (it was missing it when I configured it). Do you mean I require an old glibc to compile a new one?

-- 
Diese E-Mail wurde aus dem Sicherheitsverbund E-Mail made in
Germany versendet: http://www.gmx.net/e-mail-made-in-germany

Re: Aw: Re: How to compile gcc toolchain with special sysroot correctly?

[Andrew Haley]

On 11/27/2013 09:10 AM, Johannes Lorenz wrote:
>>> However, this displays no files:
>>>
>>>     find ~/local -name crti.o
>>
>> So you have to populate your sysroot with with some files and headers.
>> crti.o is part of glibc.
> 
> Ok, but the problem occured when I tried to compile glibc (it was missing it when I configured it). Do you mean I require an old glibc to compile a new one?

Yes, you do, because the configure tests are trying to link a program.
That isn't going to work unless there is a C library.

Some circularity can't be avoided.

Andrew.

Re: How to compile gcc toolchain with special sysroot correctly?

[Kai Ruottu]

27.11.2013 10:18, Johannes Lorenz kirjoitti:

 > I tried to install binutils, gcc and glibc. My idea was: First 
compile binutils, then compile a gcc which is
 > linked with the new binutils, and finally, these two compile a new 
glibc (without need of my system's
 > glibc of /usr/lib). Maybe this is conceptually wrong?

Are you trying to build the target Linux system from scratch?  The 
produced glibc runtime parts (shared
libs) being installed onto the originally unexisting target system? If 
not then your goal is "conceptually
wrong" :(

 > Notes: My system is a server running a 64 bit Ubuntu 12.04 
("precise"), but I think it is not system related.
 > The versions of the three toolchain components should fit each other, 
since openSuSE 12.2 has this combination.

I understand this that 64 bit Ubuntu 12.0 is the $host system. But what 
the openSuSE 12.2 has to do
with this goal?

In a simple Ubuntu 12.04 to OpenSuSE 12.2 cross compiler case using a 
sysroot'ed glibc for the target system
one of course would produce only the target binutils and the target GCC 
for the $host (that usually being a
totally different arch, different CPU, and system, for instance 
Solaris2.10). And would not try to replace the
already existing target C library, here the glibc made for OpenSuSE 
12.2, but only copy it into that chosen
$sysroot.  If this isn't clear then one should ask : "Do people REALLY 
replace the target C library in native
binutils and GCC builds?"  It would sound "sane" to rebuild the system 
glibc with the updated binutils and
GCC afterwards, they are newer and should produce a better and quicker C 
library, or how?  But please
believe me, the native binutils and GCC builders don't try to replace 
the target C library in '/lib*', '/usr/lib*',
'/usr/include' etc. Neither all the X11 libraries in the system!  So why 
on earth any cross GCC builder would
do that if all the target libraries are already there, prebuilt and tested?

Generally the copied glibc should work after copying it but the sad fact 
is that those "custom"
glibcs in the current Linuces don't follow the standards used in 
building a glibc from its sources and then
installing it :(  I mean the used symlinks which should be "relative", 
pointing to '../../lib*' in the shared lib
symlinks in the 'usr/lib*', instead of this they may be "absolute", 
pointing to '/lib*' :(  Whether the linker
configured using '--with-sysroot=$sysroot' can handle these symlinks is 
unclear. My habit has been to fix
the symlinks in the target glibc if they are "nonstandard"...