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

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

[Johannes Lorenz]

> Just configure, build, and install
> GCC, and programs will use its libraries.  You might need to use
> ldconfig to configure the system to use the new libaries, but this
> needs to be done with great care.  It's better to set a default
> LD_LIBRARY_PATH.

It indeed work to just use a new gcc. When compiling, it took the new libraries instead of the old ones. Compiler flags were indeed not necessary. It was sufficient to just set the LD_LIBRARY_PATH on every execution.

Thanks for the good and fast support.
-- 
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?

[Johannes Lorenz]

> I didn't say that you should compile a new glibc.  I assumed that was
> your goal.  It is an eccentric thing to be doing.

Ok, so one possibility would be to use a new gcc + ld on an old glibc, correct?

What would be the correct way to do that? If a library is found in the local installation, it was from our gcc (e.g.: ~/local/lib/gcc...), so we use it, but if it was not found, get it from the system, i.e. /usr/lib. The same for the headers. How to tell gcc to behave like that? A combination of "--sysroot" and "-L" does not seem to do the job, I think.

Many thanks on advance.

-- 
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 01:57 PM, Johannes Lorenz wrote:

> So you'd say, unlike Andrew, that I should not compile a new
> glibc. I need a new libstdc++, I hope this will be compatible with
> the old glibc.

I expect so.

> But if I really want to compile a new glibc, you think this is
> impossible/very difficult?

I didn't say that you should compile a new glibc.  I assumed that was
your goal.  It is an eccentric thing to be doing.

Andrew.

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

[Johannes Lorenz]

@Andrew:

I copied these crt*.o libraries, but now, it complains that it is missing stdio.h. I really guess it would be better to link to the whole old glibc. Is there any good trick to tell gcc: Search in your sysroot, but if you can not find it, try in "/usr/include" ? (somehow the opposite of "-I")

@Kai:

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

I don't know what you mean, but I am trying to install glibc to another "root" on the same target system. I have gcc 4.4, but want to have 4.7 (on the same target), so I tried to compile a new toolchain in ~/local, using my gcc 4.4.

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

Ok, I don't want to compile to a different target. I only mentioned openSuSE to say that the versions of binutils, gcc and glibc work on "some system". But I just want to compile on $host for $host ;) Both are Ubuntu.

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

So you'd say, unlike Andrew, that I should not compile a new glibc. I need a new libstdc++, I hope this will be compatible with the old glibc. But if I really want to compile a new glibc, you think this is impossible/very difficult?

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