Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Marco atzeri]

On 6/17/2011 5:49 PM, Charles Wilson wrote:
> On 6/17/2011 11:03 AM, Marco atzeri wrote:
> > Sorry Chuck,
> > but I can assure you that I am linking against shared dlls,
> > but the detection is incorrect.
>
> Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a,
> and foo-N.dll (plus the -lfoo incantation) you're using for which the
> detection fails?
>
> Maybe we can figure out why func_win32_libid() is failing.
>
> --
> Chuck

Hi Chuck,
I guess func_win32_libid() is not failing but the gcc/linker is
smarter than libtool expect; or that autoconf is misleading libtool.

At configure stage for "checking for Fortran 77 libraries of gfortran-4"

configure:28653: result:  -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin 
-lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32

And on "Makefile"
FLIBS =  -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin 
-lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32


Now in the gfortran package:

/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a
/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a
/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la
/lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a
/lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la

libgfortran is available as dynamic and static,
while libgfortranbegin is only static

libgfortranbegin.a is included as object in the build
of the dll/exe, while libgfortran.dll.a is used
for the linking with cyggfortran-3.dll

Similar thing happens for the few libraries
that are available only as static like SuiteSparse

checking for ccolamd in -lccolamd
result: yes

so
CCOLAMD_LIBS = -lccolamd

But Suitesparse libs are only static:
/usr/lib/libamd.a
/usr/lib/libbtf.a
/usr/lib/libcamd.a
/usr/lib/libccolamd.a
/usr/lib/libcholmod.a
/usr/lib/libcolamd.a
/usr/lib/libcsparse.a
/usr/lib/libcxsparse.a
/usr/lib/libklu.a
/usr/lib/libspqr.a
/usr/lib/libumfpack.a

so they are included as objects in the dll build.

For your notice, building octave with
"lt_cv_deplibs_check_method=pass_all"
works fine and the program pass all the tests,
while without it the program is unusable.


Regards
Marco