On Wed, Oct 12, 2011 at 3:13 PM, Mike Frysinger <vap...@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
