Hi all, I'm building a SWIG wrapper around a C++ class that uses the Judy Array Library, to be able to use this class as a python extension module. In order to be loaded by python, the extension module has to be compiled as a dynamic library. An additional constraint of my project requires this extension module to be "self-contained", ie it should not require an external dependency on the libJudy.so (it will be deployed on machines on which I cannot install anything).
Rolling the static libJudy.a and my C++ code into a dynamic library loadable in python works on a 32 bits machine, not on a 64 bits machine: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libJudy.a(JudyLDel.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC It seems to me that this would require libJudy to be compiled with -fPIC. Any reasons why doing so would not make sense? Thanks! Olivier ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
