trunk r659 and inclusion of system libraries on Linux

25 views
Skip to first unread message

Florian Höch

unread,
May 8, 2009, 11:54:42 AM5/8/09
to PyInstaller
Hi,

I've had a problem with an (onefile) executable generated under Linux
with trunk r659. The binary worked fine on the system it was generated
on, but failed on others with a cryptic error ('U����8��]��u��}
��H �m�����j$: Error
156978068' with differing error numbers). So, I reverted the change
introduced in r652 and now the binary works. I've looked at the list
of libs included in both binaries, and these are the libs which are
extra in the r659-built binary:

libatk-1.0.so.0
libbz2.so.1
libcairo.so.2
libcrypto.so.0.9.8
libdl.so.2
libexpat.so.1
libfontconfig.so.1
libfreetype.so.6
libgcc_s.so.1
libgdk_pixbuf-2.0.so.0
libgdk-x11-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgthread-2.0.so.0
libgtk-x11-2.0.so.0
libICE.so.6
libm.so.6
libncurses.so.5
libncursesw.so.5
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpcre.so.0
libpng12.so.0
libpthread.so.0
libreadline.so.5
librt.so.1
libSM.so.6
libssl.so.0.9.8
libstdc++.so.6
libutil.so.1
libX11.so.6
libXau.so.6
libxcb-render.so.0
libxcb-render-util.so.0
libxcb.so.1
libxcb-xlib.so.0
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXext.so.6
libXfixes.so.3
libXinerama.so.1
libXi.so.6
libXrandr.so.2
libXrender.so.1
libXxf86vm.so.1
libz.so.1

I guess there is/are some that caused the problem I was having. Any
hints appreciated.

Giovanni Bajo

unread,
May 12, 2009, 9:03:52 AM5/12/09
to PyIns...@googlegroups.com

Hi Florian,

thanks for the report. It doesn't ring a bell right now, but it is
surely a bug I would like to investigate. I would appreciate if you
could find out which *exact* libraries cause the problem.

My first guess would be trying to remove only libX* and see if it starts.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com

Florian Höch

unread,
May 14, 2009, 7:09:41 PM5/14/09
to PyInstaller
I got a bit further. The main culprit turned out to be libdl, after
adding it to the exclusion list the executable ran on one of the
distributions I tested (Knoppix 6.1). I then added several other
excludes to fix some remaining issues under that distribution:
libcairo (needs libglitz)
libgdk_pixbuf (lots of 'file not found' errors when it tries to access
non-existent icon files)
libpango (caused text in windows and other controls to appear as
boxes)

Now the executable (built under openSUSE 11) works as expected on
Knoppix 6.1, but not on Ubuntu Jaunty or Fedora 10 (it fails without
error, just exiting). I'll try if I can pinpoint the problem or
atleast get the executable to spit out a meaningful error message.

Florian Höch

unread,
May 24, 2009, 8:30:43 AM5/24/09
to PyInstaller
I found a solution that works for me with the four distributions I
tested the app on. I had to exclude the following libraries:

libcairo.so.2
libdl.so.2
libfontconfig.so.1
libgdk_pixbuf-2.0.so.0
libgdk-x11-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgthread-2.0.so.0
libgtk-x11-2.0.so.0
libpango* (all the libpango stuff)
libpthread.so.0
librt.so.1
libX* (all the libX stuff)

Giovanni Bajo

unread,
May 25, 2009, 12:55:59 PM5/25/09
to PyIns...@googlegroups.com
On 5/24/2009 2:30 PM, Florian Höch wrote:
> I found a solution that works for me with the four distributions I
> tested the app on. I had to exclude the following libraries:
>
> libcairo.so.2
> libdl.so.2
> libfontconfig.so.1
> libgdk_pixbuf-2.0.so.0
> libgdk-x11-2.0.so.0
> libgmodule-2.0.so.0
> libgobject-2.0.so.0
> libgthread-2.0.so.0
> libgtk-x11-2.0.so.0
> libpango* (all the libpango stuff)
> libpthread.so.0
> librt.so.1
> libX* (all the libX stuff)

Hi Florian,

it doesn't sound any specific ring to me. I can't understand why we
should exclude libgtk or libX from the build... there has to be
something that escapes me.

I believe that the problem lies elsewhere: there is probably something
*missing* from the build. Can you please check with strace? It should be
rather straightforward:

* Build a clean package with PyInstaller (all libraries included)
* Move to the machine where the package does not work.
* Run "strace -ff ./programname 2>&1 1>strace.log"
* grep the strace log for all dynamic libraries that get loaded, and
see which are loaded from /lib instead of the temporary directory.

(if you could send me the strace.log it would also be great, but please
check if it contains sensitive information)

Florian Höch

unread,
May 25, 2009, 1:58:43 PM5/25/09
to PyInstaller
Ok, thanks for the suggestions. I've run strace, and uploaded the log
here:

http://hoech.net/dispcalGUI/tmp/dispcalGUI-onefile-strace.log

The system I use only for building and testing, so there's no
sensitive data atm. The error is at line 2002 in the log, but I still
have no idea what actually causes it. It seems all files are loaded
from the temp dir as should be.
Reply all
Reply to author
Forward
0 new messages