building a linux executable

[Prateek]

Hello,

I'm trying to package my python program into a linux executable using
cx_freeze. The goal is that the user should require python on their
system.

I've managed to make the binaries on Fedora Core 6 and they run fine.
However, when I move to Ubuntu (tested on Ubuntu Server 7.04 and
xUbuntu Desktop 7.04), the program fails to run with the following
error:

ImportError: no module named _md5

_md5 being imported by the hashlib module because the import of
_hashlib.so failed.

When I try to import the _hashlib module manually, I see that it
cannot find libssl.so.6 (The _hashlib module in the standard python
installation which came with Ubuntu works just fine). If I manually
copy the libssl.so.6 file from FC6 (its really a symlink pointing to
libssl.so.0.9.8b) to Ubuntu and make the symlink in /lib, it works
fine (the next error is related to libcrypto, libxslt and libjpeg (i'm
also using libxml, libxsl and PIL in my application).

I've scoured the net and it seems that _hashlib.so is dynamically
linked to libssl which is not being "integrated" into the build by
cx_Freeze. Similarly, there are other files with the same problem.

Does anyone have any idea how to make cx_Freeze make a linux
executable which is portable across *nix distros?

Thanks in advance,
-Prateek Sureka

 

[Bjoern Schliessmann]

I'm trying to package my python program into a linux executable
using cx_freeze. The goal is that the user should require python
on their system.

I've managed to make the binaries on Fedora Core 6 and they run
fine. However, when I move to Ubuntu (tested on Ubuntu Server 7.04
and xUbuntu Desktop 7.04), the program fails to run with the
following error:

I'm sorry I cannot help, but how many linux distros have no python
installed or no packages of it?

Regards,


Björn

 

[Paul Boddie]

I'm sorry I cannot help, but how many linux distros have no python
installed or no packages of it?

It's not usually the absence of Python that's the problem. What if
your application uses various extension modules which in turn rely on
various libraries (of the .so or .a kind)? It may be more convenient
to bundle all these libraries instead of working out the package
dependencies for all the target distributions, even if you know them
all.

Paul

 

[Bjoern Schliessmann]

It's not usually the absence of Python that's the problem. What if
your application uses various extension modules which in turn rely
on various libraries (of the .so or .a kind)? It may be more
convenient to bundle all these libraries instead of working out
the package dependencies for all the target distributions, even if
you know them all.

True, thanks for clarification.

Regards,


Björn

 

[Paul Boddie]

True, thanks for clarification.

Any suggestions, then? ;-)

I've also run into similar issues with cx_Freeze: I wanted to package
a game written using PyGame, which itself requires some SDL libraries,
which in turn require different libraries like smpeg (if I remember
correctly). It gets to the point where one is effectively building a
Python distribution (another question asked recently but not answered
sufficiently), which has minimal linkage to other libraries - perhaps
the system C libraries, some X11 libraries, and nothing more. Some
ideas about doing that successfully (perhaps LSB enters the picture)
would be quite useful.

Paul

 

[Prateek]

It's not usually the absence of Python that's the problem. What if
your application uses various extension modules which in turn rely on
various libraries (of the .so or .a kind)? It may be more convenient
to bundle all these libraries instead of working out the package
dependencies for all the target distributions, even if you know them
all.

Paul

Thanks Paul,

So I've bundled all the extension modules (cx_Freeze helped me out
with that). Here is what I did:

if sys.platform.startswith("linux"):
import [add a bunch of imports here]

This import statement immediately imports all modules which will be
required. Hence, cx_Freeze is easily able to find them and I can put
all the .so files with the distro.

The problem is that some of these .so files (_hashlib.so) are hard-
linked to /lib/libssl.so and /lib/libcrypto.so. I cannot simply just
copy those (libssl/libcrypto) files into the distribution folder (and
cx_Freeze won't do anything about them because they are not Python
modules). I need a way to figure out how to get _hashlib.so to refer
to a libssl.so which is in the same directory (I would have thunk that
it should use the PATH environment variable - apparently not).

This seems to be a simple enough problem, doesn't it??

NB: Has the community come up with a better way to distribute Python
executables on linux? I'd also like to hear from folks who've got
linux distributables of medium to large scale python programs...

 

[Carl Banks]

On 24 Okt, 14:20, Bjoern Schliessmann <usenet-

(e-mail address removed)> wrote:

It's not usually the absence of Python that's the problem. What if
your application uses various extension modules which in turn rely on
various libraries (of the .so or .a kind)? It may be more convenient
to bundle all these libraries instead of working out the package
dependencies for all the target distributions, even if you know them
all.

Paul

Thanks Paul,

So I've bundled all the extension modules (cx_Freeze helped me out
with that). Here is what I did:

if sys.platform.startswith("linux"):
import [add a bunch of imports here]

This import statement immediately imports all modules which will be
required. Hence, cx_Freeze is easily able to find them and I can put
all the .so files with the distro.

The problem is that some of these .so files (_hashlib.so) are hard-
linked to /lib/libssl.so and /lib/libcrypto.so. I cannot simply just
copy those (libssl/libcrypto) files into the distribution folder (and
cx_Freeze won't do anything about them because they are not Python
modules). I need a way to figure out how to get _hashlib.so to refer
to a libssl.so which is in the same directory (I would have thunk that
it should use the PATH environment variable - apparently not).

The environment variable you want is LD_LIBRARY_PATH.

Also, if you're not aware, the ldd command can print out the library
dependencies.

This seems to be a simple enough problem, doesn't it??

NB: Has the community come up with a better way to distribute Python
executables on linux? I'd also like to hear from folks who've got
linux distributables of medium to large scale python programs...

Since most Linux systems have Python installed these days, the impetus
isn't quite as strong, even given the issues brought up here.


Carl Banks

 

[Bjoern Schliessmann]

Any suggestions, then? ;-)

Not really; I've got a vaguely similar problem myself -- several
Debian systems with Python 2.4 and Python 2.5. But modules I need
(wxWidgets 2.8 and Twisted) aren't available as Python 2.5 packages
for Debian, so I'm stuck with 2.4. Packages from unstable won't
work because Twisted has a binary part that is linked against
another libc. I don't really want to compile and install manually
from tarballs everywhere, and building .deb packages with Python is
complicated.

Regards,


Björn

 

[BlueBird]

Hi,

Some time ago, I compiled a small list of tools to perform the some
"python executable bundling" tasks.

It might be useful for you. Here is the list:

http://www.freehackers.org/Packaging_a_python_program


Philippe