[Top][All Lists]

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

Re: libtool 1.5 tag woes

From: Paolo Bonzini
Subject: Re: libtool 1.5 tag woes
Date: Mon, 17 Nov 2003 11:57:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2

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.


reply via email to

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