Re: exclusive static or shared
Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:10:20PM CET: 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? Yes, there are some thoughts: First, don't let shared libraries have static libraries as dependencies. It's a pain, there are many systems where this will not work as desired, and making sure you never end up with duplicate symbols and/or arising subtle bugs is not easy. Text relocations cost shareability and lots of memory on some systems, and if they cause a sufficient speedup, it usually means your interface design is broken. Surely I acknowledge that on _some_ systems things may be differently, but Libtool is about portable library creation. And after all, it is possible to achieve this now by the workaround of creating several instances of a library (don't bother us with bug reports then, though; I won't read them). On systems without pass_all, libtool will not actually _include_ the static library into the shared one, though, but record the dependency in the .la file so that it can be fulfilled when a program is created. Second, there was recently a longish thread about per-deplib static/ shared flags for creating programs, including patches. Likely, soon after 2.0 is released some progress on that issue can be expected. ;-) Third, there is a pending patch implementing `-static-libtool-libs', to be applied before 2.0 hopefully. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
Hi Christopher,
* Christopher Hulbert wrote on Fri, Feb 17, 2006 at 08:21:07PM CET:
I normally do not create shared libraries. The ONE place I do though
is with Matlab MEX functions which are nothing more than a shared
library with the mexFunction as an exported function. I link my
Matlab code against static libraries that contain my real functions
(The matlab interface serves exactly that an interface from matlab to
my C/fortran backend).
So do you compile your static library code with -fPIC? Because if not,
then..
Although it's not advised it works on 3 main
platforms that we use matlab on x86,x86_64,and win32.
.. it will fail on x86_64 (for nontrivial code):
echo 'int x = 0; int a() { return x; }' a.c
gcc -c a.c
ar cru liba.a a.o
echo 'extern int a(); int b() { return a(); }' b.c
gcc -fPIC -c b.c
gcc -shared -o libb.so b.o -L. -la
| /usr/bin/ld: ./liba.a(a.o): relocation R_X86_64_PC32 against `x' can not be
used when making a shared object; recompile with -fPIC
| /usr/bin/ld: final link failed: Bad value
If you _do_ build the static library with -fPIC: just consider using a
libtool convenience archive instead of a library. See the docs for the
differences.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
I normally do not create shared libraries. The ONE place I do though is with Matlab MEX functions which are nothing more than a shared library with the mexFunction as an exported function. I link my Matlab code against static libraries that contain my real functions (The matlab interface serves exactly that an interface from matlab to my C/fortran backend). Although it's not advised it works on 3 main platforms that we use matlab on x86,x86_64,and win32. The comment/suggestion was not a necessity, but would facilitate my option as a user/developer to build both shared and static libraries and be able to link the Matlab code against either (without separate builds). It's really no big deal though. Maybe this little spiel will give you an idea of where I start doing wacky things with libtool :)! On 2/17/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:10:20PM CET: 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? Yes, there are some thoughts: First, don't let shared libraries have static libraries as dependencies. It's a pain, there are many systems where this will not work as desired, and making sure you never end up with duplicate symbols and/or arising subtle bugs is not easy. Text relocations cost shareability and lots of memory on some systems, and if they cause a sufficient speedup, it usually means your interface design is broken. Surely I acknowledge that on _some_ systems things may be differently, but Libtool is about portable library creation. And after all, it is possible to achieve this now by the workaround of creating several instances of a library (don't bother us with bug reports then, though; I won't read them). On systems without pass_all, libtool will not actually _include_ the static library into the shared one, though, but record the dependency in the .la file so that it can be fulfilled when a program is created. Second, there was recently a longish thread about per-deplib static/ shared flags for creating programs, including patches. Likely, soon after 2.0 is released some progress on that issue can be expected. ;-) Third, there is a pending patch implementing `-static-libtool-libs', to be applied before 2.0 hopefully. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
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: 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
