libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: revised patch for glib compilation on cygwin with POSIX runtime


From: Tor Lillqvist
Subject: Re: revised patch for glib compilation on cygwin with POSIX runtime
Date: Tue, 20 Feb 2001 13:00:31 +0200 (FLE Standard Time)

Gary V. Vaughan writes:
 > If libtool doesn't already find non-libtool libraries on mingw, then that is 
 > a bug.  libtool works with non-libtool libraries on the other architectures 
 > to which it has been ported.  Patches gratefully accepted (I think this 
 > should be quite straight forward).

It might not be quite straightforward, as the places and names to look
for depends much on your version of binutils etc. I think ld looks for
various perumutations of libxxx.a, libxxx.dll.a, libxxx.lib, xxx.lib,
xxx.dll depending on version in some order.

But anyway, I will have a look at it.

 > >   3) libtool should be able to use a pre-existing .def file
 > >   (hand-written or otherwise generated), in case one doesn't want to
 > >   export everything. OTOH, if some library can export everything on
 > >   Unix, doing it on Win32 probably won't cause any harm, either.
 > 
 > Seems fair enough to me.

Actually it already handles this, I just didn't notice at first. The
-export-symbols flag accepts a file listing symbols to be exported,
which can be produced from typical simple .def files by simply
dropping the first (EXPORTS) line.

OTOH, libtool then proceeds to prepend an EXPORTS line, followed by
the contents of the symbols file, so it might be better to change
libtool to check if the supplied -export-symbols file already is a
.def file and in that case use it as is?  Then it would also be
possible to use the more esoteric .def file stuff, if necessary (I
don't even know what all there can be in .def files, but presumably in
some cases it might even be useful to use some of the more esoteric
features.)

 > >   4) libtool should be taught to generate MS import libs, too, if
 > >   lib.exe (or actually link.exe) is available.
 > 
 > Not so sure about this one.  But if you can come up with a clean patch that 
 > doesn't perturb any of the other ports, I'd certainly be happy to evaluate 
 > it.

This wouldn't be hard at all, basically libtool needs to invoke:
        lib.exe -name:xxx.dll -def:xxx.def -out:xxx.lib
ignoring failure if lib.exe isn't found.

 > Great!  There are some submission guidelines on the libtool homepage, and we 
 > might need a copyright assignment if your changes are moderately large.

The like to "copyright assignment form" seems to be broken. I can't
find it on the www.gnu.org site now, either.

--tml




reply via email to

[Prev in Thread] Current Thread [Next in Thread]