Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5
On Thu, Nov 12, 2009 at 10:21 AM, Steffen Mueller 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
Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5
Hi, I have finally was able to solve this problem using a workaround. The problem was that on my RH4 machines the .so files were link to .so.0 files... So, when the par was opened and ran it looked for .so files while the files in the /tmp/par tmp dir had .so.0 extenssion. The solution for that was creating my own lib directory and copy there all the library (.so file) I needed (with .so extenssion) Then, I ran pp (not wxpar...) with -l switch for all the library files I stored in my own lib directory. That workaround solve the problem for me. Thanks. Erez On Thu, Nov 12, 2009 at 11:21 AM, Steffen Mueller wrote: > 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
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
