Has anyone built octave-forge on SuSE 9.1 AMD64?
Hi all, I'm trying to install octave-forge-2004.02.12 downloaded from http://sourceforge.net/projects/octave/ and ./configure fails with the following error message: checking for mkoctfile... mkoctfile /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld: cannot find -lncurses collect2: ld returned 1 exit status configure: error: Could not run mkoctfile I have submitted this as bug 980116 at http://sourceforge.net/projects/octave/ Has anyone successfully built octave-forge on SuSE 9.1 AMD64? How? Thanks
On Sat, Jun 26, 2004 at 12:52:36PM +1000, Paul C. Leopardi wrote:
Hi all, I'm trying to install octave-forge-2004.02.12 downloaded from http://sourceforge.net/projects/octave/ and ./configure fails with the following error message:
checking for mkoctfile... mkoctfile /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld: cannot find -lncurses collect2: ld returned 1 exit status configure: error: Could not run mkoctfile
I have submitted this as bug 980116 at http://sourceforge.net/projects/octave/
Has anyone successfully built octave-forge on SuSE 9.1 AMD64? How? Thanks
Did you install the "ncurses-devel" package? Ciao, Marcus
Marcus, Thanks, that's what the problem was. I hadn't installed ncurses-devel. The ./configure script now works. Best regards On Saturday 26 June 2004 14:21, Marcus Meissner wrote:
On Sat, Jun 26, 2004 at 12:52:36PM +1000, Paul C. Leopardi wrote:
Hi all, I'm trying to install octave-forge-2004.02.12 downloaded from http://sourceforge.net/projects/octave/ and ./configure fails with the following error message:
checking for mkoctfile... mkoctfile /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/ bin/ld: cannot find -lncurses collect2: ld returned 1 exit status configure: error: Could not run mkoctfile
I have submitted this as bug 980116 at http://sourceforge.net/projects/octave/
Has anyone successfully built octave-forge on SuSE 9.1 AMD64? How? Thanks
Did you install the "ncurses-devel" package?
Hi all, Thanks to Marcus Meissner, ./configure now works. But make failed at: mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o xmlread.oct g++ -shared -o xmlread.oct xmlread.o xmltree_read.o xmltree.o -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: xmltree_read.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC xmltree_read.o: could not read symbols: Bad value collect2: ld returned 1 exit status I "fixed" this by defining CC="gcc -fPIC" at ./configure But now make fails at: 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? Should I report this to the octave-forge people as a bug? Is it a bug in Ginac? In packaging? Thanks
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.
Michael, Reply below. Best regards On Monday 28 June 2004 18:07, Michael Matz wrote:
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.
Thanks. I took the expedient route of putting NOINSTALL in main/symbolic. I'll do without Ginac for now.
participants (3)
-
Marcus Meissner -
Michael Matz -
Paul C. Leopardi