octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]