Re: libtool 1.5 tag woes

[Paolo Bonzini]

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

Re: libtool 1.5 tag woes (static/shared)

[Sander Niemeijer]

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.

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

quick changes question

[Patrick Welche]

I have yesterday's CVS autoconf, automake, apache httpd-2.0. Using

  ltmain.sh (GNU libtool) 1.5a (1.1296 2003/10/21 15:03:52)

apache's buildconf does its thing, and my only problem is undefined module
symbols in the final link, however

  ltmain.sh (GNU libtool) 1.5a (1.1331 2003/11/14 17:33:04)

gives me such errors as:

config.status: creating libtool
sed: /ltmain.sh: No such file or directory
mv: rename libtoolT to libtool: No such file or directory
cp: libtoolT: No such file or directory
chmod: libtool: No such file or directory

Can you think of something which has changed in the last 3 weeks that could
cause this? (It looks like top_builddir or something like that is no longer
set, but I am not changing autoconf, just libtool.. (supplementary question:
ac_top_builddir and top_builddir both seem to be defined - which one should
one use?))

Cheers,

Patrick


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool