shlib's not being registered (if there are non numbers after .so ?)

[mat813]

I'm not exactly sure why, but right now, lang/perl5-devel's libperl.so is called libperl.so.5.24.0.r1.2 and it seems to confuse pkg, I get this error:

(p5-Alias-2.32_3) /wrkdirs/usr/ports/devel/p5-Alias/work/stage//usr/local/lib/perl5/site_perl/mach/5.24/auto/Alias/Alias.so - required shared library libperl.so.5.24.0.r1.2 not found

But Alias.so has the right rpath and all:

root@10amd64-ports-perl5-devel:~ # readelf -d /usr/local/lib/perl5/site_perl/mach/5.24/auto/Alias/Alias.so|grep perl
 0x0000000000000001 (NEEDED)             Shared library: [libperl.so.5.24.0.r1.2]
 0x000000000000000f (RPATH)              Library rpath: [/usr/local/lib/perl5/5.24/mach/CORE]
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/local/lib/perl5/5.24/mach/CORE]

[mat813]

Oh, to reproduce, add DEFAULT_VERSIONS=perl5=devel to your make.conf, and try to build devel/p5-Alias

[infracaninophile]

The bit of code producing this effect is here:

https://github.com/freebsd/pkg/blob/master/libpkg/elfhints.c#L246

which says effectively that the ABI version is some string of digits and '.' characters.

As I recall, this was copied out of the FreeBSD ldconfig sources and uses the same heuristics to identify and parse shared library filenames. I don't know if there's some external standard we should be complying to, but that seems to be a BSD/Unix convention .

[mat813]

Well, the thing is, everything works fine with it, but pkg :-)

# ldd /usr/local/lib/perl5/site_perl/mach/5.24/auto/Alias/Alias.so
/usr/local/lib/perl5/site_perl/mach/5.24/auto/Alias/Alias.so:
        libperl.so.5.24.0.r2 => /usr/local/lib/perl5/5.24/mach/CORE/libperl.so.5.24.0.r2 (0x801603000)
...

If having a non digit after .so is bad, I can change it so that the r is removed, but I'd rather be sure it really is bad.

[mat813]

Also, it's a bit of a double standard:

# pkg shlib libperl.so.5.24.0.r3
libperl.so.5.24.0.r3 is provided by the following packages:
perl5-5.24.0.r3
No packages require libperl.so.5.24.0.r3.

It's ok for Perl to provide it, but it's not for any port to use it.

[infracaninophile]

On 04/28/16 09:55, Mathieu Arnold wrote:

Also, it's a bit of a double standard:

# pkg shlib libperl.so.5.24.0.r3
libperl.so.5.24.0.r3 is provided by the following packages:
perl5-5.24.0.r3
No packages require libperl.so.5.24.0.r3.

It's ok for Perl to provide it, but it's not for any port to use it.

Yeah. We should at least be consistent. As I recall, that test was already relaxed to allow any sequence of digits and dots, rather than just a dot and a single number for the ABI version. Given perl can load its shared library (and it is a genuine shared library, rather than a loadable module) and it works with other packages that embed a perl interpreter, then I can't see any reason not to allow arbitrary version strings.

Hmmm.... I wonder how many other instances there are of complex version strings on shlibs like that in the ports.

Cheers,

Matthew