[This is associated with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209173 against lang/perl5.22
(and implicitly some other lang/perl5.* examples) .]
Problem: building lang/perl5.22 from source (say via portmaster) with no prior
perl5.22 installed leads to:
> Shared object "libperl.so.5.22" not found, required by "perl"
on 11.0-CURRENT. (I've not tried a 10.x context so far. As stands I do not have
one.)
I'll first give some operational context and then show some readelf output and
truss output that suggests some about what is or is not going on. Then I'll
give some other supporting details.
Operational Context. . .
The perl port tries to build the perl executable and test it before anything
new has been installed in:
> /usr/local/lib/perl5/5.22/mach/CORE
(This is before staging. Note: I happen to be using use "portmaster -DK
lang/perl5.22" to build so materials are left behind from build failures. Paths
below are from my particular context.)
But it also builds the perl executable based on using:
> -Wl,-R/usr/local/lib/perl5/5.22/mach/CORE
leaving only something like LD_LIBRARY_PATH as a means of picking up the new
libperl.so.5.22 during any pre-final-installation tests of the perl executable
built. And perl's build sequence does do such tests, including checking that
the version number matches what it should. (libperl.so is where the version
number comes from.)
My initial example here will be for no pre-existing perl5.22 installation. I
will note a little about if, say, perl5.22.1 has been successfully installed
first before an update to perl5.22.2. Getting to that point for 5.22.1 may
require a work around.
Using portmaster to build perl 5.22 (specifically here 5.22.2) gets to the
point of testing
> /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/perl
which fails. Without a prior build of perl5.22 it fails with:
> Shared object "libperl.so.5.22" not found, required by "perl"
If there is instead an older 5.22.1 for an update to 5.22.2 the failure is for
finding and using the older libperl.so.5.22 which returns the older version
number, something perl's build procedure checks.
If after the failure I copy the libperl.so* files from:
> /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/
to:
> /usr/local/lib/perl5/5.22/mach/CORE/
and then try "portmaster -DK lang/perl5.22" again the build works based on
finding the new libperl.so.5.22 in the place it was not present before (no file
or older vintage file).
So what is going on?. . .
Below is readelf and truss output related to seeing what is or is not going on.
. .
(My example here happens to be on a 11.0 based rpi2 armv6 build but in my case
tailored to cortex-a7/armv7.)
> # readelf --dynamic
> /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/perl | grep PATH
> 0x0000000f RPATH Library rpath:
> [/usr/local/lib/perl5/5.22/mach/CORE]
> 0x0000001d RUNPATH Library runpath:
> [/usr/local/lib/perl5/5.22/mach/CORE]
> # env
> LD_LIBRARY_PATH=/usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2
> truss /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/perl
> mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,21,0x1000) =
> 537092096 (0x20036000)
> issetugid() = 0 (0x0)
> stat("/usr/libsoft",{ mode=drwxr-xr-x ,inode=3698147,size=15360,blksize=32768
> }) = 0 (0x0)
> __sysctl(0xbfbfe68c,0x2,0x20035258,0xbfbfe688,0x1,0x0) = 0 (0x0)
> __sysctl(0xbfbfe68c,0x2,0x20035358,0xbfbfe688,0x0,0x0) = 0 (0x0)
> __sysctl(0xbfbfe68c,0x2,0x20035458,0xbfbfe688,0x0,0x0) = 0 (0x0)
> __sysctl(0xbfbfe68c,0x2,0x20035558,0xbfbfe688,0x0,0x0) = 0 (0x0)
> __sysctl(0xbfbfe68c,0x2,0x20035658,0xbfbfe688,0x0,0x0) = 0 (0x0)
> lstat("/etc",{ mode=drwxr-xr-x ,inode=40850304,size=2560,blksize=32768 }) = 0
> (0x0)
> lstat("/etc/libmap-soft.conf",0xbfbfe5a0) ERR#2 'No such file or
> directory'
> access("/usr/local/lib/perl5/5.22/mach/CORE/libthr.so.3",F_OK) ERR#2 'No such
> file or directory'
> openat(AT_FDCWD,"/var/run/ld-elf-soft.so.hints",O_CLOEXEC,00) = 3 (0x3)
> read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\r\0\0\0"...,128) = 128 (0x80)
> lseek(3,0x8000000000,SEEK_SET) = 128 (0x80)
> read(3,"/usr/libsoft\0",13) = 13 (0xd)
> close(3) = 0 (0x0)
> access("/usr/libsoft/libthr.so.3",F_OK) = 0 (0x0)
> openat(AT_FDCWD,"/usr/libsoft/libthr.so.3",O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=3692264,size=110496,blksize=32768 }) = 0
> (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,12,0xbfbfe0182002a664)
> = 537055232 (0x2002d000)
> mmap(0x0,176128,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,537055316,0x32002d074)
> = 537124864 (0x2003e000)
> mmap(0x2003e000,106496,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537055316,0x32002d074)
> = 537124864 (0x2003e000)
> mmap(0x2005f000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537055316,0x32002d074)
> = 537260032 (0x2005f000)
> mmap(0x20060000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537055316,0x32002d074)
> = 537264128 (0x20060000)
> munmap(0x2002d000,4096) = 0 (0x0)
> close(3) = 0 (0x0)
> access("/usr/local/lib/perl5/5.22/mach/CORE/libperl.so.5.22",F_OK) ERR#2 'No
> such file or directory'
> access("/usr/libsoft/libperl.so.5.22",F_OK) ERR#2 'No such file or
> directory'
> access("/usr/libsoft/libperl.so.5.22",F_OK) ERR#2 'No such file or
> directory'
> Shared object "libperl.so.5.22" not found, required by "perl"write(2,"Shared
> object "libperl.so.5.22" "...,61) = 61 (0x3d)
>
> write(2,"\n",1) = 1 (0x1)
> exit(0x1)
> process exit, rval = 1
There is no evidence above of any attempt to use the path from "env
LD_LIBRARY_PATH=. . ." to access any file, much less libperl.so.5.22
specifically.
It is also interesting that the line
> access("/usr/libsoft/libperl.so.5.22",F_OK) ERR#2 'No such file or
> directory'
repeats twice back-to-back.
OTHER DETAILS. . .
Mathieu Arnold has tried to make changes to the lang/perl5.22 materials to help
but so far the behavior is invariant to his changes. (He also touched some
other lang/perl5.* materials but I've been using just 5.22.)
My /usr/ports/ is at -r414889 and currently has a lang/perl5.22/Makefile patch
Mathieu had me try but the behavior in question did not change from before I
had no patch.
My 11.0-CURRENT is at -r298990 (a no-debug build, 1100106 for kernel and user).
The build is tailored to the rpi2's cortex-a7/armv7 in world as well as the
kernel.
I've previously attempted lang/perl5.22 upgrade-to-5.22.2 builds on powerpc64
and powerpc but I'm away from those machines now and they are unplugged, so no
access currently. But what I'd done shows that the problem is not specific to
arm.
===
Mark Millard
markmi at dsl-only.net
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
