Date: Mon, 9 May 2016 13:19:09 -0700 From: Mark Millard <markmi@dsl-only.net> To: svn-ports-head@freebsd.org, freebsd.contact@marino.st Subject: Re: svn commit: r414832 - in head: Mk Mk/Scripts lang/perl5-devel lang/perl5.18 lang/perl5.20 lang/perl5.22 Message-ID: <CC91DAA6-CBA4-42BF-8D65-B6E8BF93C0C6@dsl-only.net>
next in thread | raw e-mail | index | archive | help
On Mon May 9 12:08:12 UTC 2016 John Marino wrote: > On 5/9/2016 1:58 PM, Mathieu Arnold wrote: > > > > This makes lang/perl5* use USE_LDCONFIG instead of hardcoding = -rpath. > > >=20 > Now that's really interesting and a shame it's not logged because IMO=20= > rpath is superior to LDCONFIG wrt to rtld lookups, so it would be=20 > interesting to know why perl was "downgraded" and what problem is = being=20 > solved. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209173 . The basic problem is that when perl is built the new one is run/tested = before perl is installed. When it is built with -rpath it uses that path = in those early runs/tests and fails as a result of referencing where = things will later be installed. It either: A) picks up the older libperl.so*'s or B) finds no libperl.so*'s (first time install for where it is looking) In case (A) the old perl version number is returned in a test that is = run and so the build fails that test. (The version number apparently = comes from the library.) In case (B) a run fails by not finding the libperl.so*'s and the build = fails. The specific example submitted was for inappropriately finding the = files: /usr/local/lib/perl5/5.22/mach/CORE/libperl.so* I was having to copy the libperl.so*'s from the failed /usr/obj/ area to = /usr/local/lib/perl5/5.22/mach/CORE/ and then re-run the build (or other = such manual hacks) in order that the early runs/tests would work/pass. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC91DAA6-CBA4-42BF-8D65-B6E8BF93C0C6>