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 ... <link DLL> Creating library file: .libs/liblzma.dll.a <link static archive>: 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