GCC 3.4.3 is upon us!

[black hole sun]

MOD EDIT: Stickified. --plate
MOD EDIT: Un-Stickified. --Deathwing00


Just thought I'd let you all know. It isnt OFFICIALLY released yet, but it's on the gcc FTP and it's the completely frozen RTM version

ftp://ftp.gnu.org/gnu/gcc/gcc-3.4.3/

Mainly, this is a bugfix release. GCC 3.4 is becoming very stable as of late here is the (incomplete) changelog:

Bootstrap failures

17369 [ia64] Bootstrap failure with binutils-2.15.90.0.1.1
17850 [arm-elf] bootstrap failure - libstdc++ uses strtold when undeclared

Internal compiler errors (ICEs) affecting multiple platforms

13948 (java) GCJ segmentation fault while compiling GL4Java .class files
14492 ICE in loc_descriptor_from_tree, in dwarf2out.c
16301 (c++) ICE when "strong" attribute is attached to a using directive
16566 ICE with flexible arrays
17023 ICE with nested functions in parameter declaration
17027 ICE with noreturn function in loop at -O2
17524 ICE in grokdeclarator, in cp/decl.c
17826 (c++) ICE in cp_tree_equal

C and optimization bugs

15526 (or x86?) -ftrapv aborts on 0 * (-1)
16999 #ident stopped working
17503 quadratic behaviour in invalid_mode_change_p
17581 Long long arithmetic fails inside a switch/case statement when compiled
with -O2
18129 -fwritable-strings doesn't work

C++ compiler and library bugs

10975 incorrect initial ostringstream::tellp()
11722 Unbuffered filebuf::sgetn is slow
14534 Unrecognizing static function as a template parameter when its return
value is also templated
15172 Copy constructor optimization in aggregate initialization
15786 Bad error message for frequently occuring error.
16162 Rejects valid member-template-definition
16612 empty basic_strings can't live in shared memory
16715 std::basic_iostream is instantiated when used, even though instantiations
are already contained in libstdc++
16848 code in /ext/demangle.h appears broken
17132 GCC fails to eliminate function template specialization when argument
deduction fails
17259 One more _S_leaf incorrectly qualified with _RopeRep:: in ropeimpl.h
17327 use of `enumeral_type' in template type unification
17393 "unused variable '._0'" warning with -Wall
17501 Confusion with member templates
17585 usage of unqualified name of static member from within class not allowed
17821 Poor diagnostic for using . instead of ->
17829 wrong error: call of overloaded function is ambiguous
17851 Misleading diagnostic for invalid function declarations with undeclared
types
17976 Destructor is called twice
18020 rejects valid definition of enum value in template
18093 bogus conflict in namespace aliasing
18140 C++ parser bug when using >> in templates

Fortran

17541 data statements with double precision constants fail

x86-specific

17853 -O2 ICE for MMX testcase

Sparc-specific

17245 ICE compiling gsl-1.5 statistics/lag1.c

Darwin-specific

17167 FATAL:Symbol L_foo$stub already defined.
17537 g++ not passing -lstdc++ to linker when -l is only supplied

AIX-specific

17277 could not catch an exception when specified -maix64

Solaris-specific

17505 <cmath> calls acosf(), ceilf(), and other functions missing from
system libraries

HP/UX specific:

17684 /usr/ccs/bin/ld: Can't create libgcc_s.sl

ARM-specific

17384 ICE with mode attribute on structures

MIPS-specific

17770 No NOP after LWL with -mips1

Other embedded target specific

11476 [arc-elf] gcc ICE on newlib's vfprintf.c
14064 [avr-elf] -fdata-sections triggers ICE
14678 [m68hc11-elf] gcc ICE
15583 [powerpc-rtems] powerpc-rtems lacks __USE_INIT_FINI__
15790 [i686-coff] Alignment error building gcc with i686-coff target
15886 [SH] Miscompilation with -O2 -fPIC
16884 [avr-elf] [fweb related] bug while initializing variables

Bugs relating to debugger support

13841 missing debug info for _Complex function arguments
15860 [big-endian targets] No DW_AT_location debug info is emitted for formal
arguments to a function that uses "register" qualifiers

Testsuite issues (compiler not affected)

17465 Testsuite in libffi overrides LD_LIBRARY_PATH
17469 Testsuite in libstdc++ overrides LD_LIBRARY_PATH
18138 [mips-sgi-irix6.5] libgcc_s.so.1 not found by 64-bit testsuite

documentation

15498 typo in gcc manual: non-existing locale example en_UK, should be en_GB
15747 [mips-sgi-irix5.3] /bin/sh hangs during bootstrap: document broken shell
16406 USE_LD_AS_NEEDED undocumented

[firephoto]

3.4.3 is in the portage tree for ~arch and it looks like the "f77" use flag has changed to "fortran".(?)

[firephoto]

I had a little trouble after a reboot but got KDE started again after I did a "gcc-config i686-pc-linux-gnu-3.4.3" and "fix_libtool_files.sh 3.4.2". I don't know that the fix_libtool part is needed though but I did it anyway.

[revertex]

i just emerged 3.4.3, and now i can't emerge anything.
emerge even die with all sort of errors related to gcc.
next time i've got gcc working i will build a precompiled gcc package just in case i need to downgrade but can't compile an older version.

[Deranger]

3.4.3 is in the portage tree for ~arch and it looks like the "f77" use flag has changed to "fortran".(?)

Yep, it looks like.

i just emerged 3.4.3, and now i can't emerge anything.
emerge even die with all sort of errors related to gcc.
next time i've got gcc working i will build a precompiled gcc package just in case i need to downgrade but can't compile an older version.

LiveCD is your friend

[revertex]

thanks for the tip Oktane, i already found a solution in bugzilla.
live-cd is my last resource, it's too easy to fix things this way, there is no fun!

[meabolex]

running "gcc-config i686-pc-linux-gnu-3.4.3" fixed the problem for me.

[Deranger]

running "gcc-config i686-pc-linux-gnu-3.4.3" fixed the problem for me.

Yeah, it doesn't switch automatically to 3.4.3, and because there's no 3.4.2 (or whatever you had before emerging 3.4.3), it doesn't work.

[Ruzgfpegk]

running "gcc-config i686-pc-linux-gnu-3.4.3" fixed the problem for me.

For me too.

Before doing it and after having updated GCC, I had this frightening error nearly everytime I wanted to start a program (it didn't for pySoulSeek) :

Code: Select all

error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

EDIT :
Seems like the number for this bug is 70436.

[mirko_3]

Worked fine with me, after doing a "gcc-config 3" and a "fix_libtool_files.sh 3.4.2" and finally adding GCC_SPECS="/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs" at the end of /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3 (this last one is a bug, already reported on bugzilla). Pretty smooth, all in all, other than the bug part...

[StifflerStealth]

Does anyone know if they fixed the sse2 bug for P4's in this release. I hope they do sometime, so I can use gcc 3.4.x and have sse2 optimizations.

[aderio]

Worked fine with me, after doing a "gcc-config 3" and a "fix_libtool_files.sh 3.4.2" and finally adding GCC_SPECS="/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs" at the end of /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3 (this last one is a bug, already reported on bugzilla). Pretty smooth, all in all, other than the bug part...

Done the business for me. Don't you just love the forums, just when you start to panic in with the knoppix cd - www.forums.gentoo.org - find solution - print - fix - reboot -JOB DONE.

IMHO these forums are without doubt the biggest selling point (giving away point ) of Gentoo. Hopefully M$ will not catch on

[firephoto]

I just upgraded the slower box and I had time to notice that it has a little message that says you have an existing gcc profile that is valid so it is leaving it be, but if you want to change it you can and it tells you how, then it does a fix_libtools*, then it finishes the emerge and unmerges your 3.4.2 which makes the first part invalid because it just took away your "existing gcc". This flies by so fast on the athlon64 I usually don't have a chance to even notice it or read any info notices before it removes the old version of a package.

I still have 3.3.4-r1 installed so this could be the reason it thinks I'm ok and doesn't switch to the new gcc.

[Heurisko]

here's what I posted in another thread about it:

The gcc-config fix, listed above, fixed it for me also. But, I came very close to totally dumping Gentoo because of the way portage handled this upgrade.

This is why I make this complaint:
If there is a new version of portage available to be emerged, portage itself will say that it will stop and reload itself before continuing with any other emerge requests in the current list (like if you do an emerge -Dvu world).

Why in the world (no pun intended) wouldn't the Gentoo developers make provision for the same kind of "reloading", as it were, for such major changes as gcc 3.4? It makes not sense whatsover. In fact, I couldn't even finish the emerge request that I was doing today because of this lack of forsight. (This type of change could also require user interaction before continuing with that or any other emerge slated to be completed.)

It also caused me to lose critical time today when kde wouldn't come up because of this oversight.

Really? How hard could it be to integrate that kind of stopage and warning into portage when there are such critical changes that WILL affect your system in such a dramatic way?

[HydroSan]

I nearly stabbed myself in the face when I upgraded portage and could get nothing working.

I ran gcc-config, I manually updated some configs in /etc/env.d, and ran ldconfig && env-update && source /etc/profile as many times as possible.

I downgraded GCC and plan not to upgrade until an -r1 is released to fix this.

[jefftang]

It's badly broken for me too.

I've run gcc-config and my ld.so.conf has the right directories in it, but the file just isn't anywhere to be found:

Code: Select all

# ls /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.*
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.a   /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.so
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.la
# ls /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.3/libstdc++.*
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.3/libstdc++.a   /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.3/libstdc++.so
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.3/libstdc++.la

I tried the fixtools script and re-emerging gcc 3.4.3. Is there some tool that erases/generates this library?

[Dolio]

Really? How hard could it be to integrate that kind of stopage and warning into portage when there are such critical changes that WILL affect your system in such a dramatic way?

It isn't released yet (still ~x86), so you still have time to go file a bug report and ask for appropriate handling from within the ebuild, or wherever handling would be appropriate.

The 3.4.3 ebuild seems to be slotted, so it should leave 3.3.x (or whatever) on your machine, which should leave you with a working compiler in most cases. If one has already been playing around with the 3.4 series, though, I guess it would remove that package and leave you without a compiler. However, it should be noted that you would have to be playing with experimental packages, and shouldn't really expect hand holding.

If it does, in fact, remove 3.3.x even though it's slotted, and could leave even people how aren't experimenting without a default compiler, then that is most likely a bug, and should be reported.

[Deranger]

Hmm, I just emerged GCC 3.4.3 and ran gcc-config, everything works very well. What kind of problems do you guys have?

[Grahammm]

IMHO these forums are without doubt the biggest selling point (giving away point ) of Gentoo. Hopefully M$ will not catch on

They already have, but abandoned the idea many many moons ago. The Microsoft forums on CompuServe used to be very good, but that was about 10 years ago.

[xero_cool]

The gcc-config fix, listed above, fixed it for me also. But, I came very close to totally dumping Gentoo because of the way portage handled this upgrade.

This is why I make this complaint:
If there is a new version of portage available to be emerged, portage itself will say that it will stop and reload itself before continuing with any other emerge requests in the current list (like if you do an emerge -Dvu world).

Why in the world (no pun intended) wouldn't the Gentoo developers make provision for the same kind of "reloading", as it were, for such major changes as gcc 3.4? It makes not sense whatsover. In fact, I couldn't even finish the emerge request that I was doing today because of this lack of forsight. (This type of change could also require user interaction before continuing with that or any other emerge slated to be completed.)

It also caused me to lose critical time today when kde wouldn't come up because of this oversight.

Really? How hard could it be to integrate that kind of stopage and warning into portage when there are such critical changes that WILL affect your system in such a dramatic way?

I agree that this would be a valuable "feature," but it would be quite lame to quit using Gentoo over something as trivial as that... if you're tired of fixing stuff that breaks once in awhile, then switch to arch from ~arch and most of these bugs will be fixed by the time the packages are unmasked for you.

[windzor]

[quote="firephoto"]3.4.3 is in the portage tree for ~arch and it looks like the "f77" use flag has changed to "fortran".(?)[/quote]

Its because of the comming GCC 4.0 migration to F95. Read the " f77 is now just plain old fortran in preparation for gcc4" thread on gentoo-dev@gentoo.org after further information

[jefftang]

It's badly broken for me too.

I've run gcc-config and my ld.so.conf has the right directories in it, but the file just isn't anywhere to be found.

I unmerged gcc-3.4.3 and re emerged it and that seemed to fix things.

[RumbleBot]

I don't know if this has been posted yet, but this is what worked for me.

I emergeed gcc 3.4.3, but it was still lookin for the 3.4.2 directory. I just added a symlink.

Code: Select all

cd /usr/lib/gcc/x86_64-pc-linux-gnu
ln -s 3.4.3 3.4.2

of course change x86_64-pc-linux-gnu to whatever system your running. Worked like a charm for me.

[Dark_Hunter]

correct way it works =)

1. emerge gcc
2. run

Code: Select all

gcc-config -l

The "-l" is a "L".

select the profile you want to use

3. run

Code: Select all

gcc-config NUMBER_OF_THE_PROFILE_YOU_WANT

[Brain Fury]

/me bows to the search

once again you have saved me