Hi, You aren't going to be able to avoid the glibc dependency. Most times you can simply package (with cx_Freeze) the application on an "older" machine that has all of the glibc requirements that you are looking for. glibc is backwards compatible but not forwards compatible. That's why I use CentOS 5.x for packaging instead of what I normally use day-to-day (Fedora 13).
The only other option is to force the base executables to be built statically and all Python extensions you are using to be included statically as well -- judging from the list of extensions you are using that isn't going to work for you. So see if you can get an "old" distribution and build with that. I use a virtual machine (via Oracle VirtualBox) for that purpose which works quite well. Hope that helps you out. Anthony On Mon, Jul 12, 2010 at 12:25 PM, julian bilcke <julian.bil...@iscpif.fr> wrote: > Hi ! > > I have a new question regarding packaging of standalone Python application > using cx_freeze. > > Just in preamble, a bit of context : > > - We are building an open-source text-mining python server application for > research, using a lot of existing python libs > - we have the following dependencies: Numpy, Twisted, (py-)BerkeleyDB, > zope.interface, simplejson, yaml > > - Still, we have been asked to make it a "no additional bumper required" > application (example of use cases: restrained environment without network > connection, no admin access or install, or usb-key bootable app..) > - we still though this was feasible, so we decided to to build 4 versions > (linux32, linux64, mac, win32) > - We turned to tools like py2exe/app, pyinstall, and cx_freeze to make the > job easier > > But this task appear to be difficult, because of these heavy dependencies > (numpy, berkeley..) > > We have some results for Windows (binaries looks portable), but on other > platforms, like mac or linux, > this looks hard. > > By example, I tried to run our app under debian32 (it was built with > cx_freeze under ubuntu32) > but it failed : issue with numpy.so, which has an external dependency on > glibc at a particular version. > I don't have any idea on how resolve this kind of dependency without using > the standard system packaging system.. > > So, my question is : > - does someone had to do something similar ? is there a solution to this > kind of issue (handling of external dependencies/libs) ? > - it is even feasible to package such program ? or should we abandon and > instead turn to a "local install" packaging ? > > > if someone here had to deal with this kind of packaging, and has any hint, I > would be very, very thankful ! > > Julian > > ps: > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > cx-freeze-users mailing list > cx-freeze-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cx-freeze-users > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ cx-freeze-users mailing list cx-freeze-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cx-freeze-users
