[rt.cpan.org #63939]

[Philip Kime via RT]

Wed Dec 15 04:00:06 2010: Request 63939 was acted upon.
Transaction: Ticket created by PHILKIME
Queue: PAR-Packer
Subject: (No subject given)
Broken in: 1.008
Severity: Normal
Owner: Nobody
Requestors: ***@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63939 >


It seems that the behaviour of --link is subtly different between OSX
and Linux.

Many libraries are symbolic links and are referenced through the link
names. Consider a library referenced as X which is a symlink to Y

X -> Y

On linux, pp dereferences X and packs Y with the name X, which is nice.
However on OSX, it seems that pp dereferences X and packs Y but with the
name Y. This breaks components which reference the library via name X.

I can work around this by copying Y to name X in, say, /tmp and then
packing /tmp/X and this works but it would be nice to make OSX pp have
the same behaviour as linux pp.

[Roderich Schupp via RT]

Wed Dec 15 10:57:08 2010: Request 63939 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: (No subject given)
Broken in: 1.008
Severity: Normal
Owner: Nobody
Requestors: ***@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63939 >

Post by Philip Kime via RT
However on OSX, it seems that pp dereferences X and packs Y but with the
name Y.

I suppose you checked the cache area of your packed executable
(typically /tmp/par-USR/SHA1-CHECKSUM) and found Y there, right?

Post by Philip Kime via RT
This breaks components which reference the library via name X.

Looks like the heuristic in methods _find_shlib and _chase_lib
of PAR::Packer is wrong for OSX. Sorry, I know next to nothing
about OSX - does it use ELF for objects and shared libraries?
If so, what is the SONAME of X?

Can you run the following script with a single argument:
the value of pp's --link option where the problem shows?

use PAR::Packer;
my ($link) = @ARGV;
my $pp = PAR::Packer->new;
print $pp->_find_shlib($link, "foobar");

If it complains about "Environment variable LD_LIBRARY_PATH
does not exist", just set LD_LIBRARY_PATH to the built-in library
search path (e.g. /lib:/usr/lib on Linux, Solaris).

Cheers, Roderich

[Lamprecht Christoph via RT]

Fri Oct 03 09:08:13 2014: Request 63939 was acted upon.
Transaction: Correspondence added by LAMPRECHT
Queue: PAR-Packer
Subject: The behaviour of "pp --link ..." is subtly different between OSX and Linux.
Broken in: 1.008
Severity: Normal
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63939 >


The naming schema for shared libs on darwin is

libname.x.x.x.dylib

The attached patch changes _find_shlib and _chase_lib to use the extension .dylib instead of of $Config{dlext} which has the value '.bundle' (there are different types of dynamically linked libs).
It also changes the regexes used to derive the correct name 'libname.x.dylib' from the forms -l libname.dylib ; -l libname.x.x.x.dylib; /path/to/libname.dylib etc.
Files that are named .*\.bundle (these do not follow the version numbering schema of .dylib files)
can still be referenced by their full name.
I'm a pp user and not an expert concerning MacOSX. So anyone who could review would be welcome.

Cheers, Christoph

Post by Roderich Schupp via RT
Looks like the heuristic in methods _find_shlib and _chase_lib
of PAR::Packer is wrong for OSX. Sorry, I know next to nothing
about OSX - does it use ELF for objects and shared libraries?
If so, what is the SONAME of X?
the value of pp's --link option where the problem shows?
use PAR::Packer;
my $pp = PAR::Packer->new;
print $pp->_find_shlib($link, "foobar");
If it complains about "Environment variable LD_LIBRARY_PATH
does not exist", just set LD_LIBRARY_PATH to the built-in library
search path (e.g. /lib:/usr/lib on Linux, Solaris).

[Philip Kime via RT]

Sun Mar 27 10:39:25 2016: Request 63939 was acted upon.
Transaction: Correspondence added by PHILKIME
Queue: PAR-Packer
Subject: The behaviour of "pp --link ..." is subtly different between OSX and Linux.
Broken in: 1.008
Severity: Normal
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63939 >

ls -ld /opt/local/lib/libz.1.dylib

lrwxr-xr-x 1 root admin 16 2 Oct 22:33 /opt/local/lib/libz.1.dylib -> libz.1.2.8.dylib

/tmp/thing.pl /opt/local/lib/libz.1.dylib

/opt/local/lib/libz.1.dylib

Does this mean this is fixed now?

[Roderich Schupp via RT]

Tue Mar 29 04:48:14 2016: Request 63939 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: The behaviour of "pp --link ..." is subtly different between OSX and Linux.
Broken in: 1.008
Severity: Normal
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63939 >

Post by Philip Kime via RT
Does this mean this is fixed now?

Maybe... I applied Christoph Lamprecht's for PAR::Packer 1.024.
Feel free to reopen this bug if the problem persists.

Cheers, Roderich