Andres Freund <and...@anarazel.de> writes:
> FWIW, while trying to mirror the same logic in meson I learned that the new
> logic removes the rpath setting from the parameters on at least netbsd and
> suse. We'll add them back - unless --disable-rpath is used.
Hmm ... on my shiny new netbsd buildfarm animal, I see:
$ perl -MConfig -e 'print "$Config{ccdlflags}"'
-Wl,-E -Wl,-R/usr/pkg/lib/perl5/5.34.0/powerpc-netbsd-thread-multi/CORE
$ perl -MConfig -e 'print "$Config{ldflags}"'
-pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib
$ perl -MExtUtils::Embed -e ldopts
-Wl,-E -Wl,-R/usr/pkg/lib/perl5/5.34.0/powerpc-netbsd-thread-multi/CORE
-pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib
-L/usr/pkg/lib/perl5/5.34.0/powerpc-netbsd-thread-multi/CORE -lperl -lm -lcrypt
-lpthread
So we were *already* stripping the rpath for where libperl.so is,
and now we also strip -L and rpath for /usr/lib (which surely is
pointless) and for /usr/pkg/lib (which in point of fact have to
be added to the PG configuration options anyway). These Perl
options seem a bit inconsistent ...
> I think some
> distributions build with --disable-rpath. Not sure if worth worrying about.
I believe that policy only makes sense for distros that expect every
shared library to appear in /usr/lib (or /usr/lib64 perhaps). Red Hat
for one does that --- but they follow through: libperl.so is there.
I think we're good here, at least till somebody points out a platform
where we aren't.
regards, tom lane
