GCC 4.1.1 and glibc 2.4 stable on x86 and amd64

[Pajarico]

(Nevermind)

[Polynomial-C]

Hi,

If you don't but are aware what's possibly going to happen, give it a try.

Yeah, I know what could happen and I won't blame anybody else than myself if something fails. I'm at emerge -e system on two machines right now and everything seems to work.

Cheers
Poly-C

[Polynomial-C]

I did emerge -e system and then world, and many (all?) of the packages of system are being emerged again with world. Is that normal?

yes, it's normal that all packages from system get recompiled in world, too. I think this is even wanted in case of a gcc-upgrade because this way your toolchain should be sane (means everything was compiled with the same set of tools which were compiled with the same compiler).

Cheers
Poly-C

[swimmer]

For those of you who don't want to compile packages more than once run:

Code: Select all

# emerge -pe system | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/.*/=\0/" > system.list
# emerge -pe world | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/.*/=\0/" | grep -vFf system.list > world.list
# emerge --oneshot --nodeps `cat system.list world.list`

[...]

I'm afraid you forgot

Code: Select all

sed "s/LINGUAS.*//"

in the chain :-/

Amne: does it any harm if you don't compile those packages twice? I mean - it is still a complete 'emerge -e' of system & world ...

Greetz
swimmer

[Pajarico]

I did emerge -e system and then world, and many (all?) of the packages of system are being emerged again with world. Is that normal?

yes, it's normal that all packages from system get recompiled in world, too. I think this is even wanted in case of a gcc-upgrade because this way your toolchain should be sane (means everything was compiled with the same set of tools which were compiled with the same compiler).

Cheers
Poly-C

Thanks. I had this thread open in a window and didn't update it in a few hours, so I didn't see previous responses about the issue.

[Orific]

Code: Select all

# emerge -e system
# emerge -e world

will compile many packages twice which is a complete waste of time.

For those of you who don't want to compile packages more than once run:

Code: Select all

# emerge -pe system | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/.*/=\0/" > system.list
# emerge -pe world | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/.*/=\0/" | grep -vFf system.list > world.list
# emerge --oneshot --nodeps `cat system.list world.list`

On my desktop, this saves me double compilation of over 100 packages.

Cheers,
Barnoid

It does not work very well for me. It leaves a bracket "]" after the "=" sign:

Code: Select all

# less system.list
=] sys-libs/zlib-1.2.3
=] sys-libs/gpm-1.20.1-r5
=] sys-libs/ncurses-5.5-r2
=] app-shells/bash-3.1_p16
= ] sys-libs/readline-5.1_p4
= ] virtual/libiconv-0
...

[Polynomial-C]

Hi,

woah... I just ran genlop -t gcc and this is the result:

Code: Select all

     Tue Apr 18 13:51:31 2006 >>> sys-devel/gcc-3.4.6-r1
       merge time: 21 minutes and 45 seconds.

     Thu Aug 31 12:18:39 2006 >>> sys-devel/gcc-4.1.1
       merge time: 1 hour, 1 minute and 2 seconds.

So can someone tell me which ${superpowers} gcc-4.1.1 has that requires such an increase in compiletime?

Cheers
Poly-C

[amne]

Amne: does it any harm if you don't compile those packages twice? I mean - it is still a complete 'emerge -e' of system & world ...

No one will be able to tell you for sure, so i'll just link to wolf31o2's post again.

[Orific]

I did emerge -e system and then world, and many (all?) of the packages of system are being emerged again with world. Is that normal?

yes, it's normal that all packages from system get recompiled in world, too. I think this is even wanted in case of a gcc-upgrade because this way your toolchain should be sane (means everything was compiled with the same set of tools which were compiled with the same compiler).

Cheers
Poly-C

OK It is good to have a sane toolchain for compiling world, but are the recompilations necessary ?

[amne]

OK It is good to have a sane toolchain for compiling world, but are the recompilations necessary ?

Yes.

[chrysler]

is the ebuild using the distcc feature for compiling gcc?

[Weedman]

I was soo happy...then All of a sudden:

Code: Select all

glibc-2.4 is nptl-only!
NPTL requires a CHOST of i486 or better

I discover that I need to add the "nptl" and "nptlonly" use flags to make.conf. Fair enough, easy as pie!

But it still bums out. The same error message.

Thanks to google, I discovered that nptl isn't available for systems with the CHOST set below i486. Mines set to i386!

What am I going to do?

Research showed a total recompile was nes. But what are the steps, considering this isn't an everyday "emerge -e world".
Would something like this make sense?

Code: Select all

emerge gcc glibc
emerge -e system
emerge -e world

Is there anything else that I would need to do before or after the "emerge -e"'s?

Thanks,

weed

[psic]

Hi, weedman, the same thing happened to me, basically, I edited the make.conf, re-emerged gcc, followed all of the steps in the upgrade guide (the gcc-config, the source /etc/profile, etc.), and am now running 'emerge -ev sistem', which is (so far) going well.

[amne]

Would something like this make sense?

Code: Select all

emerge gcc glibc
emerge -e system
emerge -e world

Changing CHOST can be a bit troublesome, but i hope/assume that should work fine.

[Headrush]

Is it safe to assume that the stage tarballs for 2006.1 I see on the mirrors has been compiled with gcc-4.1.1?

[Weedman]

Hi, weedman, the same thing happened to me, basically, I edited the make.conf, re-emerged gcc, followed all of the steps in the upgrade guide (the gcc-config, the source /etc/profile, etc.), and am now running 'emerge -ev sistem', which is (so far) going well.

So you edited the CHOST setting? I just had to clarify that.

In all of my n00bish moments, I am having one right now. The system in question in an AMD Sempron laptop. Should I switch to i686? I am almost certain I should....

Changing CHOST can be a bit troublesome, but i hope/assume that should work fine.

Thanks. This is my first time at doing something like this (as in involved, and serious), even if I have used Gentoo since late last year.

I'll probably leave it compiling overnight. It's 10 to 12 here in Australia.

Thanks for your super quick replys!

weed

[Orific]

OK It is good to have a sane toolchain for compiling world, but are the recompilations necessary ?

Yes.

OK. But it is frustrating for people with slow machines (like me ). Barnoid's idea interested me very much.

Changing CHOST can be a bit troublesome, but i hope/assume that should work fine.

I agree with the troublesome part... I did it once, without problems, but it is better to take a look at this post before.

[Dominique_71]

Is it safe to assume that the stage tarballs for 2006.1 I see on the mirrors has been compiled with gcc-4.1.1?

Code: Select all

gcc --ver

will show you which version it is.

EDIT: It is gcc-4.1.1

[Barnoid]

@Orific:

It does not work very well for me. It leaves a bracket "]" after the "=" sign:

Code: Select all

# less system.list
=] sys-libs/zlib-1.2.3
=] sys-libs/gpm-1.20.1-r5
=] sys-libs/ncurses-5.5-r2
=] app-shells/bash-3.1_p16
= ] sys-libs/readline-5.1_p4
= ] virtual/libiconv-0
...

hmm.., then your emerge -p format differs. Simply cut away two more columns (i.e. 'colrm 1 18' instead of 'colrm 1 16'), and you should be fine.
As swimmer pointed out, you should also remove any 'LINGUAS=...' strings, so

Code: Select all

# emerge -pe system | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/LINGUAS.*//" | sed "s/.*/=\0/" > system.list
# emerge -pe world | grep "^\[ebuild .*" | colrm 1 16 | sed "s/\[.*//" | sed "s/USE.*//" | sed "s/LINGUAS.*//" | sed "s/.*/=\0/" | grep -vFf system.list > world.list
# emerge --oneshot --nodeps `cat system.list world.list`

(You'll still need to modify the 'colrm')

Be aware that some say not compiling the left-out packages twice is not safe. I hadn't had any problems neither with the gcc 3.3 -> 3.4 nor the 3.4 -> 4.1 transition, though.

[Gergan Penkov]

this was posted on gentoo-amd64 some time ago, I don't know who the author is, but:

Code: Select all

emerge -ep world|cut -d] -f2|cut -d" " -f2|grep /|sed -e s/^/=/ > pkglst

but as it was stated it is strongly recommended to emerge -e system && emerge -e world and not to take shortcuts, as it ensures that the toolchain is sane, the problem is with the order in which certain packages get emerged from portage and that there are circular dependancies between the toolchain packages (at least in order to enable certain features in them for example).

[Smoothhound]

For those wondering about the rationale behind the recommendations for redundant system & world rebuilds check out this thread and perhaps use hielvc's excellent emwrap.sh script to get the most stable system with the minimum number of compiles.

[JohnerH]

I had a moment of noobishness...

CCACHE.... We have to reset it right?

I seem to recall that after each gcc version upgrade I had to reset it.

Thanks in advance,

J

[gian]

I have a simple and rather direct question: I use a commercial application (whose name I avoid here, and... no, it is not possible to ask them to change their code...) that works only if I

setenv LD_ASSUME_KERNEL 2.4.1

in this case I get

Code: Select all

gian@mir> ldd /..../myapplication.exe
        linux-gate.so.1 =>  (0xffffe000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0xb7f3e000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e4f000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7e41000)
        libg2c.so.0 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libg2c.so.0 (0xb7e1e000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7e1a000)
        libm.so.6 => /lib/libm.so.6 (0xb7df8000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb7de3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7d91000)
        librt.so.1 => /lib/librt.so.1 (0xb7d7d000)
        libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0xb7cc7000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 (0xb7cbe000)
        libc.so.6 => /lib/libc.so.6 (0xb7ba8000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb7b9f000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb7b87000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b84000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7b7e000)
        /lib/ld-linux.so.2 (0xb7fb1000)

and myapplication works properly, if I do not set the LD_ASSUME_KERNEL my application simply aborts with the well known

Code: Select all

gian@mir> myapplication.exe
/.../myapplication.exe: relocation error: /.../myapplication.exe: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

and ldd tells me, as it is obvious, that the libs in /usr/tls are being used in this case;

My question

Does this mean that if I want to keep using myapplication as I'm doing now I must not upgrade to the new glibc ? (or, equivalently, must absolutely change to the hardened or no-nptl profile...?)

This would be quite sad since I want to use both NPTL applications... but also myapplication and possibly for a long time...

[massimo71]

I have my best machine already on gcc 4.11 (xeon 3.0 2gb ram raid 5)

now i want upgrade other gentoo pc. (pIII pIV etc)

So my question is :
i can abilitate distcc after switch to new gcc for speed up ?

like here :

> ** distcc disable **
> emerge -uav gcc
> gcc-config i686-pc-linux-gnu-4.1.1
> source /etc/porfile
> fix_libtool_files.sh 3.4.6
> emerge --oneshot -av libtool
> ** distcc enable **
> emerge -eav system
> emerge -eav world


Thanks.

[Smoothhound]

I had a moment of noobishness...

CCACHE.... We have to reset it right?

I seem to recall that after each gcc version upgrade I had to reset it.

Thanks in advance,

J

No you don't have to clear CCACHE, the cached code is indexed by (amongst other things) the timestamp of the complier binary

Edit: typo