Sun Apr 10 09:53:58 2016: Request 113618 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Strange issue with not packing libperl.dylib
Broken in: 1.030
Severity: Important
Owner: Nobody
Requestors: philk...@kime.org.uk
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=113618 >
On 2016-04-10 09:26:46, PHILKIME wrote:
> Thanks for the reply - that's all true:
>
> DYLD_LIBRARY_PATH=/var/folders/g0/t3rtgwks57366nz5dvxkrv_m0000gn/T//par-
> 7068696c6b696d65/cache-2a87b1d6222c0a4dfff86a3067e459abc842a0ff
>
> and the lib/exe is in there.
Puzzling...
> But I can't work out what changed from 1.29?
I fixed this "unpack a directory and a file both called 'version'" problem
and rewrote some of the embedding stuff. But it's working as expected.
> I remember there was some older OS related ticket which you
> merged for 1.30 to fix not following symlink names for libs (which
> seems to be fixed) - anything to do with it
No, this was for "pp --link LIB" - though both deal with shared libraries,
this doesn't have any implications here.
> or do I need to explicitly
> set DYLD_LIBRARY_PATH in the exe now?
You can't because it needs to be set _before_ you can run the exe.
Also the test confirmed that the packed executable "sees" the correct setting.
If /your/dyld/path is what the test reported, try
DYLD_LIBRARY_PATH=/your/dyld/path DYLD_PRINT_LIBRARIES=1 /your/dyld/path/foo.exe
It should tell you _which_ libperl.dylib is used.
Cheers, Roderich
