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: Gary V . Vaughan
Subject: Re: revised patch for glib compilation on cygwin with POSIX runtime
Date: Wed, 21 Feb 2001 22:11:32 +0000

On Tue, 20 Feb 2001, Tor Lillqvist wrote:
> 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.

I think it will be okay to choose a canonical search order for libtool to use 
on mingw, and pass libraries found in this way to the linker using full path 
names.  I'm not sure what the canonical order should be... maybe whatever the 
most recent binutils uses is a good starting point?

> But anyway, I will have a look at it.

Excellent, thankyou!

>  > >   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.
>
> [[snippage]]

Well it is "supposed" to do it, but I have never had occasion to use it, and 
am very dubious as to its correctness.  On the other hand I have never 
received a complaint, so verifying it is very low on my list of priorities 
right now.

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

Okay.  I look forward to your patch ;-)

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

Oops.  The procedure for submitting assignments has changed since I last 
organised any.  I'll try and find out what the new procedure is, and update 
the libtool pages.  I'll mail you in private about this.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc



reply via email to

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