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

[Charles Wilson]

On 6/20/2011 3:32 AM, Marco atzeri wrote:
> 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.

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

Hm.  This is a big, general problem: it means you libtool can't build
ANY fortran DLLs -- because they will all need libfortranbegin.a  IIRC,
the fortran startup object used to be *an object*, so it didn't trigger
this problem.

We're really collecting more and more reasons to rewrite the support in
libtool for the gcc compiler to just use $(CC) (or $CXX, etc) to link,
and NOT muck around with detecting all these objects and compiler
runtime libs and crud -- which we currently do so that libtool can link
using $(LD) directly.

Now, even if we DID do that, it won't "fix" the problem below:

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

Well, in this case, libtool is doing what it is programmed to do: don't
allow DLLs to depend on static libs.  As I said earlier, this is in
general a good rule for win32.

You've found a case where this heuristic fails, and violating it does
not /appear/ to cause any problems for this particular application.

I think, in this case, overriding the autoconf variable as you are doing
is actually the right procedure!  I'm leery of making this a configure
option (--allow-static-deps) because then the uninitiated might use it
all the time...and invariably they WILL run into the problems I warned
about.


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

But we still have the problem with fortran DLLs in general.  Sigh.

--
Chuck