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

[Joao Cardoso]

"Steven G. Johnson" wrote:
> 
> > I had one problem: after `configure' found ATLAS, -latlas etc where
> > added to LIBS, and after that `configure' fail to compile other generic
> > test cases, as -lg2c was also needed!? I quicky solve it by forcing LIBS
> > to have -lg2c.
> > Perhaps your patch should instead add -latlas etc to FLIBS? I am not a
> > configure expert!
> 
> FLIBS should only be the libraries that are needed to link Fortran
> stuff,

And this is not the case? -latlas is only needed in the final Octave
link, to link against libcruft.a. It is not needed for linking other
source files.

> and they should be linked after LIBS anyway and should include
> -lg2c when that is needed.

-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.

> > Also, even if liblapack.so/a does not exists in the system,
> > libcruft/lapack-xtra is compiled, given multiply defined symbols on
> > libcruft.so/a creation. The solution is to remove lapack-xtra from the
> > `AC_OUTPUT(Makefile' list in configure.in.
> 
> No.  The correct thing is to remove the files in lapack-xtra/ from
> lapack/, and the files in blas-xtra/ from blas/.  I think my patch
> mentioned this?  If not, it should have.

I don't agree, as it asks for the user manual intervention, losing the
`automagic' of automake/autoconf/etc.
It would be better to conditionally create the Makefile list based on
what `configure' found, as libcruft/Makefile.in says:

  # (Some of the directories in libcruft may be only optionally built,
  #  e.g. if they are already present on the system.  For these, their
  #  dirname is substituted by configure and may be the empty string.)

But omitting the Makefile creation in libcruft/lapack-xtra isn't enough
(and really not necessary).
The libcruft/Makefile.in CRUFT_DIRS should have a @XLAPACK_DIR@, and as
you set LAPACK_DIR="" if -llapack if found, you should set
XLAPACK_DIR="" if it is not found. This is also true for blas-xtra.

At this point you must be saying: "why don't he do it?"
I don't know how to do it :), and I think that having a shared ATLAS is
important. "R" works with it, I tried, and I think that "rlab" should
also work.

> > I was able to build working shared libraries of ATLAS, but not of netlib
> > LAPACK... was anyone able to do it (with gcc-2.95.2)?
> 
> What sort of problems were you having?  (LAPACK has an annoying build
> procedure.  It should really be fixed, but it is like pulling teeth to
> get these Fortran guys to use autoconf/automake.)

I had no problem building LAPACK, and the static archive works OK. If I
specify `-fpic' to latter build a shared lib, again everything works OK,
and the liblapack.a work fine; but if I extract the object files from
libpack.a and build a shared lib, at run-time I get an OS specific
error. My OS is SCO, uncommon.

If nobody else has such problems with this procedure, than it is a g77
problem with some LAPACK source file on my system -- it already happened
in the past and was an `as' i386 related bug deployed by g77.
The procedure works OK for ATLAS.

Thanks,
Joao

> Steven



-----------------------------------------------------------------------
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
-----------------------------------------------------------------------