Shared object "libperl.so" not found; bootstrapped to ~/pkg

[James Cook <falsifian%falsifian.org@localhost>]

I am having trouble with a perl that I have built from pkgsrc head
botstrapped with ~/pkg as prefix. This happens if I try to load
the Fcntl module:

$ ~/pkg/bin/perl -MFcntl       
Can't load '/home/falsifian/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/auto/Fcntl/Fcntl.so' for module Fcntl: /home/falsifian/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/auto/Fcntl/Fcntl.so: Shared object "libperl.so" not found at /home/falsifian/pkg/lib/perl5/5.40.0/XSLoader.pm line 94.
 at /home/falsifian/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/Fcntl.pm line 862.
Compilation failed in require.
BEGIN failed--compilation aborted.

Similar errors occur for many of the other base perl modules I
tried. I'm guessing any module that uses a .so.

Any advice for how to hunt this down? I'm a bit fuzzy on how shared
libraries work or why this might have happened. The rest of my
email has more details in case they're useful, including a sequence
of commands I used to nuke ~/pkg and start over for the sake of
reproducibility (producing the results shown in this email).


----

I see this:

$ ldd /home/falsifian/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/auto/Fcntl/Fcntl.so     
/home/falsifian/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/auto/Fcntl/Fcntl.so:
        -lperl => not found
        -lc.12 => /usr/lib/libc.so.12

I don't know whether it matters that I used ~/pkg. I did try making
perl in a non-bootstrapped pkgsrc (so, default /usr/pkg prefix),
without installing it (because I don't want to mess up /usr/src),
and I see a similar issue there:

# In non-bootstraped pkgsrc
$ ldd work/perl-5.40.2/lib/auto/Fcntl/Fcntl.so     
work/perl-5.40.2/lib/auto/Fcntl/Fcntl.so:
        -lperl => not found
        -lc.12 => /usr/lib/libc.so.12

I don't know if that's expected; maybe the rpath is supposed to
get fixed by the install phase or something? (If it would help, I
can try reproducing under /usr/pkg in a VM or something.)


I also notice
	readelf -a ~/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/auto/Fcntl/Fcntl.so
shows this:
 0x000000000000000f (RPATH)              Library rpath: [/home/falsifian/pkg/lib]
but the one under /usr/pkg (working; installed with pkgin) has this instead:
 0x000000000000000f (RPATH)              Library rpath: [/usr/pkg/lib:/usr/pkg/lib/perl5/5.40.0/x86_64-netbsd-thread-multi/CORE]
and the non-bootstrapped one I didn't install (work/perl-5.40.2/...) has:
 0x000000000000000f (RPATH)              Library rpath: [/usr/pkg/lib]


To try to make this situation more reproducible, I used the following
commands to produce the perl installation under ~/pkg described
above. I've got pkgsrc checked out at ~/co/pkgsrc at git commit
93c6d87e.

rm -rf ~/pkg
cd ~/co/pkgsrc/bootstrap
./cleanup
./bootstrap --unprivileged
cd ../lang/perl5
~/pkg/bin/bmake clean
	===> Cleaning for perl-5.40.2
~/pkg/bin/bmake install
	...
	=> Creating binary package /home/falsifian/co/pkgsrc/packages/All/perl-5.40.2.tgz
	===> Installing binary package of perl-5.40.

(My end goal is to try doing some work on sysutils/git-annex, and
of course perl is a prerequisite. I decided to use ~/pkg as my
prefix to avoid messing up my existing (stable) packages. I thought
I'd be able to mix, but a package from pkgsrc head wanted a newer
sqlite3 than pkgin installed, and I didn't want to make guesses
about whether I could just "make replace" it, and decided a totally
separate prefix would be cleaner.)

-- 
James