[Bug 209173] lang/perl5.22: port build has inappropriate use of -Wl, -R/usr/local/lib/perl5/5.22/mach/CORE before the update libperl.so.5.22.2 is there to use (11.0-CURRENT in use)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209173

--- Comment #10 from Mark Millard <markmi at dsl-only.net> ---
Looking around I see that in the ordering of things tracing where the -Wl,-R
comes from (working backwards from a particular point):

. . ./work/perl-5.22.2/config.sh

contains a line that assigns ccdlflags:

ccdlflags='  -Wl,-R/usr/local/lib/perl5/5.22/mach/CORE'

The build's log file shows a line that says:

Creating config.sh...

at around 28% into the log file. By contrast the line:

Adding -Wl,-R/usr/local/lib/perl5/5.22/mach/CORE to the flags

is at around 6% into the log file and is the first mention of "CORE" in the log
file.

At around 5% is the question/answer:

Where do you want to put the public architecture-dependent libraries? (~name
okay)
[/usr/local/lib/perl5/5.22/mach]  

which seems to be the source of the path before "/CORE" in the -Wl,-R use.

The question is from:

. . ./work/perl-5.22/Configure

It is Configure that is causing . . ./work/perl-5.22/config.sh and the like to
use "-Wl,-R/usr/local/lib/perl5/5.22/mach/CORE" for "$osname" being "freebsd".

This is in part because of the answer to a prior question:

Any special flags to pass to $cc to use dynamic linking?
[none]

being "none" so that the default value for ccdlflags is assigned, which happens
to reference the final installation place and so presumes no staging.

If the answer was something else but "none" that answer would be the ccdlflags
value instead.

With "none" the default ends up being based on:

shrpdir=$archlibexp/CORE

via (for "$osname" being "freebsd"):

xxx="-Wl,-R$shrplibdir"

and a later:

ccdlflags="$ccdlflags $xxx"


For the wrong-.so-place tests (as long as they are used) as long as a staging
area is in use by FreeBSD ports design instead of direct use of the final
installation place the perl command built for use in those tests needs to refer
to the staging area libperl.so.5.22, not to the installation place. (5.22 is
just my specific example context and so is over specific overall.)

An alternative is to skip all tests that are before installation in the final
place that would be using the wrong/missing libperl.so.5.* from the reference
to the final place instead of the staging place.

Of course the final installed perl executable would need to refer to the final
installation place instead of the staging area.

Or perl needs to allow external control of the place to find the dynamic
linking materials and then to be externally controlled for the staging vs.
final stages.

This would appear to need at least a different answer to:

Any special flags to pass to $cc to use dynamic linking?
[none]

unless . . ./work/perl-5.22/Configure is reworked in some other way.

-- 
You are receiving this mail because:
You are the assignee for the bug.