Creating executables on Linux

[Thorsten Kampe]

Hi,

I've never been successful creating a (stand-alone) executable on Linux.
While the creation process succeeds and I can run the stand-alone
executable on the machine where I created it, it will not run on other
hosts (SUSE Linux Enterprise Server 10 SP2 for instance).

./my_application
Traceback (most recent call last):
File "<string>", line 14, in <module>
File "/home/thorsten/python/pyinstaller/iu.py", line 436, in
importHook
File "/home/thorsten/python/pyinstaller/iu.py", line 495, in doimport
File "/home/thorsten/python/pyinstaller/iu.py", line 297, in getmod
File "/home/thorsten/python/pyinstaller/archive.py", line 468, in
getmod
File "/home/thorsten/python/pyinstaller/iu.py", line 109, in getmod
ImportError: /lib/libc.so.6: version `GLIBC_2.9' not found (required by
/tmp/_MEIPbsjVL/libQtCore.so.4)

On this machine I am running glibc-2.4 (the latest one for this
machine), on the machine where the stand-alone was created, it's 2.12.1.

Does PyInstaller on Linux depend on the glibc version? If so, doesn't
that defy the whole sense of creating stand-alone executables?

Thorsten

[Giovanni Bajo]

PyInstaller just packs the files on your computers together. If those
files depend on a specific GLIBC, the only solution would be to ship
glibc as well, but this has proven to create more problems than it
solves. In a word, PyInstaller cannot compensate for the absence of an
ABI.

Our suggestion is to try and execute PyInstaller on the older operating
system that you plan to support. This usually achieves the best results,
because GLIBC developers maintain backward binary compatibility.
--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com

My Blog: http://giovanni.bajo.it
Last post: Compile-time Function Execution in D

[Daniel Hyams]

I would be interested in a definitive answer to this too, but I'm not sure that pyinstaller can get around ABI versioning restrictions in the underlying C library.  It does make things harder for distributing apps on Linux.

The way I work around this, with good success, is to purposefully build the executable on as old of a distribution as you can.  For example, I build on SuSe 11.1, and the executable I generate from that runs on a wide range of other systems.  But as soon as I hit one that uses an older ABI of glibc than SuSe 11.1, I'm in the same boat as you are.  So it's not really solving the problem, just mitigating it.

FWIW, I tried building on a newer machine and copying over libc to the older machine (just in the directory with my executable, not system wide), when I first started this process.  I didn't really expect it to work, and it didn't; the executable died in a twitching heap.

--
You received this message because you are subscribed to the Google Groups "PyInstaller" group.
To post to this group, send email to pyins...@googlegroups.com.
To unsubscribe from this group, send email to pyinstaller...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyinstaller?hl=en.

--
Daniel Hyams
dhy...@gmail.com

[Martin Zibricky]

Daniel Hyams píše v Čt 02. 12. 2010 v 10:04 -0500:

> I would be interested in a definitive answer to this too, but I'm not
> sure that pyinstaller can get around ABI versioning restrictions in
> the underlying C library. It does make things harder for distributing
> apps on Linux.

If you need newer tools (like python 2.6, Qt 4.6, ...) on older linux
distributions you need to compile it yourself or I would recommend
trying gentoo prefix, which automates compilation and installation of
those tools.

http://www.gentoo.org/proj/en/gentoo-alt/prefix/

Hower, to setup such an environment is a bit harder.