Hi, On Sat, 26 Jun 2004, Paul C. Leopardi wrote:
g++ -shared -o symbols.oct symbols.o probably_prime.o differentiate.o findsymbols.o numden.o syminfo.o symlsolve.o sumterms.o sym-bool.o sym-create.o ov-ex.o ov-vpa.o ov-ex-mat.o ov-relational.o op-ex-mat.o op-ex.o op-vpa.o -L/usr/lib64 -lginac -L/usr/lib64 -lcln -lgmp -L/usr/lib64/octave-2.1.55 -loctinterp -loctave -lcruft -lreadline -lncurses -ldl -lm -L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3 -L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../lib64 -L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/libginac.a(add.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib64/libginac.a: could not read symbols: Bad value collect2: ld returned 1 exit status
Any ideas on how I can get libginac to use "-fPIC"? Do I need to recompile libginac from source?
If libginac only comes as static library (as the error indicates), then yes, it needs to be rebuild from source. I assume the above binary (symbols.oct) is not just a shared library which later is linked to an application, but instead is a DSO loaded dynamically by the application (via dlopen). In the former case a work-around would be to not link libginac to symbols.oct but defer this linking to the application itself.
Should I report this to the octave-forge people as a bug? Is it a bug in Ginac? In packaging?
Sort of bug in Ginac (would be fixable by either providing a shared libginac.so, or using -fPIC for compiling libginac.a's objects). Ciao, Michael.