Understanding libtool on Windows / MinGW
I am currently porting a largish piece of software from Linux to Windows, and I'm having trouble compiling some of the third-party libraries it requires. (before you ask: yes, I have to compile most of these libraries myself; this is not the issue here.) I realize that this comes up regularly, but I haven't found a unified, coherent explanation or solution. I am asking these questions not just to find a solution to my immediate problem, but to find the *correct* solution (as opposed to all the wrong ones Google dug up for me), and to truly *understand* why it is the correct one. Let's start with the first indication I had that something was not as it should be. While building the C++ bindings for HDF5 (after fixing a few other bugs), I got this: libtool: link: g++ -o .libs/dsets.exe dsets.o h5cpputil.o ../../test/.libs/libh5test.a ../../c++/src/.libs/libhdf5_cpp.a /mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a ../../src/.libs/libhdf5.a -lws2_32 -L/mingw/lib/gcc/mingw32/4.4.0 g++.exe: C:/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory First question: why is libtool linking *explicitly* against libstdc++? I noticed that configure decided that this was necessary, but the first thing I did after installing MinGW was compile "hello world" programs in C, C++ and Fortran, and gcc / g++ / gfortran had no trouble linking them without explicit references to libc / libstdc++ / libgfortran. Second question: there is no libstdc++.dll.a; is this a mistake on the part of the MinGW maintainers? Third question: what are the expected library names when building with the GNU toolchain on Windows? I expected ".a" for the static library, ".dll" for the shared library and ".lib" for the import library. Apparently, I was wrong. (I probably knew this at some point, but it's been ten years since I did any serious development work on Windows, and back then, I used an IDE that did it all for me) Fourth question: when I googled for solutions to this problem, what I found (again and again) was "replace library_names='whatever.dll.a' in the .la file with library_names=''". Somehow, I don't think libtool would consistently set library_names to an incorrect value; if it had at some point, surely it would have been fixed by now. Therefore, that advice must be incorrect. This hypothesis was strengthened when I found that jpeg7 won't link with this hack (not as in "libtool fails to link programs that use libjpeg", but as in: libtool fails to link libjpeg") Fifth question: can someone give a concise explanation of what, exactly, -no-undefined does, and why it is required? DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
GNU Libtool 2.2.6b released
We are pleased to announce the release of GNU Libtool 2.2.6b. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. This release is a bug fix release for version 2.2.6. The following bugs are fixed: - Fixed libltdl to no longer attempt to dlopen() the old_library listed in the .la file. Now will use only the preopen loader to attempt to load it. This may be a security issue, all users are advised to upgrade. - Similarly, don't open module.la from the current directory, this changes the behavior of libltdl to match the documentation. libtool-2.2.6b is available now from ftp.gnu.org, along with diffs against libtool-2.2.6a. Please use a mirror to reduce stress on the main gnu machine: http://www.gnu.org/order/ftp.html Here are the compressed sources: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.gz ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.lzma Here are the diffs against libtool-2.2.6a: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6a-2.2.6b.diff.gz The MD5 and SHA1 checksums are: libtool-2.2.6b.tar.gz 07da460450490148c6d2df0f21481a25 libtool-2.2.6b.tar.lzma a4b36980765003b47dd75ac9429f4f11 libtool-2.2.6a-2.2.6b.diff.gz a485788eb8fac09f7bb19b9f471ecf16 libtool-2.2.6b.tar.gz 5afa73c8ef9ebe64bbb438a0f8779c9036e43c55 libtool-2.2.6b.tar.lzma 18baaac89eed8be7bd2af2d2181598e176029cc6 libtool-2.2.6a-2.2.6b.diff.gz 161b4f775d2e17890a25fd791c2deb3a69dcf293 This release was bootstrapped with automake-1.11 and autoconf-2.64. You can fetch the unbootstrapped source code with git by using the following commands: $ git clone git://git.savannah.gnu.org/libtool.git $ cd libtool $ git checkout v2.2.6b Please report bugs to , along with the verbose output of any failed test groups, and the output from `./libtool --config.' The README file explains how to capture the verbose test output. ___ http://lists.gnu.org/mailman/listinfo/libtool
retagged 2.2.6b
So, I screwed up ... Yes, I know it's not best. I tagged 2.2.6b yesterday, and moved the tag this morning, so you may have the tag pointing at the wrong commit. Sorry, Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
Congrats on the release! I'm a little confused by the version number, though. 2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also the rationale provided as to why the "a" suffix was not included in the directory name from the expanded tarball. This new release has the suffix "b" *and* includes "b" in the directory name. This is a departure from prior LT releases where bug fixes incremented the minor number -- I expected this release to be 2.2.7. Has LT changed its version numbering scheme? More specifically -- what exactly do the minor version number and suffix now represent? Thanks! On Nov 16, 2009, at 7:07 AM, Peter O'Gorman wrote: We are pleased to announce the release of GNU Libtool 2.2.6b. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. This release is a bug fix release for version 2.2.6. The following bugs are fixed: - Fixed libltdl to no longer attempt to dlopen() the old_library listed in the .la file. Now will use only the preopen loader to attempt to load it. This may be a security issue, all users are advised to upgrade. - Similarly, don't open module.la from the current directory, this changes the behavior of libltdl to match the documentation. libtool-2.2.6b is available now from ftp.gnu.org, along with diffs against libtool-2.2.6a. Please use a mirror to reduce stress on the main gnu machine: http://www.gnu.org/order/ftp.html Here are the compressed sources: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.gz ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.lzma Here are the diffs against libtool-2.2.6a: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6a-2.2.6b.diff.gz The MD5 and SHA1 checksums are: libtool-2.2.6b.tar.gz 07da460450490148c6d2df0f21481a25 libtool-2.2.6b.tar.lzma a4b36980765003b47dd75ac9429f4f11 libtool-2.2.6a-2.2.6b.diff.gz a485788eb8fac09f7bb19b9f471ecf16 libtool-2.2.6b.tar.gz 5afa73c8ef9ebe64bbb438a0f8779c9036e43c55 libtool-2.2.6b.tar.lzma 18baaac89eed8be7bd2af2d2181598e176029cc6 libtool-2.2.6a-2.2.6b.diff.gz 161b4f775d2e17890a25fd791c2deb3a69dcf293 This release was bootstrapped with automake-1.11 and autoconf-2.64. You can fetch the unbootstrapped source code with git by using the following commands: $ git clone git://git.savannah.gnu.org/libtool.git $ cd libtool $ git checkout v2.2.6b Please report bugs to , along with the verbose output of any failed test groups, and the output from `./libtool --config.' The README file explains how to capture the verbose test output. -- Jeff Squyres jsquy...@cisco.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On 11/16/2009 09:18 AM, Jeff Squyres wrote: Congrats on the release! I'm a little confused by the version number, though. 2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also the rationale provided as to why the "a" suffix was not included in the directory name from the expanded tarball. This new release has the suffix "b" *and* includes "b" in the directory name. We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. This release only contains two bugfixes to libltdl that were deemed important enough to warrant a separate release from the "stable" 2.2.6 series. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote: We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. So why not call this release 2.2.8 and bump the version number of the next one to 2.2.10? Is it technically difficult to do so? I ask because version numbers are primarily for users -- not developers. So a little developer discomfort to rename specific releases is (IMHO) acceptable in order to provide a clear, unambiguous meaning of the version number to users. This release only contains two bugfixes to libltdl that were deemed important enough to warrant a separate release from the "stable" 2.2.6 series. Understood. My only point is that the last 2 public releases of LT have had semantically different meanings of the version number. It is therefore VERY unclear that 2.2.6b is a significant security/bug fix release (even if the actual changes are minor). If I (a random user) saw that LT released 2.2.6b but didn't read anything in the notes, I'd assume that it was another packaging change, like 2.2.6a was. I certainly would not immediately grok that it contains a security update. OTOH, if the LT version number was bumped to 2.2.8 -- or even 2.4 -- I would assume that most users will think, "Something important must have changed. I should go a) read the release notes, and b) install this update." (all normal disclaimers on the word "assume", of course ;-) ). My $0.02: the version number of a package is a critical method of communication to the rest of the world. It needs to have clear, unambiguous meaning. The last 2 releases of LT have significantly muddied the waters as to what the 3rd field in the LT version number means. Can you clarify what exactly the minor number and suffix mean in the LT version number (for the purposes of understanding future releases)? Sidenote: it's easy for email threads like this to get sidetracked into flamewars. Please understand that I'm a long-time/loyal LT user and greatly appreciate all your efforts -- I'm *NOT* trying to start a flamewar. I sent this email (and the emails back when 2.2.6a was released) not to be a jerk, but rather to ask a genuine user- perspective question and hopefully get some clarity for the future. Thanks! -- Jeff Squyres jsquy...@cisco.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On 11/16/2009 09:32 AM, Jeff Squyres wrote: On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote: We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. So why not call this release 2.2.8 and bump the version number of the next one to 2.2.10? Is it technically difficult to do so? Because I never thought to do so. My only point is that the last 2 public releases of LT have had semantically different meanings of the version number. It is therefore VERY unclear that 2.2.6b is a significant security/bug fix release (even if the actual changes are minor). If I (a random user) saw that LT released 2.2.6b but didn't read anything in the notes, I'd assume that it was another packaging change, like 2.2.6a was. I certainly would not immediately grok that it contains a security update. I agree with your points, and had I put any thought at all into version numbering I would have done it differently. Apologies all around. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Backport of libltdl changes to branch-1-5
If you happen to be stuck using an older libltdl for some reason, the
attached untested patch should give you the same changes in behavior as
the badly numbered 2.2.6b release.
Peter
--
Peter O'Gorman
http://pogma.com
diff -urN libtool-1.5.26.orig/libltdl/ltdl.c libtool-1.5.26/libltdl/ltdl.c
--- libtool-1.5.26.orig/libltdl/ltdl.c 2007-11-15 13:36:41.0 -0600
+++ libtool-1.5.26/libltdl/ltdl.c 2009-11-15 21:13:37.0 -0600
@@ -2192,7 +2192,8 @@
static int try_dlopen LT_PARAMS((lt_dlhandle *handle,
const char *filename));
static int tryall_dlopen LT_PARAMS((lt_dlhandle *handle,
- const char *filename));
+ const char *filename,
+ const char * useloader));
static int unload_deplibs LT_PARAMS((lt_dlhandle handle));
static int lt_argz_insert LT_PARAMS((char **pargz,
size_t *pargz_len,
@@ -2390,9 +2391,10 @@
}
static int
-tryall_dlopen (handle, filename)
+tryall_dlopen (handle, filename, useloader)
lt_dlhandle *handle;
const char *filename;
+ const char *useloader;
{
lt_dlhandle cur;
lt_dlloader *loader;
@@ -2459,6 +2461,11 @@
while (loader)
{
+ if (useloader && strcmp(loader->loader_name, useloader))
+ {
+ loader = loader->next;
+ continue;
+ }
lt_user_data data = loader->dlloader_data;
cur->module = loader->module_open (data, filename);
@@ -2528,7 +2535,7 @@
error += tryall_dlopen_module (handle,
(const char *) 0, prefix, filename);
}
- else if (tryall_dlopen (handle, filename) != 0)
+ else if (tryall_dlopen (handle, filename, NULL) != 0)
{
++error;
}
@@ -2549,7 +2556,7 @@
/* Try to open the old library first; if it was dlpreopened,
we want the preopened version of it, even if a dlopenable
module is available. */
- if (old_name && tryall_dlopen (handle, old_name) == 0)
+ if (old_name && tryall_dlopen (handle, old_name, "dlpreload") == 0)
{
return 0;
}
@@ -2813,7 +2820,7 @@
/* Try to dlopen the file, but do not continue searching in any
case. */
- if (tryall_dlopen (handle, filename) != 0)
+ if (tryall_dlopen (handle, filename,NULL) != 0)
*handle = 0;
return 1;
@@ -3103,7 +3110,7 @@
/* lt_dlclose()ing yourself is very bad! Disallow it. */
LT_DLSET_FLAG (*phandle, LT_DLRESIDENT_FLAG);
- if (tryall_dlopen (&newhandle, 0) != 0)
+ if (tryall_dlopen (&newhandle, 0, NULL) != 0)
{
LT_DLFREE (*phandle);
return 1;
@@ -3225,7 +3232,7 @@
}
#endif
}
- if (!file)
+ else
{
file = fopen (filename, LT_READTEXT_MODE);
}
@@ -3412,7 +3419,7 @@
#endif
)))
{
- if (tryall_dlopen (&newhandle, filename) != 0)
+ if (tryall_dlopen (&newhandle, filename, NULL) != 0)
{
newhandle = NULL;
}
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On Mon, 16 Nov 2009, Jeff Squyres wrote: Congrats on the release! I'm a little confused by the version number, though. 2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also the rationale provided as to why the "a" suffix was not included in the directory name from the expanded tarball. This new release has the suffix "b" *and* includes "b" in the directory name. This is a departure from prior LT releases where bug fixes incremented the minor number -- I expected this release to be 2.2.7. I also noticed that the 'a' release was not propagated into the directory name. I am not sure if this is a bug according to FSF rules, but it seems like a defect if source packages can not be extracted to the same directory without overwriting each other, and for this instance it is quite useful if 'libtool --version' includes the 'b' so I tend to be happy with 'b'. We should thank Peter for donating his weekend to the task of cutting the release. What is done is done and the current focus from libtool 2.2.X users should be to make sure that any libltdl embedded in their own packages matches this version. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
release procedure
Hi, For some reason our release procedure calls for running make distcheck 5 times. This is a tad onerous (one make distcheck takes almost an hour on my system). HACKING asks for: * Run `make distcheck' and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install' and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--program-prefix=g' and `make distcheck CC=g++' then later: * Run `make -fMakefile.maint git-dist' (which also runs make distcheck). Seriously, wtf? I suggest that just the first two would be adequate. We also fetch latest config* and some automake files from git/cvs. These files are all included in automake releases, what's wrong with just using the automake versions. Ralf releases automake fairly regularly ... If we must continue to fetch (I did not do so for todays release because when I tried I got test failures in make check/distcheck etc.), then we need to change the Makefile to use git for the config project. Why on earth do we have a commit script that just provides an opaque interface to git? Let's just use gnuupload from gnulib to upload the tarballs. Maintaining our own system is silly. I think that's about all, I will provide patches for HACKING and Makefile.maint later. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: release procedure
For some reason our release procedure calls for running make distcheck 5 times. This is a tad onerous (one make distcheck takes almost an hour on my system). HACKING asks for: and `make distcheck CC=g++' I think keeping CC=g++ might be a good idea because many users (self included) use libltdl in C++ projects. Sure, the header forces symbols to have C-linkage in any case, but I'd sleep better knowing this was covered somehow. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: release procedure
On 11/16/2009 11:29 AM, David Fang wrote: For some reason our release procedure calls for running make distcheck 5 times. This is a tad onerous (one make distcheck takes almost an hour on my system). HACKING asks for: and `make distcheck CC=g++' I think keeping CC=g++ might be a good idea because many users (self included) use libltdl in C++ projects. Sure, the header forces symbols to have C-linkage in any case, but I'd sleep better knowing this was covered somehow. Using libltdl from a C++ package should already be covered by the testsuite. If you find it is not adequately covered, please let us know. libltdl itself does not even build with g++, that check does not belong, really. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
On Mon, 16 Nov 2009, Dag-Erling Smørgrav wrote: Second question: there is no libstdc++.dll.a; is this a mistake on the part of the MinGW maintainers? I suggest that you look into the issue of throwing C++ exceptions past DLL boundaries. This seems to be a complex issue for Windows with several solutions, none of which are perfect. Due to these issues, it is not unusual for a DLL version of libstdc++ to be missing. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
On Mon, 16 Nov 2009, Dag-Erling Smørgrav wrote: Fifth question: can someone give a concise explanation of what, exactly, -no-undefined does, and why it is required? This option is an indication that the application is fully prepared to resolve all symbols at link time. One requirement for this is that all libraries that the DLL depends on be specified at link time. This is a reason why libstdc++ also needs to be supplied at link time. Libtool normally refuses to a static library into a DLL since that would cause a lot of problems. You did not mention the version of libtool you are using. This may be obtained from 'libtool --version'. The current version is 2.2.6b. I have libjpeg 7 installed as a shared library under MinGW and have not noticed any problems linking with it. There are many versions of MinGW and many versions of libtool and some work better than others. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: release procedure
Hi Peter, * Peter O'Gorman wrote on Mon, Nov 16, 2009 at 05:16:15PM CET: > For some reason our release procedure calls for running make > distcheck 5 times. This is a tad onerous Agreed. > (one make distcheck takes almost an hour on my system). Hmpf. If you have a multi-way system, try e.g. TESTSUITEFLAGS=-j6 for a four-core one. I have a couple of local patches to use parallel-tests for the old Libtool testsuite, but that makes things a bit awkward. Still, I should probably clean them up and post them for review. > HACKING asks for: > * Run `make distcheck' > and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install' > and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--program-prefix=g' > and `make distcheck CC=g++' > > then later: > * Run `make -fMakefile.maint git-dist' (which also runs make distcheck). > > Seriously, wtf? > > I suggest that just the first two would be adequate. Either that, or limit some of these tests so they are still effective but less expensive. Certainly having both the last implied distcheck and the first one is overkill. The CC=g++ can help to avoid some test failures elsewhere though. > We also fetch latest config* and some automake files from git/cvs. > These files are all included in automake releases, what's wrong with > just using the automake versions. Ralf releases automake fairly > regularly ... Well, esp. config.guess often is newer, and not having the latest of that greatly bothers users porting stuff to new systems. Of all things, this is one issue that I'd really like us to keep, also as it avoids the implied serialization between Automake and Libtool. > If we must continue to fetch (I did not do so for todays release > because when I tried I got test failures in make check/distcheck > etc.), then we need to change the Makefile to use git for the config > project. Yes. > Why on earth do we have a commit script that just provides an opaque > interface to git? FWIW, I never use it. Gary? > Let's just use gnuupload from gnulib to upload the tarballs. > Maintaining our own system is silly. Fine with me. > I think that's about all, I will provide patches for HACKING and > Makefile.maint later. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
