Thu Feb 04 03:03:13 2010: Request 42986 was acted upon.
Transaction: Correspondence added by TJC
Queue: PAR
Subject: PAR-based modules use system XS modules over included modules
Broken in: 0.984
Severity: Important
Owner: Nobody
Requestors: t...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=42986 >
Sorry, jumping back into this bug again after a long break.
The workaround I was using was simply to ensure the target system didn't
install much at all into the system libraries, thus ensuring no
conflicts, and then forgot about the issue.
I've noticed the problem still seems to exist, even with the PAR being
built on an identical system, so I'm sure the shared objects should be
compatible. In fact, the PAR and parl executables were built on one
system, and installed on the other, seeming to indicate binary
compatibility between the two.
The system-installed XS module's shared-library is loaded in preference
to the one included in the PAR, thus causing DynaLoader to die.
(in this case, it's Digest::SHA1 and Digest/SHA1.so)
Is there anything else I can check in the meantime, that would be
preventing the par-included SHA1.so to be loaded? I have verified it is
included in the PAR.
thanks.
