Request for help with DYLD_LIBRARY_PATH-related bug in perl5.28 build

[Mojca Miklavec]

On 17 August 2018 at 02:42, Tony Cook wrote:
> On Thu, Aug 16, 2018 at 12:28:32PM +0200, Mojca Miklavec wrote:
>> Hi,
>>
>> Is there any volunteer to help with rewriting/fixing part of the perl
>> build system*** (which sets DYLD_LIBRARY_PATH to current build path
>> for the sake of finding the library, just to be later shadowed by the
>> OS, probably for security reasons)?
>>
>> The bug first appeared in running the test suite:
>>     https://trac.macports.org/ticket/55203
>> but in 5.28 it escalated to being unable to build perl itself to start with.
>>
>> HomeBrew's workaround was to create a symlink after configure and
>> before make. For us that would mean doing something like
>>     ln -s /opt/local/var/macports/build/_path_to_lang_perl5/perl5.28/work/perl-5.28.0/libperl.dylib
>> \
>>     /opt/local/lib/perl5/5.28/darwin-thread-multi-2level/CORE/libperl.dylib
>> after the configure step.
>>
>> But I'm not too thrilled to repeat the same (pretty nasty?) workaround.
>>
>> See:
>>     https://rt.perl.org/Public/Bug/Display.html?id=126706
>>     https://rt.perl.org/Public/Bug/Display.html?id=133306
>>
>> Other non-broken build system first link against the local version of
>> libraries and then run install_name_tool during "make install" to fix
>> the links to binaries. This would probably be the best patch for Perl
>> as well, but I'm not eager to spend so much time trying to learn how
>> their build system works and then fixing all the places, that would
>> take me forever. The first link contains an attempt of a patch which
>> "unhides" DYLD_LIBRARY_PATH to some extent, but it's incomplete.
>
> Hi,
>
> I plan to extend that patch to a full fix in this development cycle

Thank you.

> (before 5.30), but I have some other perl tasks that I need to finish
> first.
>
> I'll take a look at using install_name_tool, but I don't know how
> practical it will be to use that in the perl build process (in
> particular, for the modules.)

I admit that I don't know anything about the perl build system.
(I never had any issues with module building and testing so far - that
said, lots of them are pure scripts.)

Here's my "hello-world" example demonstrating what I consider to be
the correct behaviour (it doesn't need to use @rpath):
    https://github.com/mojca/test-meson-libraries#cmake
(I needed this to test some buggy behaviour of meson.)

When libraries and binaries are being built, it's ideal if paths are
correct in that temporary location (without the need to resort to more
and more workarounds for DYLD_LIBRARY_PATH) and then the paths get
fixed during "make install".

I don't know how difficult this would be to fix in perl, but it would
probably help a lot in the light of being future-proof and less hacky.
Apple has been so profoundly deprecating and hiding DYLD_LIBRARY_PATH
that I wouldn't be surprised if they simply disable / remove it one
day.


Meson had the reverse problem: everything would work in the build
directory, but installed libraries kept the strange path. However it
was "easy" to fix that in MacPorts by simply running install_name_tool
on each file at the end of the build. Fixing it in the middle of the
build as required by perl is nearly impossible (without patching the
build scripts).

>> Any other less aggressive workaround is also welcome. Usually this
>> could be fixed by manually running install_name_tool, but this needs
>> to be done during the build.
>>
>> (If I login to their tracker, I'm not even able to view the relevant
>> tickets, only the ones I opened myself. I'm able to view the tickets
>> as anonymous user, but then I'm not able to subscribe or comment.)
>
> If you mail perlbug-admin at perl.org they might be able to fix your
> access.

Thank you for the hint, I just did.

Mojca