[Top][All Lists]
[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