perl5
perl5 copied to clipboard
Perl
openbsd: ensure we link to the built libperl.a, not the system libperl.a
When building with gcc, lib/ExtUtils/t/Embed.t would link against the system libperl.a rather than the newly built libperl.a.
Due to the limited API used by the sample code this typically didn't crash, but some configuration changes could result in a crash or a link error.
For OpenBSD, change the link options to more closely match those used when building the perl executable, which results in linking against the correct library.
Fixes #22125
Also adds a test to ensure we are linking against the correct libperl.
Smoke reports from before a trivial rebase at https://perl.develop-help.com/?b=smoke-me%2Ftonyc%2F22125-openbsd-embed
- This set of changes requires a perldelta entry, and it is included.
@tonycoz, thanks for continuing to investigate this. Could you rebase your smoke-me branch and push this new code to that branch? That way, @cjg-cguevara's smoker will pick up the branch.
@afresh1, can you take a look at this p.r.? Thanks.
@tonycoz: I fetched your p.r. and built a perl locally per the following:
$ uname -mrs
OpenBSD 6.9 amd64
$ gcc --version
gcc (GCC) 4.2.1 20070719
$ gitcurr
gh-23265-tonycoz-22125-openbsd-embed-20250507
$ ./perl -Ilib -V:config_args
config_args='-des -Dusedevel -Dcc=gcc -Accflags=-DPERL_RC_STACK -DDEBUG_LEAKING_SCALARS';
$ ./perl -Ilib -v | head -2 | tail -1
This is perl 5, version 41, subversion 13 (v5.41.13 (v5.41.12-41-g060adda81e)) built for OpenBSD.amd64-openbsd
This configuration was the first one I discussed in https://github.com/Perl/perl5/issues/22125. All tests PASSed. So that's a very good sign. I will want to re-test this with clang10 and g++. However, as previously reported my OpenBSD-VM version is obsolete, so we'll need feedback from people who have more up-to-date versions of the platform and its C-compilers. Having your p.r. code in the smoke-me branch will be very helpful for this.
Having your p.r. code in the smoke-me branch will be very helpful for this.
I pushed it to the smoke-me, https://perl.develop-help.com/?b=smoke-me%2Ftonyc%2F22125-openbsd-embed we're just waiting for results now.
I've also gotten a PASS with the following configuration:
$ ./perl -Ilib -V:config_args
config_args='-des -Dusedevel -Dcc=clang -Accflags=-DPERL_RC_STACK -DDEBUG_LEAKING_SCALARS';
Am beginning a smoke-test run with my customary configurations. That will take several hours. Note that I haven't looked at the code changes at all -- only the test results.
I should be able to run tests with this. Will have to remember which architectures I have that still use gcc :-)
Intuitively, it seems wrong to me that this is OpenBSD specific code. Are we sure we're fixing this in the right place?
Intuitively, it seems wrong to me that this is OpenBSD specific code. Are we sure we're fixing this in the right place?
Smoke testing didn't find anything else tripping the added version check.
There may be other systems that trip this, but I'd rather not risk breaking this test for other systems by making the change for other systems too without evidence that it's needed.
Both points seem reasonable. We (PSC) are thinking we should ship this patch as is for now, but we also want to pick this up early next cycle and investigate whether we can make this change across the board without limiting it to OpenBSD.
Both points seem reasonable. We (PSC) are thinking we should ship this patch as is for now, but we also want to pick this up early next cycle and investigate whether we can make this change across the board without limiting it to OpenBSD.
Yeah that sounds reasonable to me.
I should be able to run tests with this. Will have to remember which architectures I have that still use gcc :-)
Time got away from me, it won't be this week.
On my machine where it is easy to build a smoke-me perl:
This is perl 5, version 41, subversion 13 (v5.41.13 (v5.41.12-41-g060adda81e)) built for OpenBSD.sparc64-openbsd
with
./Configure -des -Dusedevel -Dcc=gcc -Accflags="-DPERL_RC_STACK -DDEBUG_LEAKING_SCALARS"
I get:
Failed 3 tests out of 2664, 99.89% okay.
../lib/locale.t
porting/authors.t
run/locale.t
Which does not include failures from lib/ExtUtils/t/Embed.t.
Note that Embed.t fails similarly on FreeBSD with useshrplib=true
LD_LIBRARY_PATH=/usr/home/tony/dev/perl/git/perl ./runtests choose
t/../lib/ExtUtils/t/Embed ... ok
All tests successful.
Elapsed: 1 sec
u=0.00 s=0.01 cu=0.13 cs=0.27 scripts=1 tests=10
$ grep useshrplib config.sh
config_args='-des -Dusedevel -Duseshrplib -Dusethreads'
config_arg3='-Duseshrplib'
useshrplib='true'
$ uname -a
FreeBSD freebsd12 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64
Can you be more specific? blead works for me
On Wed, Jul 23, 2025 at 05:34:36PM -0700, Tony Cook wrote:
Can you be more specific? blead works for me
This was just something I noticed in passing while trying to reproduce the DBI failures, so I haven't looked closely. But:
$ uname -a FreeBSD perlmonger.nycbug.org 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64 $ env | grep LD_ $ env | grep PERL $ echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/davem/bin $
then with a freshly untarred perl-5.43.1.tar.gz and the following build script:
#!/bin/sh
PP=5.43
PPP=5.43.1
OUT=/home/davem/dbi_issue/perl-$PPP
( sh Configure \
-Dusedevel \
-Darchlib=$OUT/lib/perl-$PP/mach -Dcc=cc -Dinc_version_list=none -Dlibperl=libperl.so.$PPP -Dman1dir=$OUT/lib/perl5/$PP/perl/man/man1 -Dman3dir=$OUT/lib/perl5/$PP/perl/man/man3 -Dprefix=$OUT -Dprivlib=$OUT/lib/perl5/$PP -Dscriptdir=$OUT/bin -Dsitearch=$OUT/lib/perl5/site_perl/mach/$PP -Dsitelib=$OUT/lib/perl5/site_perl -Dsiteman1dir=$OUT/lib/perl5/site_perl/man/man1 -Dsiteman3dir=$OUT/lib/perl5/site_perl/man/man3 -Dusenm=n -Duseshrplib -sde -Ui_iconv -Ui_malloc -Uinstallusrbinperl -Alddlflags="-L$OUT/lib/perl5/$PP/mach/CORE" -Dshrpldflags='-Wl,-soname,$(LIBPERL:R)' -Doptimize='-g -pipe -fstack-protector-strong -fno-strict-aliasing' -Dusedtrace -Ui_gdbm -Dusemultiplicity=y -Duse64bitint -Dusemymalloc=n -Dusethreads=y -Dversiononly -Accflags='-DDEBUGGING -ggdb' && \
TEST_JOBS=4 HARNESS_OPTIONS=j4 make -j 4 test_harness && \
make -j 4 install \
) > stdout.log 2> stderr.log
I get:
../lib/ExtUtils/t/Embed.t (Wstat: 0 Tests: 2 Failed: 2) Failed tests: 1, 10
-- Diplomacy is telling someone to go to hell in such a way that they'll look forward to the trip
From what I can see that requires the -Dlibperl=libperl.so.$PPP for the test to fail, and causes problems on Linux too.
But it looks like the fix is similar - skipping -lperl and linking directly to $libperl
Setting libperl like that seems like it would cause other problems, from what I can tell from Configure any system that uses any of these from Configure:
cygwin*)
shrpldflags="$shrpldflags -Wl,--out-implib=libperl.dll.a"
...
linklibperl="-L. -lperl"
;;
sunos*)
linklibperl="-lperl"
;;
netbsd*|freebsd[234]*|openbsd*|dragonfly*|bitrig*)
linklibperl="-L. -lperl"
;;
interix*)
linklibperl="-L. -lperl"
shrpldflags="$shrpldflags -Wl,--image-base,0x57000000"
;;
if going to fail to link ./perl (or link to the wrong library).
eg. on DragonflyBSD:
LD_LIBRARY_PATH=/home/tony/dev/perl/git/perl ./miniperl -Ilib make_ext.pl DynaLoader.o MAKE="make" LIBPERL_A=libperl.so.5.43.2 LINKTYPE=static
cc -o perl -Wl,-E -fstack-protector-strong -L/usr/local/lib -Wl,-R/usr/local/lib/perl5/5.43.2/x86_64-dragonfly/CORE perlmain.o -L. -lperl `cat ext.libs` -lpthread -ldl -lm -lcrypt -lutil -lc
/usr/libexec/binutils234/elf/ld.gold: error: cannot find -lperl
perlmain.o:perlmain.c:function xs_init: error: undefined reference to 'boot_DynaLoader'
perlmain.o:perlmain.c:function xs_init: error: undefined reference to 'Perl_newXS'
...
perlmain.o:perlmain.c:function main: error: undefined reference to 'perl_run'
collect2: error: ld returned 1 exit status
*** Error code 1
Stop.
make: stopped in /home/tony/dev/perl/git/perl