On Thu, Aug 28, 2008 at 4:22 PM, Gabor Szabo <szabgab@gmail.com> wrote:
> At start-up I get a warning pop-up with the following text:
>
> libwx_gtk2_html-2.8.so.0: cannot open shared object file: No such file
> or directory
>
> If I click on the details I get this:
>
> libwx_gtk2_stc-2.8.so: cannot open shared object file: No such file or directory
> libwx_base_net-2.8.so.0: cannot open shared object file: No such file
> or directory
> libwx_gtk2_html-2.8.so.0: cannot open shared object file: No such file
> or directory

Are you sure that this is the exact error message?
Because a slightly different one: it's always complaining about
libwx_....so , not ...so.0. That's also what I see when running
padre under strace.

> but I though I included all 3:
> using this script: http://svn.perlide.org/padre/trunk/create_exe

Your build script is OK: running unzip on padre shows that
the libs are included and looking at /tmp/par-USER/....
shows that they have been correctly extracted into the top level
cache directory. Also, the final executable runs with LD_LIBRARY_PATH
set to this directory so the should be found by the runtime linker.

But I think the run time linker is not to blame here. The telltale sign
is that the above names dont't end in ...so.0. The latter are the
names that are registered in the shared libs, both for their own internal
name and as references to other libwx libs. These names are indeed
used in lookup that show up under strace and the correctly resolved.
I think wxwidgets does a little shared lib lookup itself (by
explicitly calling dlopen)
and this is somehow misconfigured:
- it looks for the wrong names (the ...so name is only a symlink and
  only present when you have some wx dev package installed, it
  should look for the internal soname which ends in ...so.0)
- the search path for looking for these shared libs is totally strange,
  esp. it obviously doesn't respect LD_LIBRARY_PATH

Cheers, Roderich