[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Win32 libltdl issue
From: |
Howard Chu |
Subject: |
Re: Win32 libltdl issue |
Date: |
Wed, 27 Apr 2005 10:14:01 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050419 |
Bob Friesenhahn wrote:
I see that more recent versions of cygwin/mingw appear to have made
using declspec unnecessary:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html
I don't know how others would feel about it, but perhaps you could
just say "version >= XX of cygwin/mingw binutils are required" and
forget about all of these issues.
This assumes that libtool should only support the GCC compiler under
Windows. Microsoft, Borland, and others, need not apply. Is there a
good reason to rule out all compilers except for GCC?
Sorry, I wasn't aware that anyone used those other compilers with Cygwin
or MinGW. No, I'm not recommending that support for those be dropped if
they are indeed supported right now.
But there are a number of features in the new binutils that will make
supporting gcc easier on Cygwin/MinGW, so for environments where the GNU
toolchain is in use, I would still suggest placing minimum version
requirements in.
One other annoying gotcha when building with libtool and Win32 is that
libtool (at least in the 1.x line) assumed that any lib*.a was a static
library, and refused to link it into a DLL. It didn't account for the
possibility that the library was actually a DLL import library. Now that
the linker can automatically Do The Right thing regardless of what type
of library is fed to it, libtool could just use pass_all here. So again,
it simplifies the Win32 support if you can assume a recent toolchain.
Right now (1.x), when libtool sees that you're trying to link against a
DLL, it calls dlltool to generate a new import library on the fly, and
then deletes it when that step completes. It does this each time the DLL
is referenced in a build procedure, which is a ton of wasted effort and
makes builds much slower than they should be. With a new toolchain you
could delete all of the commands for these cases and just let ld link
the thing.
Failing that, libtool should include the import library in the install
step, and the .la file should list
library_names='libfoo.dll libfoo.dll.a'
so that libtool will use the import library when linking libtool
libraries together.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
- FYI: remove stale reference to libltdl/loaders/Makefile [libtool--gary--1.0--patch-22], Gary V. Vaughan, 2005/04/15
- FYI: remove stale reference to libltdl/loaders/Makefile [libtool--gary--1.0--patch-22], Gary V. Vaughan, 2005/04/25
- Win32 libltdl issue, Howard Chu, 2005/04/26
- Re: Win32 libltdl issue, Ralf Wildenhues, 2005/04/27
- Re: Win32 libltdl issue, Howard Chu, 2005/04/27
- Re: Win32 libltdl issue, Ralf Wildenhues, 2005/04/27
- Re: Win32 libltdl issue, Howard Chu, 2005/04/27
- Re: Win32 libltdl issue, Bob Friesenhahn, 2005/04/27
- Re: Win32 libltdl issue,
Howard Chu <=
- Re: Win32 libltdl issue, Charles Wilson, 2005/04/27
- Re: Win32 libltdl issue, Howard Chu, 2005/04/27
- Re: Win32 libltdl issue, Charles Wilson, 2005/04/28
- Re: Win32 libltdl issue, Ralf Wildenhues, 2005/04/28
- Re: Win32 libltdl issue, Bob Friesenhahn, 2005/04/28
- Re: Win32 libltdl issue, Ralf Wildenhues, 2005/04/28