[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building static-only or shared-only libraries on a per target basis
From: |
Sander Niemeijer |
Subject: |
Re: Building static-only or shared-only libraries on a per target basis |
Date: |
Tue, 5 Aug 2003 10:31:32 +0200 |
Hi,
Maybe I can clarify the reasons behind this patch a bit more, and also
hopefully give an answer to your question.
Usually within a package you can have three situations for a library.
1) Only a static version is meaningful
In case you also have libraries of type 3) in your package, you do not
want libtool to create a shared version of this library too. So for
these libraries the -static option should be useful. Even if libtool
was configured with --disable-static, libraries of type 1) will still
be build. This behavior is already the case in the current version of
libtool (although currently providing a -static option for the
compilation mode also provides shared objects, which are completely
useless if you also use the -static link mode option. Ralph's patch
also fixes that issue).
2) Only a shared version is meaningful
This is the case (as I explained in my previous posts) when you need to
build a module for an existing commercial application (that does not
make use of ltdl functionality so static versions are indeed not
useful). If you also have type 3) libraries in your package you do not
want to have a static version build of this library. With the patch
this is made possible by providing a -shared compile/link mode option.
There is however a catch when your platform does not have shared
library functionality (which actually means that the library of type 2)
isn't meaningful for your platform anyway and should be disabled
completely using conditionals in your makefile and some self provided
configure option). So with Ralph's patch if you try to build a library
with -shared and your platform does not support shared libraries or the
user configured libtool with --disable-shared you will get a fatal
error.
3) Both static and shared versions are meaningful
This is the most common case for libtool libraries. For these types of
libraries you can globally set (with the
--[enable/disable]-[shared/static] options) whether you want either the
static version, the shared version, or both.
To come back to your question. Your library is of type 3). And as Ralph
explained, if you want to have both a static version and a shared
version you shouldn't provide a -static or -shared compile or link mode
option and you should make sure that both enable_shared and
enable_static are set to 'yes'.
If you still think that this patch would inhibit any functionality you
want, please provide an example case where you might see problems.
Regards,
Sander
On maandag, aug 4, 2003, at 21:33 Europe/Amsterdam, Earnie Boyd wrote:
Ralph Schleicher wrote:
Earnie Boyd <address@hidden> writes:
But what if I want both?
Do nothing special, its the default libtool behavior.
If you want to ensure that both kinds of libraries are
built for a package, check for enable_shared=yes and
enable_static=yes at configure time.
My question was relative to the offered patch.
Earnie.
_______________________________________________
Libtool mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool