[gentoo-dev] GCC upgrades, FUD and gentoo documentation

[gentoo-dev] GCC upgrades, FUD and gentoo documentation

[Sven Vermeulen]

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:
- Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds from
  that version onwards should not be needed
- The fix_libtool_files.sh command is now part of the toolchain eclass, so
  doesn't need to be ran by users anymore

The only thing I fail to find out is why libtool needs to be rebuild (if it
still needs to be). There are some sources telling it always needs to be
rebuild (RedHat seems to fix the two togather at all times: gcc and
libtool), others state that this is similar towards the C++ ABI, so not
needed anymore since 3.4.0/4.1.0.

I revamped the GCC Upgrade guide [2] with what I think is correct nowadays,
but this is, to be honest, a bit out of my league. That's why I'm asking
you, development community at large, to give some feedback on this, allowing
the GDP to get rid of the FUD once and for all ;-)

Wkr,
	Sven Vermeulen

[1] http://www.gentoo.org/doc/en/gcc-upgrading.xml
[2] http://dev.gentoo.org/~swift/docs/previews/gcc-upgrading.xml

[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Diego Elio Pettenò]

Il giorno sab, 08/10/2011 alle 11.33 +0000, 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/

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[James Cloos]

>>>>> "SV" == Sven Vermeulen <swift@gentoo.org> writes:

SV> - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds
SV>   from that version onwards should not be needed

That is not generally true.

I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things
outside of portage.  I still run into compilation errors with C++ which
go away if I compile said code with 4.5.

GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[Matt Turner]

On Sat, Oct 8, 2011 at 6:57 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "SV" == Sven Vermeulen <swift@gentoo.org> writes:
>
> SV> - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds
> SV>   from that version onwards should not be needed
>
> That is not generally true.
>
> I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things
> outside of portage.  I still run into compilation errors with C++ which
> go away if I compile said code with 4.5.
>
> GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*.

Is that a problem with the ABI, or just that gcc-4.6 is more strict? I
think it's the latter.

Matt

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[James Cloos]

>>>>> "MT" == Matt Turner <mattst88@gentoo.org> writes:

MT> Is that a problem with the ABI, or just that gcc-4.6 is more strict?
MT> I think it's the latter.

The failure occurs at the linking stage, not the compiling stage.

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?

Again, though, only for some libs.  And I do not remember which.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[Matt Turner]

On Sun, Oct 9, 2011 at 4:35 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "MT" == Matt Turner <mattst88@gentoo.org> writes:
>
> MT> Is that a problem with the ABI, or just that gcc-4.6 is more strict?
> MT> I think it's the latter.
>
> The failure occurs at the linking stage, not the compiling stage.
>
> 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?
>
> Again, though, only for some libs.  And I do not remember which.

Right, if it fails at link time, it's possibly an ABI incompatibility.
I just haven't ever experienced this myself.

Matt

[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

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/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

On Sat, 8 Oct 2011 11:33:07 +0000
Sven Vermeulen <swift@gentoo.org> 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.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Duncan]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

On Tue, 11 Oct 2011 03:27:04 +0000 (UTC)
Duncan <1i5t5.duncan@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.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Duncan]

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

Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1620 bytes --]

On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote:
> Il giorno sab, 08/10/2011 alle 11.33 +0000, 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 667 bytes --]

On Saturday 08 October 2011 18:57:23 James Cloos wrote:
> >>>>> "SV" == Sven Vermeulen <swift@gentoo.org> writes:
> SV> - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds
> SV>   from that version onwards should not be needed
> 
> That is not generally true.
> 
> I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things
> outside of portage.  I still run into compilation errors with C++ which
> go away if I compile said code with 4.5.
> 
> GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*.

i think you're hitting a bug that has nothing to do with the ABI 
compatibility.  i.e. Bug 297685.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Matt Turner]

On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote:
>> Il giorno sab, 08/10/2011 alle 11.33 +0000, 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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2296 bytes --]

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 +0000, 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]