[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Building 2.1.45 on cygwin
From: |
John W. Eaton |
Subject: |
Building 2.1.45 on cygwin |
Date: |
Sat, 22 Feb 2003 12:33:09 -0600 |
On 22-Feb-2003, Andy Adler <address@hidden> wrote:
| Compiling 2.1.45 on cygwin gives the following error:
|
| In libcruft, the following symbols are undefined
|
| lapack/spotf2.o(.text+0x23b):spotf2.f: undefined reference to `_sgemv_'
| lapack/spotf2.o(.text+0x275):spotf2.f: undefined reference to `_sscal_'
| lapack/spotrf.o(.text+0x268):spotrf.f: undefined reference to `_ssyrk_'
| lapack/spotrf.o(.text+0x34a):spotrf.f: undefined reference to `_sgemm_'
| lapack/spotrf.o(.text+0x3e6):spotrf.f: undefined reference to `_strsm_'
| collect2: ld returned 1 exit status
| make[1]: *** [libcruft.dll] Error 1
| make[1]: Leaving directory `/usr/src/octave-2.1.45/libcruft'
| make: *** [libraries] Error 2
|
| This can be fixed by stubbing them out.
|
| $ cat foobar.c
| int sgemv_(int foo) { return 1; }
| int sscal_(int foo) { return 1; }
| int ssyrk_(int foo) { return 1; }
| int sgemm_(int foo) { return 1; }
| int strsm_(int foo) { return 1; }
| $ gcc -c foobar.c -o foobar.o
|
| And a slight modification to the makefile
|
| $ diff -c Makefile Makefile.orig
| *** Makefile Sat Feb 22 12:09:16 2003
| --- Makefile.orig Sat Feb 22 12:08:54 2003
| ***************
| *** 107,113 ****
|
| libcruft.$(SHLEXT): $(CRUFT_PICOBJ)
| rm -f $@
| ! $(SH_LD) $(SH_LDFLAGS) $(SONAME_FLAGS) -o $@ $^ $(LINK_DEPS) foobar.o
|
| $(CRUFT_OBJ):
|
| --- 107,113 ----
|
| libcruft.$(SHLEXT): $(CRUFT_PICOBJ)
| rm -f $@
| ! $(SH_LD) $(SH_LDFLAGS) $(SONAME_FLAGS) -o $@ $^ $(LINK_DEPS)
|
| $(CRUFT_OBJ):
|
|
| ------------------------
| These functions don't seem to be used anywhere else, so
| this seems to work.
| Is there a better way of handling this kind of situation?
I added the actual blas and lapack functions to the source tree, so
this is fixed in CVS.
These functions are referenced by ranlib/setgmn.f, which was recently
changed to use lapack instead of linpack. I didn't notice on my
system because Octave never actually calls setgmn, and the linker on
my system apparently doesn't complain about the missing symbol because
it is never actually needed and it allows building static and shared
libraries with references to undefined symbols.
jwe