libtool option to build both static and shared?
Hello, I'd like to ask you to help with the following problem: A project contains sources for several libraries. Most of them should be built as shared libraries only, but one of them is to be built both as a shared library and as a static one. The user would like to use LT_INIT([disable-static]) and then override the *FLAGS in the subdirectory containing the library that needs to be available in both forms. He tried to use -static and -shared together, but it did not work. (This is the documented behaviour; though an error message from libtool might help to get this obvious.) Is there an option that would tell libtool to build both, even though it was configured with --disable-static? I invented a solution that should work: configure with --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all but libraries but that one. I could recommend this solution to the user, but I feel that the solution outlined above would be more comfortable. Thank you for any help, Stepan Kasal ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
On Thu, 12 Nov 2009, Stepan Kasal wrote: Is there an option that would tell libtool to build both, even though it was configured with --disable-static? I invented a solution that should work: configure with --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all but libraries but that one. I could recommend this solution to the user, but I feel that the solution outlined above would be more comfortable. This is the solution which currently does work, as long as the OS, tools, and libraries are capable of it. Note that using --disable-static is not portable so attempting to force only a shared build decreases portability. One place I have observed failures with --disable-static is under Microsoft Windows since the necessary DLLs are not always available. You may encounter similar issues on Unix system if there is dependence on an installed library which does not have a shared version available. 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: libtool option to build both static and shared?
Hello Bob, thank you for your answer. On Thu, Nov 12, 2009 at 10:50:03AM -0600, Bob Friesenhahn wrote: On Thu, 12 Nov 2009, Stepan Kasal wrote: Is there an option that would tell libtool to build both, even though it was configured with --disable-static? I invented a solution that should work: configure with --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all but libraries but that one. I could recommend this solution to the user, but I feel that the solution outlined above would be more comfortable. This is the solution which currently does work, as long as the OS, tools, and libraries are capable of it. Note that using --disable-static is not portable so attempting to force only a shared build decreases portability. [...] I understand that building shared library only is something that is not portable, because it is not possible. You may encounter similar issues on Unix system if there is dependence on an installed library which does not have a shared version available. This is a twofold example. When building a package for a GNU/Linux distribution, the --disable-static behaviour is always desirable. If a build of shared library fails, it is always necessary to fix the build environment so that dynamic linking is possible. It would be really evil if the build silently falled back to static linking. Anyway, back to the problem: Though the original reporter probably does not care, the solution should not compromise portability of the generated tarball. From that point of view, it is not desirable to set AM_CFLAGS=-shared in most subdirs of the project. It is better to override CFLAGS at build time. But the dreamed of solution would still be better, even from the portability angle: The library that needs to be built also as static one, say libfoo, would have: libfoo_la_CFLAGS = -static-and-shared With that, even if the project were configured as --disable-static, this one library would fall back to the previous default, which is to build both staic and shared if possible. Would it make sense to add this type of option to libtool? Or is it more consistent to keep things as they are and shoft the problem to the user, so that README would instruct him how to manipulate CFLAGS during the build? Actually is it wise to try to encode this static/shared combination into the tarball? Can it be understood as a property of the package (libfoo is a compatibility one, should be available as static lib on most platforms), or is it a platform specific issue, so that shifting the problem to the user of the tarball is the right thing to do? Happy hacking, Stepan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
Hi Stepan, * Stepan Kasal wrote on Thu, Nov 12, 2009 at 05:11:00PM CET: A project contains sources for several libraries. Most of them should be built as shared libraries only, but one of them is to be built both as a shared library and as a static one. The user would like to use LT_INIT([disable-static]) That won't work portably. If you disable one of the types here, then possibly some (system-dependent) configure tests may be omitted, which means you may run into trouble enabling the type later. This remark definitely holds for disable-shared. With disable-static I'm not sure without checking the sources, but it's prudent to assume the same. Instead, I'd suggest to just add --tag=disable-static to AM_LIBTOOLFLAGS or the per-target special (such as libfoo_la_LIBTOOLFLAGS). and then override the *FLAGS in the subdirectory containing the library that needs to be available in both forms. He tried to use -static and -shared together, but it did not work. (This is the documented behaviour; though an error message from libtool might help to get this obvious.) Is there an option that would tell libtool to build both, even though it was configured with --disable-static? Not portably; see above. I invented a solution that should work: configure with --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all but libraries but that one. I could recommend this solution to the user, but I feel that the solution outlined above would be more comfortable. Yeah, something like this seems necessary. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
On Thu, 12 Nov 2009, Stepan Kasal wrote: This is the solution which currently does work, as long as the OS, tools, and libraries are capable of it. Note that using --disable-static is not portable so attempting to force only a shared build decreases portability. [...] I understand that building shared library only is something that is not portable, because it is not possible. Sometimes it is due to limitations in the language run-time environment. For example, it has been a common problem that the C++ standard library provided with GCC is static under Windows due a problem with throwing exceptions across DLL boundaries. 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
