1 |
On Thursday 26 January 2006 19:48, Mike Frysinger wrote: |
2 |
> On Thursday 26 January 2006 11:16, Paul de Vrieze wrote: |
3 |
> > On Thursday 26 January 2006 16:34, Mikey wrote: |
4 |
> > > And those instructions have nothing whatsoever to do with common sense |
5 |
> > > from a new, or even experienced users perspective. Knowing that a gcc |
6 |
> > > upgrade will break libtool is not common sense, nor is it commonly |
7 |
> > > known. |
8 |
> > |
9 |
> > It will not break libtool. |
10 |
> |
11 |
> it does and it doesnt |
12 |
> |
13 |
> /usr/bin/libtool hardcodes the paths to internal gcc files |
14 |
> |
15 |
> normally this isnt an issue as most packages now generate and use their own |
16 |
> copy of libtool so that they always have the current toolchain information |
17 |
> |
18 |
> a few older packages however (jpeg comes to mind) use the system libtool |
19 |
> instead of bundling their own |
20 |
|
21 |
What I mean is that if library X say libjpeg, which uses libstdc++ properly |
22 |
links to libstdc++ (ldd libjpeg.so returns libstdc++) there is no need for |
23 |
library/binary Y that uses libX to also link against libstdc++. As such there |
24 |
is no need to specify this in the libtool archive of library X as linking |
25 |
instructions for linking against it. Doing so is superfluous, and the need |
26 |
for the "--as-needed" flag in the first place. It is actually also safe to |
27 |
just delete the libtool archives. In that case normal linking is performed |
28 |
which works perfectly well. |
29 |
|
30 |
Paul |
31 |
|
32 |
-- |
33 |
Paul de Vrieze |
34 |
Gentoo Developer |
35 |
Mail: pauldv@g.o |
36 |
Homepage: http://www.devrieze.net |