Jens Rehsack <rehsack%gmail.com@localhost> 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. libfile.so, libstatgrab.so, libfetch.so, > libssl.so ...). 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: /usr/pkg/lib/libgcrypto.la /usr/pkg/lib/libgcrypto.so.20 /usr/pkg/lib/libgcrypto.20.dylib 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