| 1 |
On Saturday 08 October 2011 11:07:49 Diego Elio Pettenò wrote: |
| 2 |
> Il giorno sab, 08/10/2011 alle 11.33 +0000, Sven Vermeulen ha scritto: |
| 3 |
> > - The fix_libtool_files.sh command is now part of the toolchain |
| 4 |
> > eclass, so |
| 5 |
> > |
| 6 |
> > doesn't need to be ran by users anymore |
| 7 |
> |
| 8 |
> Moreover, that should only be needed for very old installs: libstdc++.la |
| 9 |
> that caused the trouble in the first place hasn't been around for over |
| 10 |
> an year (maybe two? I lost count), and the auto-fix of .la files in |
| 11 |
> recent Portage versions make it even less necessary. |
| 12 |
|
| 13 |
well, that's not entirely accurate. like libtool, now that we've dropped |
| 14 |
libstdc++.la, the majority of issues have "gone away". but we still install |
| 15 |
.la files for the other (much more infrequently used) internal gcc libraries. |
| 16 |
|
| 17 |
although this might be something we want to address in gcc. i was fine with |
| 18 |
dropping the libstdc++.la even though it listed things in dependency_libs |
| 19 |
because the only correct way (imo) to link C++ code is with `g++`. using `gcc |
| 20 |
-lstdc++` is not supported. |
| 21 |
|
| 22 |
i think cases can be made for the other internal gcc libraries: |
| 23 |
- libgomp.la: build/link with -fopenmp, not -lgomp |
| 24 |
- libgfortran*.la: build/link with `gfortran`, not `gcc -lgfortran` |
| 25 |
- libgcj*.la: build/link with `gcj`, not `gcc -lgcj` |
| 26 |
- libobjc.la: use -lobjc to link, but dependency_libs='' |
| 27 |
- libffi.la: use -lffi to link, but dependency_libs='' |
| 28 |
- libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap` |
| 29 |
- libgij.la: build/link with `gij`, not `gcc -lgij` |
| 30 |
- libquadmath.la: only used by fortran, and dependency_libs='' |
| 31 |
-mike |
Archives