Re: patch to make octave check for ATLAS BLAS libs, etcetera

[Joao Cardoso]

"John W. Eaton" wrote:
> 
> On 27-Apr-2000, Joao Cardoso <address@hidden> wrote:
> 
> | -lg2c correctly appears in FLIBS, but not (correctly) in LIBS. The fact
> | that -lg2c does not appears in LIBS but -latlas appears produces
> | undefined references when linking pure C code:
> 
> | [jcard] gcc ca.c -o ca -lf77blas -lcblas -latlas -lm
> | Undefined                       first referenced
> |  symbol                             in file
> | e_wsfe                              /usr/local/lib/libf77blas.so
> | do_fio                              /usr/local/lib/libf77blas.so
> | s_stop                              /usr/local/lib/libf77blas.so
> | s_wsfe                              /usr/local/lib/libf77blas.so
> |
> | This might be particular to my system, as it compiles and runs OK with
> |
> |    gcc -Wl,-z -Wl,nodefs ca.c -o ca -lf77blas -lcblas -latlas -lm
> |
> | as I say to the linker to ignore undefined symbols.
> 
> Sure, that will probably work fine until you hit some case that
> requires one of those undefined symbols that you chose to ignore.  :-)

Shure. I was only trying to show that it is wrong (on my system and with
shared libs) to add -latlas etc to LIBS, because after that point
`configure' always fail to compile any file! And I am not the only one:

  Stef Pillaert wrote:
  > 
  > > On Mon, 17 Apr 2000, Stef Pillaert wrote:
  > > > int main() {
  > > > gethostname()
  > > > ; return 0; }
  > > > configure:4083: checking size of short
  > > > configure:4102: gcc -o conftest -g -O2  -g
  > > > conftest.c -llapack -lf77blas -lcblas -latlas -lm  1>&5
  > > > /usr/bin/../lib/liblapack.so: undefined reference to `e_wsfe'
  > > > [...]

> The symbols that you are ignoring are from the Fortran (f2c/g2c)
> run-time library.  Apparently libf77blas library uses the STOP
> statement and maybe also does a little I/O.
> 
> This must not be pure C code,

Nop. look above.

> since it seems to reference Fortran
> run-time stuff.  If the source for f77blas really is all C, then I'd
> guess that at least part of it was generated by f2c.

I dont think so. In the ATLAS source directory (f2c used to put a header
`f2c generated file'):

  bash-2.02# find . -name \*.c -exec fgrep -li f2c {} \;
  ./config.c
  ./interfaces/blas/C/testing/c_xerbla.c

and the reference is:
  #ifdef F77_Char
   srname = F2C_STR(F77_srname, XerblaStrLen);
  #endif

but it is from the testing directory.

> It may be that the functions that you call can never access the
> undefined functions, so you are OK.
> 
> Do you see the same unresolved references if you link to the static
> (.a) library?

No.

>  If not, then you are probably OK.

The problem is that Octave `configure' *fail* after that point. (adding
-latlas etc to LIBS)

> The dynamic linkers
> on some systems seem to want to resolve all symbols in all functions
> in shared libraries.
> 
> jwe

Thanks
Joao



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------