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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
