[rt.cpan.org #52407] pp creates par-user/ in /, not /tmp

[Naveed Massjouni via RT]

Sun Dec 13 03:06:27 2009: Request 52407 was acted upon.
Transaction: Correspondence added by IRONCAMEL
   Queue: PAR-Packer
 Subject: pp creates par-user/ in /, not /tmp
   Broken in: 1.001
Severity: Normal
   Owner: RSCHUPP
  Requestors: sw...@cpan.org
  Status: open
 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=52407 


On Fri Dec 11 18:40:37 2009, IRONCAMEL wrote:
 I got the same error on my local ubuntu machine and several redhat
 servers we have.  I fixed it by changing one line in a file in the 't'
 directory called test-proc:
 
 $ diff test-proc.orig test-proc
 16c16
  print PAR_TEMP = $ENV{PAR_TEMP}\n;
 ---
  print PAR_TEMP = $ENV{PAR_GLOBAL_TMPDIR}\n;
 
 Is this a good solution?

By the way, the tests fail even when I run them as root, because
t/30-current_exec.t checks to see if the tmp dir was correctly set in
the environment, which it wasn't.  The above patch made the tests pass.

Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5

[Mattia Barbon]

[Sorry, missed this mail, it ended up in the par folder, that I do not 
read that often...]


Roderich Schupp wrote:

On Thu, Nov 12, 2009 at 10:21 AM, Steffen Mueller
nj88ud...@sneakemail.com wrote:

Unfortunately, there's long been an issue with running PAR::Packer generated
binaries from RH4 on RH5. It's a recurring one that's regularly raised on
par@perl.org (including a recent post by yourself). It's also an issue that
*seems* to be isolated to RedHat Linuxes. I've never used RedHat and do not
plan to do so. Therefore, I can't debug it. Nobody else has managed to do
so. Your specific issue may or may not be the same as the historic one since
it's using tons of external Wx shared libraries.


I don't have RedHat either :) But I'm convinced that Erez' particular problem
would probably show on my Debian system, too (if configured in a certain way).
The error messages for the missing *.so files are generated from Wx.pm
based on a (build-time generated) list in Wx/Mini.pm.

For some reason, Wx.pm doesn't trust the inter-library dependencies among the
many wxwindows shared libraries that are present in the libraries themselves
(i.e. NEEDED tags for Elf based systems e.g. Linux), but tries to preload
these libraries itself (though it has no immediate use for them since all
access from Perl to wxwindows goes thru the glue libraries provided by Wx).


  Rest assured that the code is not there because I like to complicate 
people's life ;-)  It is required under Win32 because you can't always 
trust wxWidgets' DLLs to be in the DLL search path (or in the same 
directory as Wx.dll).


  I can't remember if the code is enabled under Linux because of an 
oversight or if there are (or were) situations when it was necessary.



To sum up: complain to the maintainer of the Wx module to stop using .so names.


  I'll disable that code in the next release, and we will see if 
anything breaks...


Thanks!
Mattia