Re: exclusive static or shared
Hi Christopher, * Christopher Hulbert wrote on Tue, Feb 14, 2006 at 11:08:28PM CET: > I have a number of directories most of which I ONLY want to build > shared libraries from. There are a couple that I ONLY want static > libraries. Is there a way to turn on/off shared/static libraries. I > saw -static which would work IF both build_old_libs=yes. Is there any > way to have -static set build_old_libs=yes? This is on cygwin with > libtool 1.5.22. Is there a -shared equivelent to disable static and > enable shared library building? Here's a set of rules. The developer can set preferences on a per-(sub)package basis by using AC_ENABLE_SHARED AC_DISABLE_SHARED AC_ENABLE_STATIC AC_DISABLE_STATIC in the respective configure.ac files. The user can do so per-(sub)package with --enable-shared=pkgs --disable-shared=pkgs --enable-static=pkgs --disable-static=pkgs and override above macros thusly. Assuming a package that uses Automake, the developer can control this on a per-library basis by putting -static into the *LDFLAGS that affect libtool-created libraries. The user can override this (usually on a per-make invocation basis) by using the flag in LDFLAGS, but has to make sure only libtool-created libraries (and not any other linked targets) are affected. The developer or the user can possibly limit the types of libraries created by using the --tag=disable-shared --tag=disable-static tags for libtool. To use these correctly, there are a few things to be noted though: - Shared libraries may not have been disabled at configure time. - These tags work with both 1.5.x and CVS libtool versions, but are not (yet) documented. - These flags need to go before the compiler: speaking in Automake terms, they would fit in LIBTOOLFLAGS but not in LDFLAGS. - We took liberty to change (fix) their semantics in 1.5.22 to this: If you pass --tag=disable-shared --tag=CXX then previously, the CXX configuration could overwrite the disabling of shared libraries. Now that does not happen any more. The new behavior (in branch-1-5 and HEAD) gives the disable-* tags precedence over the language tags. - Until we document the tags, we'll probably take liberty to change them again if we encounter more issues that we don't like. With all of the aforementioned measures, one has to take the following additional rule into account: Libtool will never disable all types of libraries. That means, it will usually fall back to static libraries because it is usually possible to create them everywhere. It is furthermore important to note that there are systems where libtool will not build static libraries by default (AIX without runtimelinking) or not build shared libraries at all. Hope that helps (and gives enough flexibility). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool (alpha)
Hi Julien,
* Julien Lecomte wrote on Wed, Feb 15, 2006 at 04:51:54AM CET:
>
> I've installed the libtool alpha cvs build under MinGW.
> Configuration and install was made under mSys (after replacing
> config.{guess,sub}):
>
> ../alpha/configure --prefix=/usr
> make
>
> Of note: I configured and installed under mSys because under MinGW it
> fails (undefined reference to `lt_libltdl_LTX_preloaded_symbols')
Weird. I haven't tested MinGW a while, but last time it worked fine.
Need to look into this. I have never tested MSYS, though.
> When I run a `libtool --help', I get :
> host-triplet: powerpc-apple-darwin8.2.0
*snip*
> How come the host-triplet is detected as *Darwin* ???
> If I run `./config.sub `./config.guess`' in the 'libltdl/config'
> directory, I get the normal 'i686-pc-msys' or 'i686-pc-mingw32'.
> I also get the expected normal response in the ./configure output.
Thanks for the bug report! I'm installing this patch to fix this.
Cheers,
Ralf
* libltdl/config/getopt.m4sh (func_help): Substitute `$host'.
* libltdl/config/ltmain.m4sh (help message): Use $host not
@host_triplet@, as the [EMAIL PROTECTED]@' substitution is done at
bootstrap
time already.
Reported by Julien Lecomte <[EMAIL PROTECTED]>.
Index: libltdl/config/getopt.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/getopt.m4sh,v
retrieving revision 1.4
diff -u -r1.4 getopt.m4sh
--- libltdl/config/getopt.m4sh 23 Jan 2006 18:33:57 - 1.4
+++ libltdl/config/getopt.m4sh 15 Feb 2006 07:28:34 -
@@ -63,6 +63,7 @@
s/^# //
s/^# *$//
s*\$progname*'$progname'*
+ s*\$host*'"$host"'*
s*\$SHELL*'"$SHELL"'*
s*\$LTCC*'"$LTCC"'*
s*\$LTCFLAGS*'"$LTCFLAGS"'*
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.37
diff -u -r1.37 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 13 Feb 2006 17:02:28 - 1.37
+++ libltdl/config/ltmain.m4sh 15 Feb 2006 07:28:34 -
@@ -60,7 +60,7 @@
# When reporting a bug, please describe a test case to reproduce it and
# include the following information:
#
-# host-triplet: @host_triplet@
+# host-triplet: $host
# shell: $SHELL
# compiler: $LTCC
# compiler flags:$LTCFLAGS
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hi Christopher, > > * Christopher Hulbert wrote on Tue, Feb 14, 2006 at 11:08:28PM CET: > > I have a number of directories most of which I ONLY want to build > > shared libraries from. There are a couple that I ONLY want static > > libraries. Is there a way to turn on/off shared/static libraries. I > > saw -static which would work IF both build_old_libs=yes. Is there any > > way to have -static set build_old_libs=yes? This is on cygwin with > > libtool 1.5.22. Is there a -shared equivelent to disable static and > > enable shared library building? > > Here's a set of rules. > > The developer can set preferences on a per-(sub)package basis by using > AC_ENABLE_SHARED > AC_DISABLE_SHARED > AC_ENABLE_STATIC > AC_DISABLE_STATIC > in the respective configure.ac files. > > The user can do so per-(sub)package with > --enable-shared=pkgs > --disable-shared=pkgs > --enable-static=pkgs > --disable-static=pkgs > and override above macros thusly. I guess I didn't make it clear enough that ALL the subdirectories were under the same configure script and doesn't make logical sense to split them. > > Assuming a package that uses Automake, the developer can control this on > a per-library basis by putting > -static > into the *LDFLAGS that affect libtool-created libraries. The user can > override this (usually on a per-make invocation basis) by using the flag > in LDFLAGS, but has to make sure only libtool-created libraries (and not > any other linked targets) are affected. I had shared libraries enables and static disabled from configure. In passing -static to the 1 library I wanted to be static, it created the library, but without any object files in it. i.e. it was an empty library and thus resulted in missing symbols later. I found If I enabled static libraries at configure time The objects would be put in, but the 30 shared libraries I wanted all got useless static ones built which wasted time and space. > > The developer or the user can possibly limit the types of libraries > created by using the > --tag=disable-shared > --tag=disable-static > tags for libtool. To use these correctly, there are a few things to be > noted though: > - Shared libraries may not have been disabled at configure time. > - These tags work with both 1.5.x and CVS libtool versions, but > are not (yet) documented. > - These flags need to go before the compiler: speaking in Automake > terms, they would fit in LIBTOOLFLAGS but not in LDFLAGS. > - We took liberty to change (fix) their semantics in 1.5.22 to this: > If you pass > --tag=disable-shared --tag=CXX > then previously, the CXX configuration could overwrite the disabling > of shared libraries. Now that does not happen any more. > The new behavior (in branch-1-5 and HEAD) gives the disable-* tags > precedence over the language tags. > - Until we document the tags, we'll probably take liberty to change them > again if we encounter more issues that we don't like. The LIBTOOLFLAGS is the variable I was looking for! Of course tag's don't work in LDFLAGS because they come after the compiler (another shot at the problem I took). I will try setting LIBTOOLFLAGS later today. On a side note, I have started to dig into the libtool CVS internals and have created a patch for the PGI wl="" and -link -dll problem I was receiving. When I get to work I will test these and submit them to the libtool-patches list. Chris > > > With all of the aforementioned measures, one has to take the following > additional rule into account: > Libtool will never disable all types of libraries. That means, it will > usually fall back to static libraries because it is usually possible to > create them everywhere. > > It is furthermore important to note that there are systems where libtool > will not build static libraries by default (AIX without runtimelinking) > or not build shared libraries at all. > > Hope that helps (and gives enough flexibility). > > Cheers, > Ralf > ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 12:28:59PM CET: > On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > > Here's a set of rules. > > > I guess I didn't make it clear enough that ALL the subdirectories were > under the same configure script and doesn't make logical sense to > split them. Oh, you made that clear. You are not the only reader of this mailing list, though, and I thought it to be appropriate to give a general answer that is useful for more than one specific purpose. > > Assuming a package that uses Automake, the developer can control this on > > a per-library basis by putting > > -static > I had shared libraries enables and static disabled from configure. In > passing -static to the 1 library I wanted to be static, it created > the library, but without any object files in it. i.e. it was an empty > library and thus resulted in missing symbols later. Ahh! Now this may be a bug, I believe. I cannot reproduce this in a test, though. Can you show me how to reproduce it? Which Libtool version? How did you configure exactly? On what $host? config.log? > and have created a patch for the PGI wl="" and -link -dll problem I > was receiving. When I get to work I will test these and submit them > to the libtool-patches list. Well, some of the issues arise from the first MSVC patches: a couple of times there was the assumption that on win32, non-gcc compiler meant MSVC. You'd need to undo that. And then go and set the flags in _LT_COMPILER_PIC correctly (for both CXX and other tags). And then you can check all the other PORTME instances in libtool.m4 to see whether they need adaptation, too. ;-) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
* Christopher Hulbert wrote on Wed, Feb 15, 2006 at 12:28:59PM CET: > On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > --tag=disable-shared > > --tag=disable-static > > - These flags need to go before the compiler: speaking in Automake > > terms, they would fit in LIBTOOLFLAGS but not in LDFLAGS. > The LIBTOOLFLAGS is the variable I was looking for! Of course tag's > don't work in LDFLAGS because they come after the compiler (another > shot at the problem I took). I will try setting LIBTOOLFLAGS later > today. Of course, as developer, you should be using AM_LIBTOOLFLAGS instead of LIBTOOLFLAGS; the latter is again reserved for the user. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hi Christopher, > > * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 12:28:59PM CET: > > On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > > > > Here's a set of rules. > > > > > I guess I didn't make it clear enough that ALL the subdirectories were > > under the same configure script and doesn't make logical sense to > > split them. > > Oh, you made that clear. You are not the only reader of this mailing > list, though, and I thought it to be appropriate to give a general > answer that is useful for more than one specific purpose. > > > > Assuming a package that uses Automake, the developer can control this on > > > a per-library basis by putting > > > -static > > > I had shared libraries enables and static disabled from configure. In > > passing -static to the 1 library I wanted to be static, it created > > the library, but without any object files in it. i.e. it was an empty > > library and thus resulted in missing symbols later. > > Ahh! Now this may be a bug, I believe. I cannot reproduce this in a > test, though. Can you show me how to reproduce it? Which Libtool > version? How did you configure exactly? On what $host? config.log? Having a problem reproducing it now that I've installed the CVS libtool :(. > > > and have created a patch for the PGI wl="" and -link -dll problem I > > was receiving. When I get to work I will test these and submit them > > to the libtool-patches list. > > Well, some of the issues arise from the first MSVC patches: a couple of > times there was the assumption that on win32, non-gcc compiler meant > MSVC. You'd need to undo that. And then go and set the flags in > _LT_COMPILER_PIC correctly (for both CXX and other tags). And then you > can check all the other PORTME instances in libtool.m4 to see whether > they need adaptation, too. ;-) Working on the patch now, I'll send it here If I don't get a confimation email from libtool-patches before it's done. > > Cheers, > Ralf > ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
Ok, I sent the patch to libtool-patch. Another question I have wondered is as follows: Lets say I build library liba as both static and shared (thus I have liba.a and liba.so or liba.lib and liba.dll). I later want to build libb.so or libb.dll against the installed liba. From my observations it always takes the shared liba. Is this true, or is there a flag to tell it to use static libraries where available (similar to -i-static for intel compiler). I was thinking something like -libtool-static or -libtool-static=-la,-lxyz where the comma-separated list is a list of libraries this rule applies to. Any thoughts on the matter? On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > [ off-list ] > > Hi Christopher, > > * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 02:24:10PM CET: > > On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > > > > Well, some of the issues arise from the first MSVC patches: a couple of > > > times there was the assumption that on win32, non-gcc compiler meant > > > MSVC. You'd need to undo that. And then go and set the flags in > > > _LT_COMPILER_PIC correctly (for both CXX and other tags). And then you > > > can check all the other PORTME instances in libtool.m4 to see whether > > > they need adaptation, too. ;-) ___ 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
Re: Libtool -release and static libraries.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: > 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. Thanks for the response and suggestions. What you mentioned above is partly what I want to do yes, however having a symlink to libatcppunit.a would also be a good thing so "casual" users that only install a single version of the library do not have to use -latcppunit-1.0.6 I had thought about renaming the library as you mentioned above, but there are problems associated with doing that. In particular I have a version for the project specified in a single place in my configure.ac file. The idea is that if I need to change the version of the library, then I change this single value and the rest of the project updates when I do a bootstrap configure and make. The configure script exports the following two variables for use in automake that help with versioning: PACKAGE_VERSION 1.0.6 PACKAGE_VERSION_UNDERSCORE 1_0_6 However in the automake files I am unable to use these variables for substitution on the left side of the = sign. I.e: [EMAIL PROTECTED]@.la [EMAIL PROTECTED]@_la_CPPFLAGS=-I$(top_builddir)/src ... Fails to work. So this means I need to specify the values manually: lib_LTLIBRARIES=libatcppunit-1.0.6.la libatcppunit_1_0_6_la_CPPFLAGS=-I$(top_builddir)/src ... This defeats the purpose of having the version specified in a single place, and introduces the possibility of version mismatch between the version used for the install file names and the version numbers used in the compiled code. I was hoping that I could use the -release option to do this and was very surprised that the functionality was not consistent for both dynamic and static libraries. > > 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. > Is there any reason why changing this functionality in libtool would be a bad idea? I am not involved enough with libtool to see what re-percussions it could have. I can say that it would be the preferred option in my situation, however maybe not for everyone. It also seems to me as though modifying the name of both the static and dynamic libraries is how the -release flag is supposed to operate, I do not see why you would wish to rename one type of library and not the other. Anyhow, Thanks again for the reply. Brendon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9AwQPfREiUgoLqwRAltmAJ9ouuln0UCoj/S9ixAaYs1h6JmD4ACfdpFE S+kV1SjhjudainEiR6o3xyE= =BfnK -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
