On Sun, Sep 04, 2005 at 08:06:07PM +1000, skaller wrote:
> Reading your excellent article, you explain this
> (excuse me duplicating text from your article):
> "* Glibc[] support[s] transitive dependencies .."
> which if I understand correctly: supposed executable E required
> library A, and library A requires library B, then you can link
> with a command like:
> gcc E -lA
> and don't need to specify -lB.
Correct, for the case of dynamic linking.
> Now you say to use libtool, which prunes extraneous dependencies.
> I actually find libtool a superior pain .. it is complex to use
> and makes a real mess of build scripts ;( I need more convincing
> on this point (I understand the pruning dependencies ..)
Actually, this should be read as: *if* you are using libtool, use this
version that can handle pruning redundant dependencies. There's really
no reason to be using libtool in the first place unless you're concerned
about making your packages portable to as many OSes as possible; if
that's not a major consideration for you, save yourself the headache of
trying to integrate libtool. :)
> Then you say to use 'versioned symbols in all libraries depended
> on by other libs' .. which makes sense .. however I could use
> some education here: the example:
> http://people.debian.org/~vorlon/dependency-hell/img9.html
> doesn't make any sense to me. Can you explain what it is doing?
The first section,
HIDDEN {
local:
__*;
_rest*;
_save*;
}
is a workaround for certain architecture-specific symbols which must be
present in the library and must *not* be versioned (discovered by trial
and error); the solution is to declare them as local symbols only, so
they're present and unversioned but not exported.
The second part,
MIT_KRB5_17 {
global:
*;
}
specifies a symbol version to apply to all other exported symbols.
> And here:
> http://people.debian.org/~vorlon/dependency-hell/img10.html
> you have an example of use of the version script: the second
> case is headed
> libtool(Makefile.am)
Two examples: the first is how to use a linker script when calling gcc
directly, the second is how to set up a Makefile.am for a libtool-using
package to call it for you.
> > http://people.debian.org/~vorlon/dependency-hell/
> >
> > > It does seem 'contrary' in some way to Debian's policy
> > > of things going in particular places .. yet people don't
> > > always actually put them there .. :)
> >
> > I really have no idea what you're referring to here.
> On an arbitrary system, to use some libary K, you cannot just
> write -lK on your link command, because the library will only
> be sought in standard locations.. you need to add -Lpath so the
> linker can actually find the library.
> My commend meant 'Debian policy says to put libraries in /usr/lib'
> which means in theory you don't need any -L switches (more or less),
> however some packages don't conform to this policy, so you may still
> need -L switches: that's what I meant .. :)
Mmm, yes. Hopefully very few packages fall into that category.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature