Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
> i think cases can be made for the other internal gcc libraries:
...
> - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap`
I'm afraid -fmudflap won't work alone (might be easy to fix in gcc?):
// a.c:
int main() { return 0; }
$ gcc -fmudflap a.c -o a
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.6/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `__wrap_main'
/tmp/ccCbbGQy.o: In function `global constructors keyed to 00099_0_main':
a.c:(.text+0x10): undefined reference to `__mf_init'
collect2: ld returned 1 exit status
$gcc -fmudflap -lmudflap a.c -o a
# all ok
same is true for all -{f,l}mudflap{,th,ir}
--
Sergei
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Wednesday 12 October 2011 15:38:47 Matt Turner wrote: > On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger wrote: > > On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: > >> Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: > >> > - The fix_libtool_files.sh command is now part of the toolchain > >> > eclass, so > >> > > >> > doesn't need to be ran by users anymore > >> > >> Moreover, that should only be needed for very old installs: libstdc++.la > >> that caused the trouble in the first place hasn't been around for over > >> an year (maybe two? I lost count), and the auto-fix of .la files in > >> recent Portage versions make it even less necessary. > > > > well, that's not entirely accurate. like libtool, now that we've dropped > > libstdc++.la, the majority of issues have "gone away". but we still > > install .la files for the other (much more infrequently used) internal > > gcc libraries. > > > > although this might be something we want to address in gcc. i was fine > > with dropping the libstdc++.la even though it listed things in > > dependency_libs because the only correct way (imo) to link C++ code is > > with `g++`. using `gcc -lstdc++` is not supported. > > > > i think cases can be made for the other internal gcc libraries: > > - libgomp.la: build/link with -fopenmp, not -lgomp > > - libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` > > - libgcj*.la: build/link with `gcj`, not `gcc -lgcj` > > - libobjc.la: use -lobjc to link, but dependency_libs='' > > - libffi.la: use -lffi to link, but dependency_libs='' > > - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` > > - libgij.la: build/link with `gij`, not `gcc -lgij` > > - libquadmath.la: only used by fortran, and dependency_libs='' > > gcc's Optimize Options page > (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) has an > example of linking C, C++, and FORTRAN code together, where it uses > g++ -lgfortran. Just thought I'd mention it. hmm, unusual, but good point. their example breaks when linking statically as fortran (always?) needs -lm, and with newer versions, -lquadmath. not sure how to address that other than leaving libgfortran.la in place :(. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger wrote: > On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: >> Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: >> > - The fix_libtool_files.sh command is now part of the toolchain >> > eclass, so >> > >> > doesn't need to be ran by users anymore >> >> Moreover, that should only be needed for very old installs: libstdc++.la >> that caused the trouble in the first place hasn't been around for over >> an year (maybe two? I lost count), and the auto-fix of .la files in >> recent Portage versions make it even less necessary. > > well, that's not entirely accurate. like libtool, now that we've dropped > libstdc++.la, the majority of issues have "gone away". but we still install > .la files for the other (much more infrequently used) internal gcc libraries. > > although this might be something we want to address in gcc. i was fine with > dropping the libstdc++.la even though it listed things in dependency_libs > because the only correct way (imo) to link C++ code is with `g++`. using `gcc > -lstdc++` is not supported. > > i think cases can be made for the other internal gcc libraries: > - libgomp.la: build/link with -fopenmp, not -lgomp > - libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` > - libgcj*.la: build/link with `gcj`, not `gcc -lgcj` > - libobjc.la: use -lobjc to link, but dependency_libs='' > - libffi.la: use -lffi to link, but dependency_libs='' > - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` > - libgij.la: build/link with `gij`, not `gcc -lgij` > - libquadmath.la: only used by fortran, and dependency_libs='' > -mike gcc's Optimize Options page (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) has an example of linking C, C++, and FORTRAN code together, where it uses g++ -lgfortran. Just thought I'd mention it. Matt
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: > Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: > > - The fix_libtool_files.sh command is now part of the toolchain > > eclass, so > > > > doesn't need to be ran by users anymore > > Moreover, that should only be needed for very old installs: libstdc++.la > that caused the trouble in the first place hasn't been around for over > an year (maybe two? I lost count), and the auto-fix of .la files in > recent Portage versions make it even less necessary. well, that's not entirely accurate. like libtool, now that we've dropped libstdc++.la, the majority of issues have "gone away". but we still install .la files for the other (much more infrequently used) internal gcc libraries. although this might be something we want to address in gcc. i was fine with dropping the libstdc++.la even though it listed things in dependency_libs because the only correct way (imo) to link C++ code is with `g++`. using `gcc -lstdc++` is not supported. i think cases can be made for the other internal gcc libraries: - libgomp.la: build/link with -fopenmp, not -lgomp - libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` - libgcj*.la: build/link with `gcj`, not `gcc -lgcj` - libobjc.la: use -lobjc to link, but dependency_libs='' - libffi.la: use -lffi to link, but dependency_libs='' - libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` - libgij.la: build/link with `gij`, not `gcc -lgij` - libquadmath.la: only used by fortran, and dependency_libs='' -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
Ryan Hill posted on Mon, 10 Oct 2011 22:13:15 -0600 as excerpted: > I try to overcome that obstacle with the gcc-porting overlay. I try to > stick all the patches that haven't been applied to the main tree in > there. (try being the key word - I really dropped the ball this release > cycle as I was graduating and then got stuck working 80hr weeks for a > few months.) Thanks, BTW. I really haven't tried 4.6 yet either, for similar work- related time constraint reasons, and IIRC that overlay hasn't been around for /too/ many cycles, so I've not really had a chance to use it. But thanks for the effort. It is appreciated, and I now have that overlay on my mental checklist for the next time I /do/ decide to unmask gcc. Having gone thru several cycles without it, I'm already sure it's going to be /quite/ a benefit. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Tue, 11 Oct 2011 03:27:04 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > The problem generally occurs when I decided I've waited long enough for a > long released upstream gcc (4.x.1 and often 4.x.2 are released already!) > to get unmasked even to ~arch. Of course, having been thru this cycle a > few times now, I well understand the reasons why it takes so long for > Gentoo to bump gcc even to ~arch, and accept that I'll often have to dig > thru bugs (often with patches attached for months, with no visible > action, if I were to complain about Gentoo it'd be about the maintainers > of those packages letting those bugs sit, or of packages that should be > put up for someone else to maintain if the maintainers can no longer > handle it, not about the efforts of the toolchain folks) and drop patches > in /etc/portage/patches/* and/or overlay a package if the ebuild itself > needs patched, and that a few packages might not yet have patches > available. That's not the problem. I try to overcome that obstacle with the gcc-porting overlay. I try to stick all the patches that haven't been applied to the main tree in there. (try being the key word - I really dropped the ball this release cycle as I was graduating and then got stuck working 80hr weeks for a few months.) > The problem is often cmake related. Since cmake is C++, once I rebuild > it against the new gcc, it tends to refuse to run if I switch to the old > gcc. Which means I'm SOL for the cmake-based package in question if it > can't yet be built against the new gcc, since the package itself won't > build with new gcc, and cmake won't run to let the package build with the > old gcc. Yeah I've run into situations like this many times. I fear it will only get worse as GCC seems to gather more and more external dependencies every release. If some future mandatory dependency links to libstdc++ it would seem to me that building that package with a newer GCC could make it very difficult to switch back. We already have this situation with the graphite libs (ppl/cloog-ppl), but fortunately it only breaks the graphite options, not the entire compiler. Anyways, we're getting off topic here. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
Ryan Hill posted on Mon, 10 Oct 2011 20:21:51 -0600 as excerpted: > There are some packages that all need to be built with the same version > of GCC. The whole qt-* family is an example, or at least it was a year > ago (I'm not using KDE any more). Luckily they tend to be bumped as a > unit. > > The biggest problem is building stuff with a newer version of gcc than > the "system" version, either outside of portage, or selectively changing > back with gcc-config. Programs can get linked to symbols in (usually) > libstdc++.so.6 that have a symbol version that doesn't exist in the > previous release. When you switch back to using that release as your > system compiler, > the libstc++ library also gets switched out, and suddenly your > gcc-4.6-compiled firefox won't launch. If you've ever gotten a bug > report like "libstdc++.so.6: version `GLIBCXX_3.4.15' not found" then > you've dealt with this. > > This isn't a problem most users encounter, but some do like to try to > rebuild some of their system a bit at a time, and this is the reason why > I usually recommend they rebuild everything. By making it an all or > nothing affair, they're less likely to try hopping back and forth > between versions. As with you, this problem appears mostly with kde, here. But at least here, it's *NOT* because I'm TRYING to rebuild a bit of my system at a time, but because parts of it won't yet build with the new gcc. The problem generally occurs when I decided I've waited long enough for a long released upstream gcc (4.x.1 and often 4.x.2 are released already!) to get unmasked even to ~arch. Of course, having been thru this cycle a few times now, I well understand the reasons why it takes so long for Gentoo to bump gcc even to ~arch, and accept that I'll often have to dig thru bugs (often with patches attached for months, with no visible action, if I were to complain about Gentoo it'd be about the maintainers of those packages letting those bugs sit, or of packages that should be put up for someone else to maintain if the maintainers can no longer handle it, not about the efforts of the toolchain folks) and drop patches in /etc/portage/patches/* and/or overlay a package if the ebuild itself needs patched, and that a few packages might not yet have patches available. That's not the problem. The problem is often cmake related. Since cmake is C++, once I rebuild it against the new gcc, it tends to refuse to run if I switch to the old gcc. Which means I'm SOL for the cmake-based package in question if it can't yet be built against the new gcc, since the package itself won't build with new gcc, and cmake won't run to let the package build with the old gcc. Of course, there's often transient issues with various apps if I try to run them in the middle of the rebuild process, too, but they do tend to be just that, transient, and to go away once I've completed the full rebuild, even when it means manually finding patches (ok) or switching to older gcc (not as good, but usually works, except as mentioned with cmake based packages) occasionally to do it. Fortunately, kde upstream seems to be /relatively/ good about building with the latest gcc themselves, so there's not as many problems there as there certainly could be given the cmake issue, but it is usually a problem for the couple of corner-cases whose upstream devs apparently don't update gcc as fast as most of the rest of kde does (sometimes not kde-base/* but other kde-based packages), and/or for the occasional non- kde but still qt/cmake based app. Tho fortunately for me personally at least, while I continue using kde as my DE of choice, with the kdepim move to akonadi and my subsequent purge of anything kdepim based, and the time it seems to take to get serious konqueror/rekonq bugs fixed indicating that even most kde folks apparently default to firefox or other alternatives, such that I too now default to firefox, and with the kde4 amarok and kaffeine already long replaced with non-kde alternatives due to their breakage, and with USE=semantic-desktop now turned off since I killed akonadi and thus could actually do so, there's now rather less kde-based-apps to get broken, here, and what remains tends to run VASTLY better and faster without all that semantic-desktop crap dragging it down! =:^) So there's less opportunity for the problem to manifest here, than there once was. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Sat, 8 Oct 2011 11:33:07 + Sven Vermeulen wrote: > Hi guys > > There is some FUD regarding GCC upgrades and I don't have the proper > knowledge to write a correct document on GCC upgrades. As you are currently > aware, we have a GCC upgrade guide [1], but it has seen its last update in > 2008. Since then, things have undoubtedly changed. > > What I can find on GCC upgrades and their apparent need (or no-need) for > rebuilding stuff: There are some packages that all need to be built with the same version of GCC. The whole qt-* family is an example, or at least it was a year ago (I'm not using KDE any more). Luckily they tend to be bumped as a unit. The biggest problem is building stuff with a newer version of gcc than the "system" version, either outside of portage, or selectively changing back with gcc-config. Programs can get linked to symbols in (usually) libstdc++.so.6 that have a symbol version that doesn't exist in the previous release. When you switch back to using that release as your system compiler, the libstc++ library also gets switched out, and suddenly your gcc-4.6-compiled firefox won't launch. If you've ever gotten a bug report like "libstdc++.so.6: version `GLIBCXX_3.4.15' not found" then you've dealt with this. This isn't a problem most users encounter, but some do like to try to rebuild some of their system a bit at a time, and this is the reason why I usually recommend they rebuild everything. By making it an all or nothing affair, they're less likely to try hopping back and forth between versions. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On 10/10/11 4:45 AM, Diego Elio Pettenò wrote: > Not really. GCC, like most other libraries, only supports > forward-compatibility. Which means that you can use code built against > 4.5 when using 4.6. I'm not sure about that. It might be a bit speculative, but I think I remember problems with that unless I rebuilt everything with new GCC (this was not with 4.5 and 4.6, but some older versions). > On the other hand without any specifics as to what failed for you it is > difficult to judge whether you found an ABI break or simply a bug in > your library or code... If rebuilding with new GCC fixes the problem I think it means the problem was with ABI. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
Il giorno dom, 09/10/2011 alle 12.35 -0400, James Cloos ha scritto: > > > Ie, ln(1) cannot find some of the symbols it needs if the .so was > compiled with 4.5 and the .o files with 4.6. > > Which looks like an ABI issue, yes? Not really. GCC, like most other libraries, only supports forward-compatibility. Which means that you can use code built against 4.5 when using 4.6. Mixing and matching is never high priority and usually doesn't work. On the other hand without any specifics as to what failed for you it is difficult to judge whether you found an ABI break or simply a bug in your library or code... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto: > > - The fix_libtool_files.sh command is now part of the toolchain > eclass, so > doesn't need to be ran by users anymore Moreover, that should only be needed for very old installs: libstdc++.la that caused the trouble in the first place hasn't been around for over an year (maybe two? I lost count), and the auto-fix of .la files in recent Portage versions make it even less necessary. As for libtool, it is required, but it doesn't happen so often that it is visible why it's necessary: % fgrep 4.6.1 /usr/bin/libtool sys_lib_search_path_spec="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 /usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib " sys_lib_dlsearch_path_spec="/lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 /lib32 /usr/lib32 /usr/local/lib32 /lib /usr/lib /usr/local/lib /usr/x86_64-pc-linux-gnu/lib /usr/lib64/opengl/xorg-x11/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/32 /usr/lib/postgresql /usr/lib64/postgresql /usr/lib64/postgresql-8.4/lib64/ /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.2 /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.2/adalib /usr/games/lib /usr/games/lib64 /usr/games/lib32 /usr/local/xine-lib-1.1/lib64 /usr/local/xine-lib-1.2/lib64 /usr/lib64/path64/lib /usr/lib64/path64/lib/1.0.0/x8664/64 /opt/ekopath/lib /opt/ekopath/lib/4.0.11/x8664/64 " compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64 /lib/../lib64 /usr/lib/../lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.." predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtbeginS.o" postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.." compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64 /lib/../lib64 /usr/lib/../lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.." predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtbeginS.o" postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.." -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
