Re: Wxpar executable created on Linux RH4 generates errors when running on LinuxRH5
On Sun, Oct 25, 2009 at 7:50 AM, Erez David int...@gmail.com wrote: On the machine where have create the package I have seen this in the lib directory: [cadBuild_rh48_32-erezd] Wx_installer l /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Alien/wxWidgets/gtk_2_8_10_uni/lib/|grep libwx_baseu-2.8.so lrwxrwxrwx 1 root root 20 Oct 19 15:34 libwx_baseu-2.8.so - libwx_baseu-2.8.so.0 lrwxrwxrwx 1 root root 24 Oct 19 15:34 libwx_baseu-2.8.so.0 - libwx_baseu-2.8.so.0.6.0 -rwxr-xr-x 1 root root 1547248 Oct 19 15:34 libwx_baseu-2.8.so.0.6.0 and it is the same for all the lib files. The libwx_baseu-2.8.so is a link to libwx_baseu-2.8.so.0 which itself is a link to libwx_baseu-2.8.so.0.6.0 ... Maybe this is what confuses wxpar...? Maybe. But these links are correct and as expected. Cheers, Roderich
Re: Wxpar executable created on Linux RH4 generates errors when running on LinuxRH5
Hi Roderich,
On the machine where have create the package I have seen this in the lib
directory:
[cadBuild_rh48_32-erezd] Wx_installer l
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Alien/wxWidgets/gtk_2_8_10_uni/lib/|grep
libwx_baseu-2.8.so
lrwxrwxrwx 1 root root 20 Oct 19 15:34 libwx_baseu-2.8.so -
libwx_baseu-2.8.so.0
lrwxrwxrwx 1 root root 24 Oct 19 15:34 libwx_baseu-2.8.so.0 -
libwx_baseu-2.8.so.0.6.0
-rwxr-xr-x 1 root root 1547248 Oct 19 15:34 libwx_baseu-2.8.so.0.6.0
and it is the same for all the lib files.
The libwx_baseu-2.8.so is a link to libwx_baseu-2.8.so.0 which itself is a
link to libwx_baseu-2.8.so.0.6.0 ...
Maybe this is what confuses wxpar...?
Thanks
Erez
On Thu, Oct 22, 2009 at 11:34 PM, Roderich Schupp
roderich.sch...@googlemail.com wrote:
On Thu, Oct 22, 2009 at 2:00 PM, Erez David int...@gmail.com wrote:
As you can see all the library files are extended with .0
If I rename this files and remove the .0 (E.g: libwx_baseu-2.8.so.0
- libwx_baseu-2.8.so ...) it works fine and doesn't generate the
error...
I hope this will help for debuging the problem.
Hmm, unfortunately the .0 extension should be correct, since this
should equal the internal soname of the shared library.
You can check this:
$ readelf -d /your/installed/libwx_gtk2u_richtext-2.8.so.0 | grep SONAME
0x000e (SONAME) Library soname:
[libwx_gtk2u_richtext-2.8.so.0]
My guess is that some misconfigured software uses the names without
the extension. It works on the machine where you packed your program,
because it probably has symlinks libwx_gtk2u_richtext-2.8.so -
libwx_gtk2u_richtext-2.8.so.0
installed (the symlink without .0 usually comes from a development
package and
is only needed if you want to build software that uses the wx libs).
Unzip the packed executable into a temp directory and grep for e.g.
libwx_gtk2u_richtext-2.8.so
$ unzip .../installer
$ grep -rl libwx_gtk2u_richtext-2.8.so .
Then examine all listed files whether they contain the string
libwx_gtk2u_richtext-2.8.so
without a trailing .0 (for binary files, run them thru strings -a ...).
On my machine, the prime suspect is Wx/Mini.pm which contains
$Wx::dlls = $VAR1 = {
'base' = 'libwx_baseu-2.8.so',
'richtext' = 'libwx_gtk2u_richtext-2.8.so',
...
};
This hash is referenced in sub _load_dll in Wx.pm which indeed tries to
Wx::_load_file the hash values. Note that I don't have Wx::Perl::Packager
installed, hence YMMV.
Cheers, Roderich
Re: Wxpar executable created on Linux RH4 generates errors when running on LinuxRH5
On Thu, Oct 22, 2009 at 10:41 AM, Erez David int...@gmail.com wrote: 09:51:59 AM: libwx_baseu_net-2.8.so: cannot open shared object file: No such file or directory 09:51:59 AM: libwx_gtk2u_adv-2.8.so: cannot open shared object file: No such file or directory ... Does anyone knows what can be the cause for this error? Well, the most interesting part of the error message are the wx librarries that are NOT listed, e.g. libwx_baseu-2.8.so.0, libwx_gtk2u_core-2.8.so.0. If these were missing, too, you wouldn't even see the popup window with the error message. To determine where they went AWOL try the following steps: (1) Check the packed executable with (it's actually a zip archive) $ unzip -l ./installer for the missing libs. If they NOT listed, stop. (2) Run the packed executable once on the machine where it fails and look at the files below its cache directory, something like /tmp/par-USER/SHA1CHECKSUM If you're not sure that you're looking at the right cache directory: the SHA1CHECKSUM is the first line printed by $ strings -a ./install | tail -3 If you DON'T find the missing libs there, stop. (3) Run the packed executable under strace on the machine where it fails: $ strace -o strace.log -f -v ./installer and try to figure out why the libs can't be found. After successful extraction (you'll see open(.../missing_lib.so, O_RDWR ...)) look for failing system calls that mention missing_lib.so. We'll dig deeper, once we know how far you got with the above steps :) Cheers, Roderich
Re: Wxpar executable created on Linux RH4 generates errors when running on LinuxRH5
On Thu, Oct 22, 2009 at 2:00 PM, Erez David int...@gmail.com wrote:
As you can see all the library files are extended with .0
If I rename this files and remove the .0 (E.g: libwx_baseu-2.8.so.0
- libwx_baseu-2.8.so ...) it works fine and doesn't generate the error...
I hope this will help for debuging the problem.
Hmm, unfortunately the .0 extension should be correct, since this
should equal the internal soname of the shared library.
You can check this:
$ readelf -d /your/installed/libwx_gtk2u_richtext-2.8.so.0 | grep SONAME
0x000e (SONAME) Library soname:
[libwx_gtk2u_richtext-2.8.so.0]
My guess is that some misconfigured software uses the names without
the extension. It works on the machine where you packed your program,
because it probably has symlinks libwx_gtk2u_richtext-2.8.so -
libwx_gtk2u_richtext-2.8.so.0
installed (the symlink without .0 usually comes from a development package and
is only needed if you want to build software that uses the wx libs).
Unzip the packed executable into a temp directory and grep for e.g.
libwx_gtk2u_richtext-2.8.so
$ unzip .../installer
$ grep -rl libwx_gtk2u_richtext-2.8.so .
Then examine all listed files whether they contain the string
libwx_gtk2u_richtext-2.8.so
without a trailing .0 (for binary files, run them thru strings -a ...).
On my machine, the prime suspect is Wx/Mini.pm which contains
$Wx::dlls = $VAR1 = {
'base' = 'libwx_baseu-2.8.so',
'richtext' = 'libwx_gtk2u_richtext-2.8.so',
...
};
This hash is referenced in sub _load_dll in Wx.pm which indeed tries to
Wx::_load_file the hash values. Note that I don't have Wx::Perl::Packager
installed, hence YMMV.
Cheers, Roderich
