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
signature.asc
Description: This is a digitally signed message part.
