It seems this thread starts to go into a direction that might change the recently added functionality of the -static and -shared flags. In a previous posting you opted for reverting the -static/-shared functionality and in the posting quoted below you are opting to make the disable-static/disable-shared tags obsolete.
IMHO I think we should keep both the -static/-shared functionality as well as the disable-static/disable-shared functionality. As I see it both features cater the needs of different types of users. The -static/-shared is more intended for the developer. The developer knows whether a static and/or a shared version of a certain library is at all useful within a package and can use these libtool flags to only create a static or shared version of a library. Mind that these flags are intended to be platform generic. This means that if you provide a -shared argument you are actually saying that creating a static version of the library wouldn't make sense for whichever platform you are building the library (this happens for instance if you are creating a library/module that will be used as plug-in for an already existing application that does not make use of libltdl).
The --disable-static/--disable-shared configure options on the other hand are intended to be used by the user who wants to install a package. The user may only be interested in either a static or a shared version of a library (but specifying such an option of course only makes sense for libraries that are build with neither a -static nor a -shared flag) and by providing these configure options the user will be able to specify this.
On Aug 3rd I have also made a posting about the rationale behind Ralph's -static/-shared patch:
<http://mail.gnu.org/archive/html/libtool/2003-08/msg00008.html>
Just my 2c.
Best regards, Sander Niemeijer
On maandag, nov 17, 2003, at 11:57 Europe/Amsterdam, Paolo Bonzini wrote:
Why make enable_shared and enable_static specific to a tag? Wouldn't it be odd that you create shared libs for "C" programs and static for "C++"? And, the --enable-shared and --enable-static options would have to multiply (--enable-c-shared, --enable-cxx-shared, etc).
I'm using tags for something different than multi-language operation. I want
to confine some configuration changes to a specific library: in particular,
I want a particular library to be compiled with -fomit-frame-pointer in an
x86 shared library (because it is a bytecode interpreter that is *a lot*
slower when a register is used for the GOT pointer), but not in the static
library (because it makes debugging harder). There is a precedent in the
disable-static and disable-shared tags (however, I think that these two
should be obsoleted now that there is -static and -shared, because they
are implemented differently than other tags).
See also my AC_LIBTOOL_TAG macro, recently posted in libtool-patches.
In this respect, documenting tag a bit more thoroughly may be a good thing. I will do it if AC_LIBTOOL_TAG is accepted -- otherwise, tags remain little more than an implementation detail and I'd rather use my time to document things for users, since I am mostly a user... :-)
>/ [AC_LIBTOOL_TAGS] is only in CVS/
I can send you a patch against 1.5 if you want.
I already did a backport AC_LIBTOOL_TAGS to 1.5; it is surely saner than
m4_define([AC_LIBTOOL_CXX_CONFIG], [:]) which is what I was using :-)
before. Thanks for your offer, though.
Paolo
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
