tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Requirements for specifying dependencies on libraries

Jens Rehsack <> writes:

> since I currently attend the annual Perl Q&A Hackathon, where
> traditionally most important toolchain people sit together and talk
> about ways to improve Perl and CPAN, we talked about packaging and how
> to support that.
> We come to the conclusion, that in the machine readable meta
> information a field shall be provided which names the requirements of
> external libraries (eg.,,,
> ...). This name should be in a canonical way.
> Here comes the question: from pkgsrc point of view, how such a
> canonical name should look like?

The notion of specifying libraries can come in two ways.  One is
relative to a source package, in terms of what it needs, and there it's
about API.   The other is about particular shlib versions, afer a
package has been built.  Then, I can see three ways, and (picking
libgcrypt without loss of generality), I can see:


The first one seems to be present on most systems, but only works for
packages that use libtool.  And the filename doesn't have the version,
but it's in the file.  The second works on normal computers (with an ELF
bias, how quickly we don't even remember when an a.out library looked
like in detail) and the last one on Macs,

So if you're really talking about ABI of a built package, then I think
it's either so or dylib.

Are perl modules configured to dlopen particular shlib versions?  Really
the version number is arbitrary per OS and can be changed by packaging,
so that seems somewhat fraught.


Attachment: pgpOgk7fP4KK9.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index