| 1 |
On Fri, 30 May 2008 21:50:49 -0500 |
| 2 |
Ravi Pinjala <ravi@××××××××.net> wrote: |
| 3 |
> Could you explain, for the benefit of us spectators, what these |
| 4 |
> libtool problems are, and what cleaner solution you have in mind? |
| 5 |
> It'd make this whole discussion a lot more comprehensible. |
| 6 |
|
| 7 |
libtool links against dependencies-of-dependencies, rather than just |
| 8 |
direct dependencies. This is correct behaviour on some platforms under |
| 9 |
some situations (one example is static linking). But when linking |
| 10 |
shared objects on modern Unixy platforms it's a pain in the ass since |
| 11 |
you end up with a load of bogus shared object dependencies that break |
| 12 |
things unnecessarily upon upgrades. |
| 13 |
|
| 14 |
as-needed works around this by making the linker only link things from |
| 15 |
the command line that resolve a name dependency (but name dependencies |
| 16 |
aren't the only dependency type). This means that most of the extras |
| 17 |
libtool adds in end up getting ignored, but it also means that things |
| 18 |
the programmer has explicitly said to link in get ignored too. |
| 19 |
|
| 20 |
The correct fix is to make libtool only link to dependencies of |
| 21 |
dependencies when doing, for example, static linking. Debian has a |
| 22 |
half-working patch for this that I posted earlier in the thread. |
| 23 |
|
| 24 |
-- |
| 25 |
Ciaran McCreesh |
Archives