Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5
[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
Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5
Hi David, Erez David wrote: I am trying to create an executable using wxpar which will work on both Linux RH4 and Linux RH5.. For this purpese I am using Linux RH4 32bit. 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'm sorry to be of so little help. I hope somebody else can fill the gap. Maybe Mark Dootson, the author of wxpar, has something to contribute to this? Best regards, Steffen
Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5
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). Unfortunately, the list of libraries in Wx/Mini.pm uses the *.so names. But the .so name is usually a symlink to ...so.1 or such and this symlink is only needed for building software (in contrast to just running a wxwindows-based application). That's why distros usually package the actual .so.N files into one package and the .so symlinks into another development package. Hence if you run any application using Wx.pm on a machine that hasn't accidentally installed the dev wxwindows package, you'll encounter Erez' problem. (I bet the Debian maintainer knows that, too, since the Debian package for Perl module Wx (libwx-perl) actually depends (though indirectly) on the development package (libwxgtk2.8-dev) for wxwindows.) To sum up: complain to the maintainer of the Wx module to stop using .so names. Cheers, Roderich
