[Mingw-users] RE: Building DLLs using MinGW & libtool

[Howard C. <hy...@hi...>]

I reported the same libtool bug a couple months ago. No response. The
libtool script assumes any file with a ".a" suffix is a static library, it
doesn't recognize that it's in fact a valid import library for a DLL. I
hacked my libtool script up to skip the filetype check and just blindly link
what I tell it to link. (Obviously it would be better in the long run to fix
the filetype check, but I knew what I was linking, and just wanted it to
shut up and do it...)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: lib...@gn... [mailto:lib...@gn...]On Behalf Of
> Bob Friesenhahn
> Sent: Tuesday, June 11, 2002 2:01 PM
> To: min...@li...
> Cc: li...@gn...
> Subject: Building DLLs using MinGW & libtool
>
>
> While attempting to build a DLL under MinGW, MSYS, using the CVS
> version of libtool and gcc 2.95.3-6, I see these warnings printed by
> libtool:
>
> *** Warning: linker path does not have real file for library -lgdi32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libgdi32 and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/local/lib/libz.a
>
> *** Warning: linker path does not have real file for library -lm.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libm and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/local/lib/libz.a
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
>
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
>
> However, I see the file GDI32.DLL in my PATH in the directory
> "/c/WINDOWS/SYSTEM32/".  I have tried to add a -L option to reference
> that directory, but it didn't help.
>
> I notice that MinGW libraries are named like "libgdi32.a".
> Regardless of the naming differences, it seems that it should be
> possible to build DLLs using libtool under MinGW.
>
> There are some other warnings printed as well for static libraries
> built with libtool:
>
> *** Warning: This system can not link to static lib archive
> /usr/local/lib/libwmflite.la.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
>
> I assume that these warnings are insignificant since the same list of
> libraries will be applied when building executables.  However, maybe I
> am wrong.  Maybe all libraries linked to the DLL need to be DLLs?
>
> What is the trick to getting this to work?
>
> Thanks,
>
> Bob
> ======================================
> Bob Friesenhahn
> bfr...@si...
> http://www.simplesystems.org/users/bfriesen
>
>
> _______________________________________________
> Libtool mailing list
> Li...@gn...
> http://mail.gnu.org/mailman/listinfo/libtool