[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool 1.5 tag woes (static/shared)

From: Sander Niemeijer
Subject: Re: libtool 1.5 tag woes (static/shared)
Date: Mon, 17 Nov 2003 13:58:00 +0100

Hi Paulo,

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:

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.


Libtool mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]