Re: Linking against static libraries in Windows (MSYS)
On Mon, 27 Jun 2016, Bob Friesenhahn wrote: The good news is that libtool will already automatically link dependency libraries when you build something which depends on 'A' and the .la file for 'A' is present. In other words, libtool should handle the problem automatically as long as you don't do something to intentionally break it (e.g. delete the .la file) or link using something other than libtool. This is a core function of libtool. I failed to mention that there is something about MinGW which does make things different. Windows DLLs do not allow undefined symbols so you may be forced to build your library 'B' as a DLL in order for library 'A' to sucessfully link. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against static libraries in Windows (MSYS)
On Mon, 27 Jun 2016, Alex wrote: $ ./configure --disable-shared --enable-static --prefix=/usr $ make && make install But when I build *A* afterwards the following warning appears: *** Warning: This system can not link to static lib archive /usr/lib/ libogg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Has anybody come across this? Is there any known fix or workaround? This is a common problem, which is not specific to MinGW or MSYS. The two possible solutions are to either arrange to link with 'B' while linking any application which depends on 'A', or else build 'B' as libtool convenience library so that all symbols from 'B' now become part of 'A'. Since in this case, the user may not expect symbols from libogg to be part of library 'A' (and perhaps multiple libraries similar to 'A' may also want to link with it), I doubt that the libtool convenience library approach is the correct one here. Duplicate symbols due to mutual dependence need to be avoided. The good news is that libtool will already automatically link dependency libraries when you build something which depends on 'A' and the .la file for 'A' is present. In other words, libtool should handle the problem automatically as long as you don't do something to intentionally break it (e.g. delete the .la file) or link using something other than libtool. This is a core function of libtool. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Linking against static libraries in Windows (MSYS)
Hello, I wonder if this would be a bug or something directly unsupported. I'm building a shared library *A* on Windows using MSYS (bash, gcc, etc.). *A* depends on *B*, so it needs to be built first and as long as both are built to be shared libraries everything goes well. However I'd like to have just a shared library of *A* (i.e. linking against a static version of *B*) and to accomplish that I built *B* as a static library only: $ ./configure --disable-shared --enable-static --prefix=/usr $ make && make install But when I build *A* afterwards the following warning appears: *** Warning: This system can not link to static lib archive /usr/lib/ libogg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Has anybody come across this? Is there any known fix or workaround? The libraries I'm building are FLAC and libogg, although it happens with different ones as well. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Problem linking with static libraries on Darwin (not the architecture being linked)
$ make CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' LDFLAGS='-framework CoreFoundation -framework CoreServices -L$HOME/build/sfAgent/libs/Release_Static/lib' But when the build goes to link an executable: /bin/sh ./libtool --tag=CXX --mode=link c++ -arch x86_64 -framework CoreFoundation -framework CoreServices -L/Users/bradenmcdaniel/build/sfAgent/libs/Release_Static/lib -o xqilla xqilla-commandline.o libxqilla.la -lpthread /Users/bradenmcdaniel/build/my/install/root/lib/libxerces-c.a /Users/bradenmcdaniel/build/my/install/root/lib/libcurl.a /Users/bradenmcdaniel/build/my/install/root/lib/libssl.a /Users/bradenmcdaniel/build/my/install/root/lib/libcrypto.a libtool: link: c++ -arch x86_64 -o xqilla xqilla-commandline.o -Wl,-bind_at_load -L/Users/bradenmcdaniel/build/my/install/root/lib ./.libs/libxqilla.a -lpthread /Users/bradenmcdaniel/build/my/install/root/lib/libxerces-c.a /Users/bradenmcdaniel/build/my/install/root/lib/libcurl.a /Users/bradenmcdaniel/build/my/install/root/lib/libssl.a /Users/bradenmcdaniel/build/my/install/root/lib/libcrypto.a -framework CoreServices -framework CoreFoundation ld: warning: ignoring file ./.libs/libxqilla.a, file was built for archive which is not the architecture being linked (x86_64): ./.libs/libxqilla.a Undefined symbols for architecture x86_64: NSFixupFilter::NSFixupFilter(EventHandler*, XPath2MemoryManager*), referenced from: _main in xqilla-commandline.o NSFixupFilter::~NSFixupFilter(), referenced from: _main in xqilla-commandline.o (…and many more symbols that would be resolved by libxqilla.) Has anyone else seen this sort of thing? And might this warning from the linker indicate something other than what it claims? It looks like the program called 'c++' (is it GCC? clang?) is either not passing the -arch option down to 'ld' or 'ld' does not respond to it. You might try adding LDFLAGS=-Wl,-arch,x86_64 and/or add '-v' to CXXFLAGS to cause the compiler to dump the details of what it is doing so you can see the arguments it is passing to the linker. Also please check that ./.libs/libxqilla.a really does contain 64-bit objects. Some linkers use the mode from the first object file they encounter. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ https://lists.gnu.org/mailman/listinfo/libtool
Problem linking with static libraries on Darwin (not the architecture being linked)
I'm experiencing a problem linking with static libraries on Darwin (Mountain Lion). I'm getting this warning: ld: warning: ignoring file ./.libs/libxqilla.a, file was built for archive which is not the architecture being linked (x86_64): ./.libs/libxqilla.a …even though I'm pretty confident that the objects in libxqilla.a were built with -arch x86_64 (like everything else built here). Backing up a bit, I have doctored things in the xqilla build a bit in order to create a static library and use some static libraries as dependencies. configure was run thusly: $ ../../Source/XQilla/configure --with-xerces=$HOME/build/my/install/root --disable-shared CC=cc CXX=c++ CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' LDFLAGS=-framework CoreFoundation -framework CoreServices -L$HOME/build/my/install/root/lib LIBS=$HOME/build/my/install/root/lib/libxerces-c.a $HOME/build/my/install/root/lib/libcurl.a $HOME/build/my/install/root/lib/libssl.a $HOME/build/my/install/root/lib/libcrypto.a …and when I build, I override CFLAGS, CXXFLAGS, and LDFLAGS (to account for problematic settings of these variables in the Makefile): $ make CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' LDFLAGS='-framework CoreFoundation -framework CoreServices -L$HOME/build/sfAgent/libs/Release_Static/lib' But when the build goes to link an executable: /bin/sh ./libtool --tag=CXX --mode=link c++ -arch x86_64 -framework CoreFoundation -framework CoreServices -L/Users/bradenmcdaniel/build/sfAgent/libs/Release_Static/lib -o xqilla xqilla-commandline.o libxqilla.la -lpthread /Users/bradenmcdaniel/build/my/install/root/lib/libxerces-c.a /Users/bradenmcdaniel/build/my/install/root/lib/libcurl.a /Users/bradenmcdaniel/build/my/install/root/lib/libssl.a /Users/bradenmcdaniel/build/my/install/root/lib/libcrypto.a libtool: link: c++ -arch x86_64 -o xqilla xqilla-commandline.o -Wl,-bind_at_load -L/Users/bradenmcdaniel/build/my/install/root/lib ./.libs/libxqilla.a -lpthread /Users/bradenmcdaniel/build/my/install/root/lib/libxerces-c.a /Users/bradenmcdaniel/build/my/install/root/lib/libcurl.a /Users/bradenmcdaniel/build/my/install/root/lib/libssl.a /Users/bradenmcdaniel/build/my/install/root/lib/libcrypto.a -framework CoreServices -framework CoreFoundation ld: warning: ignoring file ./.libs/libxqilla.a, file was built for archive which is not the architecture being linked (x86_64): ./.libs/libxqilla.a Undefined symbols for architecture x86_64: NSFixupFilter::NSFixupFilter(EventHandler*, XPath2MemoryManager*), referenced from: _main in xqilla-commandline.o NSFixupFilter::~NSFixupFilter(), referenced from: _main in xqilla-commandline.o (…and many more symbols that would be resolved by libxqilla.) Has anyone else seen this sort of thing? And might this warning from the linker indicate something other than what it claims? Braden ___ https://lists.gnu.org/mailman/listinfo/libtool
PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)
On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin p...@lysator.liu.se wrote: PR Den 2011-06-23 14:25 skrev Vadim Zeitlin: PR Am I the only one to think that this behaviour is singularly PR unhelpful? PR PR Of course not, others have stated that a patch would be welcome to PR fix --disable-static (and --enable-shared) to error out if it is not PR possible to create a shared library (due to a missing -no-undefined). Sorry for the delay, I got distracted by other things but here is finally the promised trivial patch (I also cc it to libtool-patches just in case, sorry if you get this message twice): From: Vadim Zeitlin vz-libt...@zeitlins.org Date: Thu, 7 Jul 2011 17:26:43 +0200 Subject: [PATCH] Don't fall back to static libraries if building them was disabled. If -no-undefined was not specified but the platform didn't support shared libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were built instead of shared ones, even if building them was explicitly disabled with --disable-static configure option. Fix this by stopping with a fatal error if a shared library can't be built in this case instead of unexpectedly building a static library instead. * libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when trying to build a shared library without -no-undefined on a platform not supporting undefined symbols in shared libraries. Signed-off-by: Vadim Zeitlin vz-libt...@zeitlins.org --- libltdl/config/ltmain.m4sh |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 8e5c588..40b1d5f 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -6735,9 +6735,12 @@ func_mode_link () # Check to see if the archive will have undefined symbols. if test $allow_undefined = yes; then if test $allow_undefined_flag = unsupported; then - func_warning undefined symbols not allowed in $host shared libraries - build_libtool_libs=no - build_old_libs=yes + if test $build_old_libs = yes; then + func_warning undefined symbols not allowed in $host shared libraries + build_libtool_libs=no + else + func_fatal_error can't build $host shared library unless -no-undefined is specified + fi fi else # Don't allow undefined symbols. -- 1.7.2.3 I've tested this patch with the default and --disable-static configurations under Windows and Linux and it behaved as expected. Maybe the error message could be improved but I tried to remain consistent with the existing warning, if this consideration is not important it might be better to be more explicit about the problem and its potential solution. PR But fixing that is a separate issue from what the default behavior PR should be when -no-undefined is not specified. I agree with this but I still disagree that the current default behaviour is useful. IMO both (C1) and (C3) should try to build a shared library even if -no-undefined was not given and simply either stop with a fatal error or fall back to a static library if it failed. I don't see how could getting a shared library in addition to the static one in the case (C3) could ever be a problem and getting the expected result in the case (C1) is definitely an advantage and not a drawback. But I won't discuss this any more as I don't have any new arguments and apparently the ones I already gave were insufficiently convincing. Regards, VZ pgp8oBjQCFcWr.pgp Description: PGP signature
PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)
On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin p...@lysator.liu.se wrote: PR Den 2011-06-23 14:25 skrev Vadim Zeitlin: PR Am I the only one to think that this behaviour is singularly PR unhelpful? PR PR Of course not, others have stated that a patch would be welcome to PR fix --disable-static (and --enable-shared) to error out if it is not PR possible to create a shared library (due to a missing -no-undefined). Sorry for the delay, I got distracted by other things but here is finally the promised trivial patch (I also cc it to libtool-patches just in case, sorry if you get this message twice): From: Vadim Zeitlin vz-libt...@zeitlins.org Date: Thu, 7 Jul 2011 17:26:43 +0200 Subject: [PATCH] Don't fall back to static libraries if building them was disabled. If -no-undefined was not specified but the platform didn't support shared libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were built instead of shared ones, even if building them was explicitly disabled with --disable-static configure option. Fix this by stopping with a fatal error if a shared library can't be built in this case instead of unexpectedly building a static library instead. * libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when trying to build a shared library without -no-undefined on a platform not supporting undefined symbols in shared libraries. Signed-off-by: Vadim Zeitlin vz-libt...@zeitlins.org --- libltdl/config/ltmain.m4sh |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 8e5c588..40b1d5f 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -6735,9 +6735,12 @@ func_mode_link () # Check to see if the archive will have undefined symbols. if test $allow_undefined = yes; then if test $allow_undefined_flag = unsupported; then - func_warning undefined symbols not allowed in $host shared libraries - build_libtool_libs=no - build_old_libs=yes + if test $build_old_libs = yes; then + func_warning undefined symbols not allowed in $host shared libraries + build_libtool_libs=no + else + func_fatal_error can't build $host shared library unless -no-undefined is specified + fi fi else # Don't allow undefined symbols. -- 1.7.2.3 I've tested this patch with the default and --disable-static configurations under Windows and Linux and it behaved as expected. Maybe the error message could be improved but I tried to remain consistent with the existing warning, if this consideration is not important it might be better to be more explicit about the problem and its potential solution. PR But fixing that is a separate issue from what the default behavior PR should be when -no-undefined is not specified. I agree with this but I still disagree that the current default behaviour is useful. IMO both (C1) and (C3) should try to build a shared library even if -no-undefined was not given and simply either stop with a fatal error or fall back to a static library if it failed. I don't see how could getting a shared library in addition to the static one in the case (C3) could ever be a problem and getting the expected result in the case (C1) is definitely an advantage and not a drawback. But I won't discuss this any more as I don't have any new arguments and apparently the ones I already gave were insufficiently convincing. Regards, VZ pgpgD5ub1Glcm.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool won't link with static libraries (solved)
*** Warning: Trying to link with static lib archive /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. Ok, finally figured out what's going on here. libtool is in fact doing the correct thing, the static library should not be linked in with the shared library I am building (otherwise things could end up being defined multiple times when linked against the shared library.) The undefined references I was getting were in fact unrelated to the error, and were caused by issues between Boost and mingw32. Luckily a simple #define could remove the offending code and everything compiled successfully, with the above warning still appearing. When the time came to compile actual executables, libtool correctly linked in both the shared and static libraries as requested, so everything now works as expected! Cheers, Adam. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool won't link with static libraries
*** Warning: Trying to link with static lib archive /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. I've discovered that if I manually add the .a files back into the g++ command that libtool runs, then it will be linked correctly. So the problem is definitely due to libtool discarding the .a files given to it instead of listing them along with the other libraries when it calls g++. Does anyone know what could cause this? Or how to force libtool to pass the filename through as-is? Thanks, Adam. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool won't link with static libraries
On Wednesday, April 27, 2011 22:49:11 Adam Nielsen wrote: I'm trying to cross-compile a library under Linux to produce a Win32 .dll. It needs to link in with static Boost libraries (which were also cross compiled on the same machine) but libtool seems to refuse to do this: *** Warning: Trying to link with static lib archive /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. This is the libtool command in question - but as it is all handled by autoconf I'm not sure what I'm doing wrong! /bin/sh ../libtool --tag=CXX --mode=link i486-mingw32-g++ -g -O2 -release 0.1 -version-info 0 -no-undefined -o libblah.la -rpath /usr/i486-mingw32/local/lib blah1.lo blah2.lo /usr/i486-mingw32/lib/libboost_system-mt-s.a /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a /usr/i486-mingw32/lib/libboost_system-mt-s.a -L/usr/i486-mingw32/local/lib -lblah3 I get a second error the same as the first for the other .a file. The two libraries are definitely not being linked, because the next step in the process results in: .libs/blah.o: In function `__static_initialization_and_destruction_0': /usr/lib/gcc/i486-mingw32/4.5.2/../../../../i486-mingw32/include/boost/syst em/error_code.hpp:214: undefined reference to `boost::system::generic_category()' /usr/lib/gcc/i486-mingw32/4.5.2/../../../../i486-mingw32/include/boost/syst em/error_code.hpp:215: undefined reference to `boost::system::generic_category()' /usr/lib/gcc/i486-mingw32/4.5.2/../../../../i486-mingw32/include/boost/syst em/error_code.hpp:216: undefined reference to `boost::system::system_category()' collect2: ld returned 1 exit status when statically linking, order is significant -mike signature.asc Description: This is a digitally signed message part. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool won't link with static libraries
*** Warning: Trying to link with static lib archive /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. when statically linking, order is significant -mike I just tried putting the .a files first, before any of the object files, as well as before and after the object file where the undefined references appear, but in every case I get the libtool warnings that it's not linking the library and then of course the resulting undefined references. Where should I be placing the libraries on the command line so that libtool will not ignore them? Thanks, Adam. ___ https://lists.gnu.org/mailman/listinfo/libtool
libtool won't link with static libraries
Hi all, I'm trying to cross-compile a library under Linux to produce a Win32 .dll. It needs to link in with static Boost libraries (which were also cross compiled on the same machine) but libtool seems to refuse to do this: *** Warning: Trying to link with static lib archive /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. This is the libtool command in question - but as it is all handled by autoconf I'm not sure what I'm doing wrong! /bin/sh ../libtool --tag=CXX --mode=link i486-mingw32-g++ -g -O2 -release 0.1 -version-info 0 -no-undefined -o libblah.la -rpath /usr/i486-mingw32/local/lib blah1.lo blah2.lo /usr/i486-mingw32/lib/libboost_system-mt-s.a /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a /usr/i486-mingw32/lib/libboost_system-mt-s.a -L/usr/i486-mingw32/local/lib -lblah3 I get a second error the same as the first for the other .a file. The two libraries are definitely not being linked, because the next step in the process results in: .libs/blah.o: In function `__static_initialization_and_destruction_0': /usr/lib/gcc/i486-mingw32/4.5.2/../../../../i486-mingw32/include/boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()' /usr/lib/gcc/i486-mingw32/4.5.2/../../../../i486-mingw32/include/boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()' /usr/lib/gcc/i486-mingw32/4.5.2/../../../../i486-mingw32/include/boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()' collect2: ld returned 1 exit status Can anyone offer any pointers as to what might be going on? Why won't libtool use the static library? Many thanks, Adam. ___ https://lists.gnu.org/mailman/listinfo/libtool
Linking together .dll using .a static libraries (2)
I want to explain the question a bit more. I have in a .dll library implemented, e.g.: FreeContextBuffer(NULL); For this function I need to refer to libsecur32.a. How can I do that? libhello_la_LDFLAGS = -no-undefined -avoid-version -lsecur32 does not work with cygwin. Thanks for help Hanro -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ http://lists.gnu.org/mailman/listinfo/libtool
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 ... 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
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: Linking together .dll using .a static libraries
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET: LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be x86 archive import or x86 DLL, but not x86 archive static. Some of those libraries are always linked as example mingwex. Which libraries are this exactly (for various MinGW versions), and are any of these import libs? For the non-import default-linked ones, we should probably add exceptions to libtool to accept them, but I'm not sure whether that is the right thing here. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking together .dll using .a static libraries
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive import or x86 DLL, but not x86 archive static.
Some of those libraries are always linked as example mingwex.
Which libraries are this exactly (for various MinGW versions), and are
any of these import libs?
quote for gcc spec file:
==
*lib:
%{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32
-ladvapi32 -lshell32
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
==
- mingwthrd: import, specific
- mingw32: static
- moldname: import (for functions without underscore)
- mingwex: static
- msvcrt+other xx*32: import (runtime)
mingwex is a specific extension. As example library add float and long
double functions missing in msvcrt. Version 3.15 (3.14 ?) add posix
compatible IO.
For the non-import default-linked ones, we should probably add
exceptions to libtool to accept them, but I'm not sure whether
that is the right thing here.
Thanks,
Ralf
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking together .dll using .a static libraries
LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be x86 archive import or x86 DLL, but not x86 archive static. Some of those libraries are always linked as example mingwex. Also you may pass flags to the linker: -Wl... Libtool pass it to the linker, i.e. you may pass def-file or library (-lXXX) . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Linking together .dll using .a static libraries
OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be x86 archive import or x86 DLL, but not x86 archive static. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: disable static libraries?
* Ed Hartnett wrote on Tue, May 13, 2008 at 09:46:11PM CEST: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: (The .a file is always a static library, right?) Not on AIX. AIX differentiates between the notion of 'shared object' and 'shared library'. Are there other systems where this can occur? (That is, a shared library in a .a file?) Not that I know of. I have a intel C/Fortran compiler on a Linux system which is doing the same thing: building --enable-shared, and seemingly working fine, but in the end installing only a .a file. Sounds like a bug. Does it build a shared library? Even one where the Fortran driver is used for linking? Could be that libtool doesn't know how to build shared libs with this Fortran compiler (which is it?) or that it cannot build them at all. Perhaps intel compilers also package their shared libraries in .a files... No. That is not compiler-, but system-dependent. Being able to create shared libraries at all may be compiler-dependent. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
disable static libraries?
Howdy all! What does it mean while I get the following response to ./libtool --features bash$ ./libtool --features host: powerpc-ibm-aix5.1.0.0 enable shared libraries disable static libraries Does this mean that static libraries will not be built on this platform? Yet my build is having the problem of installing only the static library. (The .a file is always a static library, right?) Thanks, Ed -- Ed Hartnett -- [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: disable static libraries?
(The .a file is always a static library, right?) Not on AIX. AIX differentiates between the notion of 'shared object' and 'shared library'. A shared object is a single object file that has the Shared object SHROBJ flag in the XCOFF header. A shared object normally has a name of the form name.o (and it is archived in the library as such). A shared library refers to an ar format archive library, where one or more of the archive members is a shared object. Note that the library can also contain regular, non-shared object files, which are handled in the normal way by the linker. A shared library normally has a name of the form libname.a, though you can also name it libname.so. Look for the Developing and Porting C and C++ Applications on AIX guide on IBM's website. Chapter 2 in particular provides a nice introduction to these concepts. Cheers, - Matteo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: disable static libraries?
On Tue, 13 May 2008, Ed Hartnett wrote: Yet my build is having the problem of installing only the static library. (The .a file is always a static library, right?) No. There is an OS called AIX which can deliver shared libraries with this extension. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: disable static libraries?
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: (The .a file is always a static library, right?) Not on AIX. AIX differentiates between the notion of 'shared object' and 'shared library'. A shared object is a single object file that has the Shared object SHROBJ flag in the XCOFF header. A shared object normally has a name of the form name.o (and it is archived in the library as such). A shared library refers to an ar format archive library, where one or more of the archive members is a shared object. Note that the library can also contain regular, non-shared object files, which are handled in the normal way by the linker. A shared library normally has a name of the form libname.a, though you can also name it libname.so. Wonderful! Thanks Matteo! The only reason I thought there was a problem was the absence of the .so file, so I am delighted to hear this. It means this is one of those rare occasions where something looked broken, but wasn't! ;-) Are there other systems where this can occur? (That is, a shared library in a .a file?) I have a intel C/Fortran compiler on a Linux system which is doing the same thing: building --enable-shared, and seemingly working fine, but in the end installing only a .a file. Perhaps intel compilers also package their shared libraries in .a files... I know that macs use .dylib, HPs use .sl, (and I thought CYGWIN used .lib, but I may be wrong there). Thanks, Ed -- Ed Hartnett -- [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: disable static libraries?
From: Ed Hartnett [EMAIL PROTECTED] Date: Tue, 13 May 2008 07:33:02 -0600 (The .a file is always a static library, right?) Not on AIX. A .a file can be a shared library, a static library, or some combination of the two. Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Can't build Win32 DLL that links with static libraries
Hi Neil, * Neil Roberts wrote on Sat, Mar 01, 2008 at 08:24:22PM CET: As I understand it, when linking a shared library libtool checks whether all of the dependencies are found and that they are valid libraries. In the old version of libtool it just did this using objdump which reports the same string regardless of whether the library it finds is static or an import library. However in the new version it will use func_win32_libid if the 'file' command is available. That function returns a different string depending on whether the library is static or import. The regular expression that is tested on this string only accepts import libraries which makes it imposible to link against static libraries. Is this intentional? Yes, I think this was a conscious decision made by the Cygwin/MinGW maintainers of Libtool. Why would you want to stop people linking against static libraries? AFAIK for cleanliness issues. You shouldn't do this on other systems, so it's encouraged to also not do it on w32. I've attached a patch which fixes it for my by just allowing it to match against static libraries as well. A similar patch has been rejected before, for these reasons. (This isn't a rejection, but an AFAIR. For arguing it, it would probably help to look up previous discussions on this.) Hope that helps. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Can't build Win32 DLL that links with static libraries
Hi, I'm using libtool to cross-compile a Windows DLL (Clutter) from a Linux box. The Windows version of the library depends on a static library called libGLee. This works fine in older versions of libtool but in the version in my Ubuntu installation (1.5.24) it resorts to building a static library with a warning about libGLee. As I understand it, when linking a shared library libtool checks whether all of the dependencies are found and that they are valid libraries. In the old version of libtool it just did this using objdump which reports the same string regardless of whether the library it finds is static or an import library. However in the new version it will use func_win32_libid if the 'file' command is available. That function returns a different string depending on whether the library is static or import. The regular expression that is tested on this string only accepts import libraries which makes it imposible to link against static libraries. Is this intentional? Why would you want to stop people linking against static libraries? I've attached a patch which fixes it for my by just allowing it to match against static libraries as well. Thanks, - Neil --- libtool-2.1b/libltdl/m4/libtool.m4 2008-01-30 12:02:43.0 + +++ libtool-2.1b-patched/libltdl/m4/libtool.m4 2008-03-01 18:41:02.0 + @@ -2974,7 +2974,7 @@ bsdi[[45]]*) cygwin*) # func_win32_libid is a shell function defined in ltmain.sh - lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' + lt_cv_deplibs_check_method='file_magic ^x86 archive (import|static)|^x86 DLL' lt_cv_file_magic_cmd='func_win32_libid' ;; @@ -2983,7 +2983,7 @@ mingw* | pw32*) # func_win32_libid shell function, so use a weaker test based on 'objdump', # unless we find 'file', for example because we are cross-compiling. if ( file / ) /dev/null 21; then -lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' +lt_cv_deplibs_check_method='file_magic ^x86 archive (import|static)|^x86 DLL' lt_cv_file_magic_cmd='func_win32_libid' else lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?' ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: changes between linking with shared objects and static libraries
Hello Henning, * Henning Nielsen Lund wrote on Sat, Feb 16, 2008 at 11:04:47AM CET: I am working on making it more easy to make shared libraries (Patch #6416) and using them for AmigaOS4. Now my big problem comes... when we link our executables using shared objects, do we need to include -use-dynld -Lsobjs: or -use-dynld -L/sobjs to the line. Are these two possibilities equivalent, and if not, when to use which? Is /sobjs a path to search shared libraries in? Then, if not for any other matter, the latter form should be preferred, as libtool will then be able to understand that, too, and look in /sobjs for deplibs. Are these flags needed also when creating shared libraries, or creating shared libraries that link against other libraries? More generally, is there some documentation available regarding the AmigaOS4 shared library implementation (and the compiler and the linker)? Is it in libtool, autoconf or automake that I need to make changes to make this work? Good question. As a first approximation, the user can workaround using ./configure LDFLAGS=-use-dynld -L/sobjs Since libtool is not typically used if all a package does is link against installed libraries (but not build any itself), then libtool would be the wrong place for this. The gnulib module havelib could be a place, but I guess Automake or Autoconf, possibly, too. I do wonder a bit, if these flags are always needed, why not make them the default inside the compiler? That would be so much simpler. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
changes between linking with shared objects and static libraries
Hello I am working on making it more easy to make shared libraries (Patch #6416) and using them for AmigaOS4. Now my big problem comes... when we link our executables using shared objects, do we need to include -use-dynld -Lsobjs: or -use-dynld -L/sobjs to the line. Is it in libtool, autoconf or automake that I need to make changes to make this work? -- best regards, hnl_dk - Henning Nielsen Lund µA1-C (IBM PowerPC 750 FX V2.2 @ 800MHz), 256MB RAM, NEC ND-3500A DVD/CD RW, Samsung SP1604N 160GB PATA Harddisk drive, Acer AL1721 17 TFT, modified Tyan M2042 1-3 PCI Riser... ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating ONLY static libraries
On 8/21/07, Jason Curl [EMAIL PROTECTED] wrote: If you don't need to have the libraries installed for a convenience library, use noinst_*. See: http://www.gnu.org/software/automake/manual/automake.html#A-Library Similarly for libtool: http://www.gnu.org/software/libtool/manual.html#Static-libraries The answer from Mike is correct, they're static libraries that other programs may link to if wanted. How do you plan to use this library? I am trying to build some program under Cygwin/X and it seemed that there is some sort of problem with linking to one of the libraries (*.la) which were made during the build process. anyway after I added --disable-shared to configure, the build process went O.K. and I didnt get no ld error. I am still not sure if the problem is from Libtool or Cygwin/X (my guess is Cygwin/X) , but for now I am quite satisfied with the static libraries as is. thank you all for your help ! Azencot Omri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating ONLY static libraries
Omri Azencot wrote: Hello I am using libtool 1.5.23 during the building process, I am also using autoconf(2.61) to create the configure file. in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got the following line: checking whether to build shared libraries... no but, after make install the package did installed in the installation folder files of the type *.la *.dll.a. My goal is to create only static libraries of this module, am I missing something ? If you don't need to have the libraries installed for a convenience library, use noinst_*. See: http://www.gnu.org/software/automake/manual/automake.html#A-Library Similarly for libtool: http://www.gnu.org/software/libtool/manual.html#Static-libraries The answer from Mike is correct, they're static libraries that other programs may link to if wanted. How do you plan to use this library? ___ http://lists.gnu.org/mailman/listinfo/libtool
Creating ONLY static libraries
Hello I am using libtool 1.5.23 during the building process, I am also using autoconf(2.61) to create the configure file. in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got the following line: checking whether to build shared libraries... no but, after make install the package did installed in the installation folder files of the type *.la *.dll.a. My goal is to create only static libraries of this module, am I missing something ? thanks in advance Azencot Omri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -static does not select static libraries very well anymore ...
Hello Roger, * Roger March wrote on Fri, Jan 05, 2007 at 08:52:57PM CET: I have been using libtool 1.5.18 for my builds for awhile. The applications link against libraries containing both static and shared versions. When 1.5.18 is linked with the '-static' flag, it seems to pretty much select a static version for every library it can. When 1.5.22 is used it seems to always go for the shared version if present. Has there been a conscious change in the semantics of '-static'? What should the behavior of '-static' be in the face of mixed static-shared links? Thanks. Please see this thread: http://thread.gmane.org/gmane.comp.gnu.libtool.general/7097/focus=6715. We need to get 1.5.24 out. Cheers, and a happy New Year, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
-static does not select static libraries very well anymore ...
I have been using libtool 1.5.18 for my builds for awhile. The applications link against libraries containing both static and shared versions. When 1.5.18 is linked with the '-static' flag, it seems to pretty much select a static version for every library it can. When 1.5.22 is used it seems to always go for the shared version if present. Has there been a conscious change in the semantics of '-static'? What should the behavior of '-static' be in the face of mixed static-shared links? Thanks. -- Roger March, [EMAIL PROTECTED], (408) 399-5406 IC Manage Inc, 101 Church St, ste 17, Los Gatos, CA, 95030 ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Libtool -release and static libraries.
I just noticed that the messages that i have sent are coming through slightly corrupted. I am going to have to find out what is causing the corruption when i get back to work, but anyway. The automake variables i have provided are being replaced with: address @ hidden @ That is not what they are supposed to be, instead they should look more like below (I have seperated each element here with a space character in the hope that they will not be translated like previous emails): libatcppunit _ la _ CPPFLAGS = -I$(top_builddir)/src libatcppunit _ la _ LDFLAGS = -release $(PACKAGE_VERSION) libatcppunit _ la _ LIBADD = I think this may have caused some confusion before... I hope that can clear up understanding my previous emails. Thanks, Brendon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool -release and static libraries.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am using libtool version 1.5.18 to create a library I wrote for unit testing. It has come to the stage where I would find it useful to have multiple versions of this library installed at any point in time on my machine. I had a look at the -version-info option, and that does not quite achieve what I desire, however the -release tag is what I want. The problem is however that the static libraries are still named libatcppunit.a and not libatcppunit-1.0.6.a as I would have expected. So various versions of the static library can not co-exist. Note: The dynamic libraries are correctly named libatcppunit-1.0.6.so, its just the static ones that are not. Is there any way to get libtool to name this static library, libatcppunit-1.0.6.a? It would still be desirable for a libatcppunit.a to exist, but for projects that need a specific version they would link with a particular version of the library. I thought I would ask this question here, as I had a look on the web, and someone else has brought this issue up in the past but I could not see any resolution for it. For reference the address to the other message is: http://lists.gnu.org/archive/html/libtool/2002-09/msg00126.html Thanks, Brendon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD86wYPfREiUgoLqwRAsU3AJ95SJ3CJCCe8NosJYJyR3CD6s6V8QCgqsO6 AFYTgtrZLNKwRMbQVCPON8o= =kW0x -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool -release and static libraries.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brendon Costa wrote: | Hi all, | | I am using libtool version 1.5.18 to create a library I wrote for | unit testing. It has come to the stage where I would find it useful to | have multiple versions of this library installed at any point in time | on my machine. | | I had a look at the -version-info option, and that does not quite | achieve what I desire, however the -release tag is what I want. The | problem is however that the static libraries are still named | libatcppunit.a and not libatcppunit-1.0.6.a as I would have expected. | So various versions of the static library can not co-exist. | | Note: The dynamic libraries are correctly named libatcppunit-1.0.6.so, | its just the static ones that are not. Since you seem to want libatcppunit-1.0.6 to be the library name, I suggest that you use it as the library name :) lib_LTLIBRARIES = libatcppunit-1.0.6.la This means that the libatcppunit.so symlink will also disappear (but that's what you want, right?) and you'll have to use -latcppunit-1.0.6 to link the library. The other alternative is for us to change libtool so that static libraries are versioned and symlinked like shared libraries, but I don't think that the way to go. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ/Po/LiDAg3OZTLPAQI+bAP/btHsxkC07quuT0bSdi0ulUosSvMwJNlU rnZaV5dtdYIbdSUlo4j22y+DS5gehrf/vPqqEPXDk+Yer/I5baJPO4LElwYSYfMd GY7PcOVfs4qNzt83nWSzR4J4pAzGFo5p2oG0xO0yT2AK3n8jVgHDJ+Eyy7mh1FvR kpKYNEdwx6w= =4Q9n -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Solaris, linking in static libraries into the shared libraries
Good day! The problem, mentioned in http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00040.html, appears to persist in both 1.5.22 and HEAD. Just FYI, hope, that You haven't forgotten it:))) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool 1.5.20, Solaris, linking in static libraries into the shared libraries
Excuse me, i have forgotten the attach in last message, now i resend. Good day! There is a following problem using CC v5.5 (v5.6 from Studio 10 does show the same behaviour). I compile the sources (attached). test1 prints the message, while test2 doesn't. That is because when we compile static library into the shared, using the string: libtool --mode=link CC -rpath /tmp -o libcon2.la dummy.lo libcon.la It becomes: CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0 .libs/dummy.o -Qoption ld -z -Qoption ld allextract,./.libs/libcon.a -Qoption ld -z -Qoption ld defaultextract -lCstd -lCrun -lc Which is considered wrong, the string must look like: CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0 .libs/dummy.o -z allextract ./.libs/libcon.a -z defaultextract -lCstd -lCrun -lc As stated here: http://forum.sun.com/thread.jspa?threadID=27249tstart=0 PS. *giggle* I remember that some time ago this has been changed into the current form because of a problem with CC5.3 on Solaris 8. On 5.3 it still doesn't work in any form. But on 5.5 and 5.6 it helps. So the idea wl=-z looks better and better:) test.tar.gz Description: GNU Zip compressed data ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.20, Solaris, linking in static libraries into the shared libraries
Hi Yuri, * Pooh wrote on Mon, Oct 31, 2005 at 11:31:24AM CET: There is a following problem using CC v5.5 (v5.6 from Studio 10 does show the same behaviour). I compile the sources (attached). test1 prints the message, while test2 doesn't. That is because when we compile static library into the shared, using the string: (Side note: you mean what in Libtool lingo is called a `convenience archive' rather than a static library; the objects in the archive contain position-independent code, PIC). libtool --mode=link CC -rpath /tmp -o libcon2.la dummy.lo libcon.la It becomes: CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0 .libs/dummy.o -Qoption ld -z -Qoption ld allextract,./.libs/libcon.a -Qoption ld -z -Qoption ld defaultextract -lCstd -lCrun -lc Which is considered wrong, the string must look like: CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0 .libs/dummy.o -z allextract ./.libs/libcon.a -z defaultextract -lCstd -lCrun -lc As stated here: http://forum.sun.com/thread.jspa?threadID=27249tstart=0 There is a partly related bugfix pending: http://lists.gnu.org/archive/html/libtool-patches/2005-10/msg00111.html Does CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0 -z \ allextract ./.libs/libcon.a -z defaultextract -lCstd -lCrun -lc work as well? For which compiler/Solaris versions (print `CC -V')? (I assume not, that's probably why you added the dummy.lo in the first place, right?) PS. *giggle* I remember that some time ago this has been changed into the current form because of a problem with CC5.3 on Solaris 8. Yes, I know. On CVS HEAD, I'll probably just set whole_archive_flag_spec= so libtool will do the extracting and not use `allextract' at all, because of above mentioned dummy-bug. On 5.3 it still doesn't work in any form. But on 5.5 and 5.6 it helps. So the idea wl=-z looks better and better:) What I haven't understood yet is why we use `-Qoption' at all. There must be some combination where `-z' doesn't work as expected. (Haven't checked the archives for this yet..) By the way, another question (since you seem to have access to a number of compiler/system version): Does the addition of `-lCstd -lCrun' cause the C++ library symbols to be copied into the created library, or are they linked dynamically? If the former: for which compiler/system versions? You should read this thread for more info on this: http://lists.gnu.org/archive/html/libtool/2005-08/msg00088.html If you can provide additional useful information, the better, but be sure to always specify which compiler/system versions you are speaking about. Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Including static libraries in shared libraries with libtool.
Howard Chu wrote: One more time, shouting into the senseless void... If these so-called convenience libraries are meant to be linked in whole, they should not be ar archives at all. You should just link them directly into a relocatable object file: ld -r -o convenience.obj *.o I am listening, and I have taken this under advisement, and plan to start the transition to reloadable objects after the dust on 2.0 has settled. Thanks for persevering with us. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
Hi, My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. Not possible without reimplementing parts of the linker. Parts of static libraries cannot be linked into shared libraries, as shared libs need to be compiled as position independent code (ld.so on ix86 linux can work around that by mapping the offending library into a private mapping and relocating it, but that is a huge waste of memory and not portable). Unfortunately, the actual results are different. There are two problem: 1. Libtool takes _all_ modules from libauth.la, and puts them into libauthuserdb.la. I only want the modules that libauthuserdb.la actually needs. A convenience library, as a libtool library that is not installed is called, is linked into each object that uses it. If the object is a library, it is copied completely, otherwise, it is linked statically. This feature is intended for huge libraries that are built from multiple subdirectories, where each subdir builds a convenience lib and everything is linked in the end. 2. For some reason, only the static version of libauthuserdb.la is generated. I don't know why, but libauthuserdb.so is not created, only libauthuserdb.a is created. I am _not_ using the --disable-shared flag with the configure script. There is no way to build a shared library, as parts of it are only available as non-PIC code. However, this is not practical. I'm building several shared libraries that use different bits and pieces of the common code, and manually tracking which common source module is used by which shared library is cumbersome. I need to coerce libtool in doing this job for me. If there may be additional shared libs that may be built outside of the source tree, you may be better off making a ...-util library that is installed and linked by all of your other libraries. This is transparent to the user, but permits everyone to write their own libraries linking against the -util library. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
Simon Richter writes: Hi, My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. Not possible without reimplementing parts of the linker. Parts of static libraries cannot be linked into shared libraries, as shared libs need to be compiled as position independent code (ld.so on ix86 linux can work around that by mapping the offending library into a private mapping and relocating it, but that is a huge waste of memory and not portable). I can create a static library from PIC modules that libtool already builds. It actually turns out to be fairly easy: libshuserdb.a: libuserdb.la -rm -f $@ cd .libs $(AR) $(ARFLAGS) ../$@ $(libuserdb_la_OBJECTS:.lo=.o) If there may be additional shared libs that may be built outside of the source tree, you may be better off making a ...-util library that is installed and linked by all of your other libraries. This is transparent to the user, but permits everyone to write their own libraries linking against the -util library. Let's explore this possibility. I have about a dozen small components (a component=library) other. Each component is in its own subdirectory. It can be built, if necessary, by itself. The components are not installed, they are just building blocks. Then, there are several installable shared libraries. Each shared library makes use of various bits and pieces from various component libraries. Your suggestion, as I understand it, is to take all the small component libraries and put them together into a single -util, that every installable shared links against. Fair enough, bit libtool doesn't seem to be able to do that. libutil_la_SOURCES=[ file listing ] libutil_la_LIBADD=subdir1/libcomponent1.la subdir2/libcomponent2.la From what I can see, libtool is not going to add libcomponent1.la and libcomponent2.la to the shared version of libutil.la, it will merely record their SONAME, and I still have to install libcomponent1.so and libcomponent2.so, in addition to libutil.so. Now on the static side, it looks like libtool will methodically unpack libcomponent1.a and libcomponent2.a; then put all of the extracted modules into libutil.a, together with libutil.a's own object modules, so libutil.a has everything. That, pretty much, is what I need to do with the shared library version as well. My component libraries are logically grouped, and each one is dedicated to a specific functionality. I'd rather not break everything up, and manually force everything into libutil.so, making for a big mess. pgpkGx0DsKG4o.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
On Sun, 26 Sep 2004, Simon Richter wrote: 1. Libtool takes _all_ modules from libauth.la, and puts them into libauthuserdb.la. I only want the modules that libauthuserdb.la actually needs. A convenience library, as a libtool library that is not installed is called, is linked into each object that uses it. If the object is a library, it is copied completely, otherwise, it is linked statically. This feature is intended for huge libraries that are built from multiple subdirectories, where each subdir builds a convenience lib and everything is linked in the end. Using recent Automake, I find that I am able to eliminate use of convenience libraries by using a non-recursive build and referring to sources in subdirectories. A simple Automake macro refers to all the objects which would be equivalent to a convenience library. Works great and avoids the overhead imposed by libtool since libtool must extract all the objects from the archive file prior to using them. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Including static libraries in shared libraries with libtool.
I'm trying to do the following with libtool, and it's not quite doing exactly what I want. Can someone suggest the correct way to do the following, with libtool 1.5.6 and automake 1.8.3 on Linux: I'm building several shared libraries. These shared libraries use common code from several static libraries, which I'll refer to as component libraries. Here's an example component library: libauth_la_SOURCES=auth.h authexit.c chain.c checkpassword.c \ [ more sources go here ] libauth_la_LDFLAGS=-static libauth.la is not going to get installed by the final application. It's an internal library whose only intended purpose is to provide some common code for a bunch of shared libraries that will be installed. Here's one such shared library: libauthuserdb_la_SOURCES=authuserdb.c preauthuserdb.c \ [ more sources ] libauthuserdb_la_DEPENDENCIES=libauth.la libauthuserdb_la_LIBADD=libauth.la libauthuserdb_la_LDFLAGS=-module My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. In other words: look up all unresolved symbols from libauthuserdb.la's sources which can be found in the libauth.la. Take whatever modules from libauth.la that libauthuserdb.la needs, and generate a .so containing libauthuserdb_la_SOURCES plus whatever the sources need that can be found in libauth.a Unfortunately, the actual results are different. There are two problem: 1. Libtool takes _all_ modules from libauth.la, and puts them into libauthuserdb.la. I only want the modules that libauthuserdb.la actually needs. 2. For some reason, only the static version of libauthuserdb.la is generated. I don't know why, but libauthuserdb.so is not created, only libauthuserdb.a is created. I am _not_ using the --disable-shared flag with the configure script. I'd like to come up with a solution to do what I want without rearchitecturing the source. Of course, I could simply take the requisite libauth_la_SOURCES, manually add them to libauthuserdb_la_SOURCES, and build a garden-variety shared library, without a dependency on a static library. However, this is not practical. I'm building several shared libraries that use different bits and pieces of the common code, and manually tracking which common source module is used by which shared library is cumbersome. I need to coerce libtool in doing this job for me. pgp8bh9cN9OJc.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
libtool and gcj static libraries
I have been unable to create a static library of java sources using libtool. $ cat Makefile.am noinst_LTLIBRARIES = libhello.la libhello_la_SOURCES = HelloWorld.java $ make libhello.la /bin/sh ./libtool --mode=link gcj-3.4 -g -O2 -o libhello.la HelloWorld.lo rm -fr .libs/libhello.la creating libhello.la (cd .libs rm -f libhello.la ln -s ../libhello.la libhello.la) It does not generate libhello.a. I've tried changing noinst to lib, in which case I get a dynamic library and no static library. I've tried adding -static to the LDFLAGS, which also doesn't work. Can libtool be used to make a static library of java sources? Please cc me in your reply. Thanks! Shaun ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: pkg-config and versioning of static libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Friesenhahn wrote: | On Wed, 17 Dec 2003, Pavel Roskin wrote: | |libhello-5.6.so is created in .libs, but libhello-5.6.a is not. Neither |is it created during installation. | |The problem may be in pkg-config, but if so, I need very good arguments |why libtool doesn't use versioning for static libraries. | |My question is - is the lack of versioning for static libraries a |limitation of libtool or is a something that pkg-config should work |around? | | | This sounds like a libtool bug to me. Agreed. I presume that because static libs do not have interface versions encoded into their sonames like shared libs, the same ideom was blindly carried over to the release version code. I would be happy to apply a patch that fixes this shortcoming. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/+VbsFRMICSmD1gYRAoxNAJ9BoyZ7PNNTih/PlV+dYI0HkNiTcQCgxlbx pBXG9Pdy09Rs62xlEJ9st5g= =dLqA -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
pkg-config and versioning of static libraries
Hello! I've received a bugreport that GNU Midnight Commander cannot be compiled statically on Gentoo Linux. The fix is to replace -lglib-2.0 with -lglib in the command line. Midnight Commander doesn't use libtool, but glib 2.x does. glib also used pkg-config. Following command is used to request static linking: ./configure LDFLAGS=-Wl,-static The configure script blindly trusts the output of pkg-config. That's what pkg-config developers want us to do - the macro file pkg.m4 comes from pkg-config. To get the list of the libraries (in the form suitable for the compiler command line), following command is run: pkg-config --libs glib-2.0 The result is -lglib-2.0. pkg-config doesn't know that static linking was requested. There is no option for that. So the output is the same for shared and static libraries. For this to work, libglib-2.0.a should be available to the linker. It exists on Debian unstable and Fedora Core 1, but not on Gentoo. It may surprise you, but the existence of libglib-2.0.a appears to be a workaround for a libtool bug. glib by itself doesn't create versioned static libraries. And that behavior comes from libtool. I'm not talking about correct versioning with -version-info, but about hard versioning using the -release option. Let's compile CVS libtool with tests and run following in tests/demo: ./libtool --mode=link gcc -g -O2 -o libhello.la -rpath /usr/local/lib \ -no-undefined -release 5.6 hello.lo foo.lo -lm libhello-5.6.so is created in .libs, but libhello-5.6.a is not. Neither is it created during installation. The problem may be in pkg-config, but if so, I need very good arguments why libtool doesn't use versioning for static libraries. My question is - is the lack of versioning for static libraries a limitation of libtool or is a something that pkg-config should work around? I checked the archives and found that proposals to add versioning for static libraries were posted, but I could not find anything that would explain position of the libtool developers in this question. I don't want to add libtool support for GNU Midnight Commander just because it's linked against glib. If you think it's a good idea, I'd like to hear arguments. -- Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: pkg-config and versioning of static libraries
On Wed, 17 Dec 2003, Pavel Roskin wrote: libhello-5.6.so is created in .libs, but libhello-5.6.a is not. Neither is it created during installation. The problem may be in pkg-config, but if so, I need very good arguments why libtool doesn't use versioning for static libraries. My question is - is the lack of versioning for static libraries a limitation of libtool or is a something that pkg-config should work around? This sounds like a libtool bug to me. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On 26.09.2003 02:44:28 [EMAIL PROTECTED] wrote: Bob Friesenhahn wrote: On Thu, 25 Sep 2003, Bernhard Rumpler wrote: When I try to link static libraries, then a warning Linking the shared library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is not portable! is displayed. What does not portable mean in this context? I suspect that this complaint is because the library doesn't have versioning information as part of its name. This complaint is because libhtmllayouthtml.la was linked with the -module flag to libtool, which means it is meant to be a dlopenable module, and on some platforms (Mac OS X/darwin NetBSD/a.out) may not be used as input to the linker. If libhtmllayouthtml.la was not linked with the -module flag, it is a bug. no, it is not linked with the -module flag. Could the problem be caused by my modifications of the respective .la-file, as described in another message of this thread: Bernhard Rumpler wrote: For now I always have to modify the respective .la files of the .a files in the subdirectories, to be able to link them. For this I set library_name (?? is this OK??) to the name of the .a file, installed=yes and the libdir to the respective .libs directory containing the .a file. Not a very good solution, and I'm also quite unsure, if this can cause problems. thanks, Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
Tor Lillqvist wrote: I have found that to ensure a mixture of Cygwin-based tools (for instance shell scripts that run under a Cygwin shell, or Cygwin Perl scripts) and native (mingw) tools interoperate reliably one needs to make sure that the same paths are valid (and point to the same files) in both. This isn't that hard. If you have sources in for instance e:\some\place, and do your builds there, make sure that e:\some is mounted in Cygwin as /some. And if you do make installs, and/or use installed libraries and headers for some package, make sure that the same holds for the installation location, and that it is on the same drive. (For instance if you install to, or use stuff installed in, e:\another\place, mount e:\another as /another.) which kind of problems can be avoided with this setup? One problem for me is that (even if I mount c: as /c) libtool always creates unix-style paths (e.g., /c/somewhere/.libs/libfoo.la) but mingw-gcc does not understand that. The problem is that this always occurs, when a library is built and the source code is organized in a number of subdirectories, and intermediate .a and .la files are generated for the subdirectories, which are then used to build up the .dll (or some other .a files) in higher level directories. @ Tor: This probem also occurs for some files, if I build glib-2.2.3, how do you avoid this when you build glib? Does your setup with mounting directories have any influence on this? For now I always have to modify the respective .la files of the .a files in the subdirectories, to be able to link them. For this I set library_name (?? is this OK??) to the name of the .a file, installed=yes and the libdir to the respective .libs directory containing the .a file. Not a very good solution, and I'm also quite unsure, if this can cause problems. thanks for any hints, Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
only static libraries created
Hi, I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? The problem is that the library consists of some sub-packages (sub-directories) that are linked together before the whole library is created. For those sub- packages just static library files (.a) are created, I suppose there should be .dlls that can be linked to the toplevel library, to avoid warnings like: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. As a consequence, no .dll is created in the toplevel directory, that should include all the sub-packages. I use the -no-undefined LDFLAG (set as an environment variable for configure), is this still necessary for libtool-1.5? I also tried to add the macro AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this made no difference, i read somewhere on the net that this is not required anymore. thanks, Bernhard libtool-1.5 autoconf-2.57 automake-1.7.6 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
[EMAIL PROTECTED] wrote: Hi, I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? The problem is that the library consists of some sub-packages (sub-directories) that are linked together before the whole library is created. For those sub- packages just static library files (.a) are created, I suppose there should be .dlls that can be linked to the toplevel library, to avoid warnings like: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. ^ How did you do that? -- guido *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. As a consequence, no .dll is created in the toplevel directory, that should include all the sub-packages. I use the -no-undefined LDFLAG (set as an environment variable for configure), is this still necessary for libtool-1.5? I also tried to add the macro AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this made no difference, i read somewhere on the net that this is not required anymore. thanks, Bernhard libtool-1.5 autoconf-2.57 automake-1.7.6 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@+++ y++ 5++X- (geekcode) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
You may want to ask at mingw.org for specifics. If all dependencies are resolved then a dll should be there as $subdir/.libs/*.dll - check the content of the .la files in $subdir/*.la whether it has been configured correctly to create dynalibs (it's a text file). Then do the next step. [EMAIL PROTECTED] wrote: Hi, I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? The problem is that the library consists of some sub-packages (sub-directories) that are linked together before the whole library is created. For those sub- packages just static library files (.a) are created, I suppose there should be .dlls that can be linked to the toplevel library, to avoid warnings like: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. As a consequence, no .dll is created in the toplevel directory, that should include all the sub-packages. I use the -no-undefined LDFLAG (set as an environment variable for configure), is this still necessary for libtool-1.5? I also tried to add the macro AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this made no difference, i read somewhere on the net that this is not required anymore. thanks, Bernhard libtool-1.5 autoconf-2.57 automake-1.7.6 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@+++ y++ 5++X- (geekcode) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? Alas, it is necessory for all libraries that your DLL depends on to also be built as DLLs. The problem is that the library consists of some sub-packages (sub-directories) that are linked together before the whole library is created. For those sub- packages just static library files (.a) are created, I suppose there should be .dlls that can be linked to the toplevel library, to avoid warnings like: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. As a consequence, no .dll is created in the toplevel directory, that should include all the sub-packages. I use the -no-undefined LDFLAG (set as an environment variable for configure), is this still necessary for libtool-1.5? I also tried to add the macro AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this made no difference, i read somewhere on the net that this is not required anymore. Since Windows DLLs do not allow undefined symbols, a requirement to build a DLL using libtool is to include the -no-undefined option, otherwise a static library will be built. Libtool 1.5 is much better at enforcing these rules than former versions of libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Guido Draheim wrote: [EMAIL PROTECTED] wrote: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. ^ How did you do that? -- guido Since libtool on cygwin usually generates unix/cygwin-style paths (starting with /cygdrive/[...]), MinGW-gcc was not able to link some of the newly generated libraries (.a). That's why I modified the respective .la file of the library and set 'libdir' to the correct path of the library file (and installed to 'yes'). Otherwise I was not able to proceed. Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Guido Draheim wrote: If all dependencies are resolved then a dll should be there as $subdir/.libs/*.dll - check the content of the .la files in $subdir/*.la whether it has been configured correctly to create dynalibs (it's a text file). Then do the next step. hmm, what can I check in the .la files? Whether there is a name set for 'library_names'? thanks, Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bernhard Rumpler wrote: On Thu, 25 Sep 2003, Guido Draheim wrote: [EMAIL PROTECTED] wrote: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. ^ How did you do that? -- guido Since libtool on cygwin usually generates unix/cygwin-style paths (starting with /cygdrive/[...]), MinGW-gcc was not able to link some of the newly generated libraries (.a). That's why I modified the respective .la file of the library and set 'libdir' to the correct path of the library file (and installed to 'yes'). Otherwise I was not able to proceed. Cygwin and MinGW tools differ significantly in that Cygwin tools deal with Unix paths while MinGW tools accept Windows paths. The easiest way to deal with MinGW is to use the MSYS shell which provides a limited Cygwin-like shell capable of supporting configure, make, and libtool, while automatically transforming Unix paths into the Windows paths that the tools require. While Cygwin does provide a compiler mode in which it may compile programs which use the MinGW library, there may be some problems with crossing over between the two environments. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bob Friesenhahn wrote: On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? Alas, it is necessory for all libraries that your DLL depends on to also be built as DLLs. This prerequisite is fulfilled for all dependencies. But since no .dlls are created in the subdirectories, no .dll is built for the whole library. When I try to link static libraries, then a warning Linking the shared library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is not portable! is displayed. What does not portable mean in this context? Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
Bob Friesenhahn writes: While Cygwin does provide a compiler mode in which it may compile programs which use the MinGW library, there may be some problems with crossing over between the two environments. This might be obvious to many, but anyway: I have found that to ensure a mixture of Cygwin-based tools (for instance shell scripts that run under a Cygwin shell, or Cygwin Perl scripts) and native (mingw) tools interoperate reliably one needs to make sure that the same paths are valid (and point to the same files) in both. This isn't that hard. If you have sources in for instance e:\some\place, and do your builds there, make sure that e:\some is mounted in Cygwin as /some. And if you do make installs, and/or use installed libraries and headers for some package, make sure that the same holds for the installation location, and that it is on the same drive. (For instance if you install to, or use stuff installed in, e:\another\place, mount e:\another as /another.) --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bob Friesenhahn wrote: The easiest way to deal with MinGW is to use the MSYS shell which provides a limited Cygwin-like shell capable of supporting configure, make, and libtool, while automatically transforming Unix paths into the Windows paths that the tools require. Yes, but there are no binaries of current versions of various developer tools available for MSYS, that's one problem. I have not yet tried to build gtk-related stuff with MSYS, since some people who do that (including the maintainer of the windows port) use MinGW and cygwin for that, and recommend this solution. It supposedly causes less problems. I don't know details, but I'll have to find out, if I dont't get dlls built with cygwin bash and cygwin libtool. I still hope I can do it with cygwin, there can only be a few little things I'm missing to do... While Cygwin does provide a compiler mode in which it may compile programs which use the MinGW library, there may be some problems with crossing over between the two environments. yes, but there, too, seem to exist problems with mixing up cygwin and mingw libraries. Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bernhard Rumpler wrote: On Thu, 25 Sep 2003, Bob Friesenhahn wrote: On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? Alas, it is necessory for all libraries that your DLL depends on to also be built as DLLs. This prerequisite is fulfilled for all dependencies. But since no .dlls are created in the subdirectories, no .dll is built for the whole library. Make sure that all of the DLLs are in your executable search path or may be found in a directory ../bin offset from where the .a and .la files are located. If libtool can't find the actual DLL then it will assume that the .a library is an implementation library and not an interface library for a DLL. When I try to link static libraries, then a warning Linking the shared library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is not portable! is displayed. What does not portable mean in this context? I suspect that this complaint is because the library doesn't have versioning information as part of its name. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
Bob Friesenhahn wrote: On Thu, 25 Sep 2003, Bernhard Rumpler wrote: When I try to link static libraries, then a warning Linking the shared library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is not portable! is displayed. What does not portable mean in this context? I suspect that this complaint is because the library doesn't have versioning information as part of its name. This complaint is because libhtmllayouthtml.la was linked with the -module flag to libtool, which means it is meant to be a dlopenable module, and on some platforms (Mac OS X/darwin NetBSD/a.out) may not be used as input to the linker. If libhtmllayouthtml.la was not linked with the -module flag, it is a bug. Thanks, Peter -- * Peter O'Gorman - http://www.pogma.com/ * ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Flags to strip static libraries
Does anyone know why libtool uses 'strip --strip-debug' to strip static libraries? ISTM that 'strip -x' (a.k.a. 'strip --discard-all') would be more appropriate (i.e., makes the file smaller and the library still works). -- Peter Eisentraut [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: cross-compiling question: static libraries and binaries to different places?
Es schrieb Dan Kegel: Guido Draheim wrote: ... See - the libtool crossgcc support (to which I did contribute some of the time) can simply ask the cross-gcc for the local searchpath via `gcc -print-search-dirs` - this is needed for win32 compiles atleast, and I have a patch on my disk which generalizes the idea for all cross-gcc targets (since there have been problems with crosscompiling linux-to-linux). You mean this? YES!! I just didn't know how to make an argument about it on the mailinglist, may be the sheer number of our voices can avoid that ;-) - oh btw your patch needs an enhancement for the last s/;/ /g since on unix a : is used. There was a discussion a while back about the use of path_separator here, but the final solution was to cut the line into three, and examine the raw print-search-dirs string for occurrences of ;. If yes, use that one as the path_separator, if no then use : and assume that unix path parts do never contain ; either but have : as the pathseparator. (and IIRC, there was some rumour about differences as with a gcc on win32 hosted in a unix pesonality, so you can't be that sure about the ; even on win32.). Anyway, you actually got the idea, and I didn't say anything explicit, so it makes me confident that this is an obvious flaw (a bug?) in the libtool crosscompiling support. It needs to be fixed. go ahead, I'm all with you, guido --- libtool.m4.orig Thu Mar 7 16:58:42 2002 +++ libtool.m4 Thu Mar 7 17:04:23 2002 @@ -2312,6 +2312,13 @@ dynamic_linker=no ;; esac + +# When cross-compiling, get the list of system library directories +# from gcc if possible, since hardcoded paths above are surely wrong. +if test $GCC = yes test $cross_compiling = yes; then + sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: | sed -e s/^libraries:// -e s/;/ /g` +fi + AC_MSG_RESULT([$dynamic_linker]) test $dynamic_linker = no can_build_shared=no ## I just spent two hours realizing why libtool could not link with shared libraries when cross-compiling; it ended up being exactly the thing you're talking about. I created a patch according to your suggestion on the libtool mailing list, and it makes life much nicer. Is this in CVS yet? By golly, it sure needs to be. - Dan ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: cross-compiling question: static libraries and binaries to different places?
Guido Draheim wrote: ... See - the libtool crossgcc support (to which I did contribute some of the time) can simply ask the cross-gcc for the local searchpath via `gcc -print-search-dirs` - this is needed for win32 compiles atleast, and I have a patch on my disk which generalizes the idea for all cross-gcc targets (since there have been problems with crosscompiling linux-to-linux). You mean this? --- libtool.m4.orig Thu Mar 7 16:58:42 2002 +++ libtool.m4 Thu Mar 7 17:04:23 2002 @@ -2312,6 +2312,13 @@ dynamic_linker=no ;; esac + +# When cross-compiling, get the list of system library directories +# from gcc if possible, since hardcoded paths above are surely wrong. +if test $GCC = yes test $cross_compiling = yes; then + sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: | sed -e +s/^libraries:// -e s/;/ /g` +fi + AC_MSG_RESULT([$dynamic_linker]) test $dynamic_linker = no can_build_shared=no ## I just spent two hours realizing why libtool could not link with shared libraries when cross-compiling; it ended up being exactly the thing you're talking about. I created a patch according to your suggestion on the libtool mailing list, and it makes life much nicer. Is this in CVS yet? By golly, it sure needs to be. - Dan ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
No static libraries?
I think this is my final real problem with the CVS version of libtool (once Per's patch is applied). Libtool isn't building static libraries for my project, although it does try to install them (and fail). Configuring with --disable-static is my work around. Any ideas? AG ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Fri, Mar 01, 2002 at 02:15:05PM -0800, Anthony Green wrote: I think this is my final real problem with the CVS version of libtool (once Per's patch is applied). Libtool isn't building static libraries for my project, although it does try to install them (and fail). You need to be more specific. 1. Does it fail while configuration your application to detect that static libraries can be built? 2. For what compiler (C, C++, GCJ)? A snippet of the ./configure run would help too. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Fri, 2002-03-01 at 15:32, Albert Chin wrote:
You need to be more specific
1 Does it fail while configuration your application to detect
that static libraries can be built?
I don't know what you mean exactly
2 For what compiler (C, C++, GCJ)?
GCJ (however, some of the libraries contain C as well)
A snippet of the /configure run would help too
The fact that the gcj -c -o test results in yes doesn't mean
anything I've hacked libtool to always produce that result for gcj
Thanks for your help!
AG
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking dependency style of gcc... gcc3
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output...
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag CXX to libtool
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
appending configuration tag GCJ to libtool
checking if gcj supports -fno-rtti -fno-exceptions... (cached) yes
checking for gcj option to produce PIC... -fPIC
checking if gcj PIC flag -fPIC works... no
checking if gcj supports -c -o file.o... yes
checking whether the gcj linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking for gcj... gcj
checking for gcjh... gcjh
checking dependency style of g++... gcc3
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for libraries needed for readline... -lreadline -ltermcap
configure: creating ./config.status
config.status: creating Makefile
config.status: creating pgsql-jdbc/Makefile
config.status: creating gnu.regexp/Makefile
config.status: creating cup/Makefile
config.status: creating BCEL/Makefile
config.status: creating xerces/Makefile
config.status: creating jakarta-regexp/Makefile
config.status: creating jakarta-oro/Makefile
config.status: creating jakarta-log4j/Makefile
config.status: creating xalan/Makefile
config.status: creating jakarta-servletapi/Makefile
config.status: creating jakarta-tomcat/Makefile
config.status: creating gnu.readline/Makefile
config.status: creating rhino/Makefile
config.status: creating bsf/Makefile
config.status: creating BouncyCastle
Re: No static libraries?
On Mar 1, 2002, Anthony Green [EMAIL PROTECTED] wrote:
Libtool isn't building static libraries for my project, although it does
try to install them (and fail).
What's the exact failure mode (snipped of the make output)? What does
libtool --features print? What is in the .la file that it's trying to
install?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: ranlib'ing static libraries?
On Aug 13, 2000, Assar Westerlund [EMAIL PROTECTED] wrote:
* ltconfig.in: add back ranlib calls for static libraries if there
is a ranlib
Thanks, I'm checking this in. Sorry about the delay.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Status Update Request (C++, static libraries)
Hi Kevin, On Thu, May 18, 2000 at 11:43:28PM -0400, Kevin Atkinson wrote: On Thu, 18 May 2000, Ossama Othman wrote: Sure. I don't know anything about libtool's internals but if you send me a patch I can try it out on several different platforms including Digital UNIX which currently doesn't have C++ support. I'll try to put one together soon, when I have some spare time. Donations are always welcome. :-) Well if you point me in the right direction I may just give you one I'll review the libtool code again to see where and how the static library problem can be fixed. Hopefully, I'll have some time to back into this stuff this weekend. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
