Creating shared and static libraries with convenience libraries
I ran in to a problem using libtool to generate both shared and static libraries with convenience archives (on cygwin, but I believe this is cross-platform). Working with git-master xz utils, with some local patches, I saw the following: /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -Wextra -Wformat=2 -Winit-self -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -Werror -g -O2 -version-info 0:0:0 -no-undefined -Xlinker --output-def -Xlinker liblzma.def.in -o liblzma.la -rpath /usr/local/lib common/libcommon.la check/libcheck.la lz/liblz.la lzma/liblzma2.la rangecoder/librangecoder.la delta/libdelta.la simple/libsimple.la liblzma_w32res.lo ... Creating library file: .libs/liblzma.dll.a : libtool: link: (cd .libs/liblzma.lax/libcommon.a && ar x "/usr/src/packages/xz/git/_build/src/liblzma/common/.libs/libcommon.a") libtool: link: (cd .libs/liblzma.lax/libcheck.a && ar x "/usr/src/packages/xz/git/_build/src/liblzma/check/.libs/libcheck.a") ... Note the various convenience libraries, such as common/libcommon.la. In $build/common/ there exist a lot of .o and .lo files, while $build/common/.libs contains a lot of (other) .o files. As expected, the first set of .o's were all compiled with "normal" flags, while the second set were compiled with the pic flags (which for cygwin are -DDLL_EXPORT -DPIC). However, for each of those convenience archives, only a single .a is created -- e.g. $build/common/.libs/libcommon.a, and it contains only the "pic" .o's from $build/common/.libs/. The associated .la file looks like this: ... # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libcommon.a' ... So, when we get around to linking the actually installable library, both the DLL and the "static' archive contain the same .o's -- the ones compiled with the "pic" flags -DDLL_EXPORT and -DPIC. This is a problem, because now the "static" archive contains declspec(dllexport)-decorated symbols. (a) Is this a known issue, a new bug, or a design decision? (b) I can work around it by avoiding convenience archives entirely, and using subdir objects instead. However, I'm unsure which released automake version first *successfully* supported those...I know they were introduced in 1.9, but IIRC proper operation required a patch that wasn't merged until 1.10. Is my recollection correct? (c) longer term, if this IS a bug, then should it be fixed? How? The relevant code is a maze of twisty passages, all alike... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating shared and static libraries with convenience libraries
On Sun, 28 Jun 2009, Charles Wilson wrote: So, when we get around to linking the actually installable library, both the DLL and the "static' archive contain the same .o's -- the ones compiled with the "pic" flags -DDLL_EXPORT and -DPIC. This is a problem, because now the "static" archive contains declspec(dllexport)-decorated symbols. Interesting. I think that it is assumed that "PIC" code will work in a static archive. Apparently this is a wrong assumption for "decorated" DLL code. Most open source projects ported to Windows rely on GCC's automatic DLL import feature. (b) I can work around it by avoiding convenience archives entirely, and using subdir objects instead. However, I'm unsure which released automake version first *successfully* supported those...I know they were introduced in 1.9, but IIRC proper operation required a patch that wasn't merged until 1.10. Is my recollection correct? I know that I used it successfully for a large non-recursive build with subdir objects prior to 1.10 being released. That would have been when the Automake feature was still "bleeding edge". Problems I noticed in those days were libtool's fault and not Automake's fault. 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: Creating shared and static libraries with convenience libraries
Bob Friesenhahn wrote: > On Sun, 28 Jun 2009, Charles Wilson wrote: >> >> So, when we get around to linking the actually installable library, both >> the DLL and the "static' archive contain the same .o's -- the ones >> compiled with the "pic" flags -DDLL_EXPORT and -DPIC. >> >> This is a problem, because now the "static" archive contains >> declspec(dllexport)-decorated symbols. It might also be an issue if you use -DPIC to determine whether to use gcc-4.x's visibility specifiers, for non-win32. Not sure about that, tho. I've verified that this behavior (pulling in the .libs/.o's into the "static" archive, when convenience libs are used) also occurs with 1.5.x. As it happens, liblzma itself does not export any data items, so in MY mingw 3.4.5 builds I don't actually see the problem. However, Lasse does see it in his mingw 4.4.0 builds, and this seems to be the reason. > Interesting. I think that it is assumed that "PIC" code will work in a > static archive. Apparently this is a wrong assumption for "decorated" > DLL code. Most open source projects ported to Windows rely on GCC's > automatic DLL import feature. Unless you're using MinGW to build a DLL (that exports data items?), and is intended for use with MSVC. Or your name is Bruno, and you don't like auto-import: http://www.haible.de/bruno/woe32dll.html >> (b) I can work around it by avoiding convenience archives entirely, and >> using subdir objects instead. However, I'm unsure which released >> automake version first *successfully* supported those...I know they were >> introduced in 1.9, but IIRC proper operation required a patch that >> wasn't merged until 1.10. Is my recollection correct? > > I know that I used it successfully for a large non-recursive build with > subdir objects prior to 1.10 being released. That would have been when > the Automake feature was still "bleeding edge". Problems I noticed in > those days were libtool's fault and not Automake's fault. Thanks for the data point. It appears upstream is using 1.10 for their distribution tarballs, so as long as they are happy to *require* 1.10 or above (for developers who want to autoreconf), then we're good to go. The main downside of always avoiding convenience libraries is they are the only way to get per-object compile flags... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating shared and static libraries with convenience libraries
On Sun, 28 Jun 2009, Charles Wilson wrote: Interesting. I think that it is assumed that "PIC" code will work in a static archive. Apparently this is a wrong assumption for "decorated" DLL code. Most open source projects ported to Windows rely on GCC's automatic DLL import feature. Unless you're using MinGW to build a DLL (that exports data items?), and is intended for use with MSVC. Or your name is Bruno, and you don't like auto-import: http://www.haible.de/bruno/woe32dll.html As a data point, I believe that GraphicsMagick explicitly dll exports functions and data when it is built under MinGW, however it has not used convenience libraries in its build for many years since they are so archaic. It does not explicitly explicitly dll export under Cygwin. I don't currently have a MinGW DLL build of GraphicsMagick using GCC 4.X. I will try to do it. 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
