> /usr/bin/ld: /usr/lib//libJudy.a(Judy1Test.o): relocation > R_X86_64_32S against `a local symbol' can not be used when making a > shared object; recompile with -fPIC > /usr/lib//libJudy.a: could not read symbols:
Weird. I don't have an answer, but I recall when we developed libJudy in 1999-2001, we didn't even try to ship a shared library version because the dynamic linking basically ate up all of the performance gains. So, yes, libJudy.a is archive only, on purpose. You are using a -shared option, which might or might not have something to do with it, not sure, but anyway, I can't see why a compiler should be unwilling to "fold" (hard-link) *.o files from a *.a file into some code that remains dynamically linkable later. If that's even what you are doing. Alan Silverstein ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
