Re: --with-sysroot conflicts in binutils and gcc
> I have renamed the libtool --with-sysroot to --with-libtool-sysroot > for experments to avoid the conflict > and it worked well for me. > > See the patch here. > > http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/rename-with-sysroot.patch > > I guess thats not best Good for experiments though. Have you also tried adding --with-libtool-sysroot=$with_build_sysroot to target_configure_args in GCC's toplevel configure script, so that target libraries are built with libtool's sysroot support? Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: --with-sysroot conflicts in binutils and gcc
On 10/23/2010 10:01 AM, Ralf Wildenhues wrote:
Hi Paolo,
* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 09:38:43AM CEST:
Also, libtool should probably ignore --with-sysroot if build==host;
native compilers are never build with a sysroot in practice.
OK, so this would mean there is no way --with-sysroot could be (ab)used
to fix the DESTDIR (re)link failures that libtool users experience
today. Desired side-effect?
No, do you have a pointer? I don't understand what failure is there
that cannot be fixed by --enable-fast-install (so that relink doesn't
happen at install time), no?
The rest of your proposed patch could also be wrapped in
gcc/configure.ac, I'm not sure whether it belongs there rather than in
Libtool?
I don't recall if binutils needs to know about a sysroot.
Another solution is to do the following renaming in GCC
--with-sysroot -> --enable-sysroot
--with-build-sysroot -> --with-target-sysroot
(not existing) -> --with-host-sysroot
The task of mapping from old to new arguments is given to the toplevel
configure script; subdirectories _never_ see a $with_sysroot with a
meaning other than the one Libtool uses. To do this, the toplevel
configure simply has to mangle the {host,build,target}_configure_args to
include the correct args:
--without-sysroot for build_configure_args
--with-sysroot=${with_host_sysroot:-no}
--enable-sysroot=${with_sysroot:-${enable_sysroot:-no}}
for host_configure_args
--with-sysroot=${with_target_sysroot:-${with_build_sysroot:-no}}
for target_configure_args.
The patch should be relatively small, so OE can backport it to 4.5 if
they wish. Adjusting the docs and selling the idea on gcc@ is probably
harder than writing it.
Paolo
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: --with-sysroot conflicts in binutils and gcc
On 10/21/2010 10:23 PM, Khem Raj wrote:
> toolchain has two options when it comes to sysroot --with-sysroot and
> --with-build-sysroot I think libtool should
> also differentiate between two and set both to same if not explicitly
> set during configure time. I think libtool
> means to use build time sysroot and not runtime sysroot its just that
> configure options are colliding
Yes, for target modules the GCC toplevel should pass
--with-sysroot=$with_build_sysroot, or libtool should learn
about --with-build-sysroot.
Also, libtool should probably ignore --with-sysroot if build==host;
native compilers are never build with a sysroot in practice. This however
would still conflict with GCC when cross-building a native compiler, or
for a sysrooted Canadian cross. The attached patch could be made to work
in this scenario if you can afford using --without-build-sysroot.
Another possibility is to have an environment variable which would
override the command-line options (ick). Then the GCC toplevel can
set it as they wish.
Paolo
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 967dd38..3b7ff61 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1183,19 +1183,21 @@ AC_DEFUN([_LT_WITH_SYSROOT],
AC_ARG_WITH([sysroot],
[ --with-sysroot[=DIR] Search for dependent libraries within DIR
(or the compiler's sysroot if not specified).],
-[], [with_sysroot=no])
+[], [with_sysroot=${with_build_sysroot}])
dnl lt_sysroot will always be passed unquoted. We quote it here
dnl in case the user passed a directory name.
lt_sysroot=
case ${with_sysroot} in #(
yes)
- if test "$GCC" = yes; then
+ if test "$GCC" = yes && test "$build" != "$host"; then
lt_sysroot=`$CC --print-sysroot 2>/dev/null`
fi
;; #(
/*)
- lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
+ if test "$build" != "$host"; then
+ lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
+ fi
;; #(
no|'')
;; #(
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
> package1: ./configure > package1: make install DESTDIR=/tmp/root1 > > package2: ./configure > package2: make install DESTDIR=/tmp/root2 > > 1. No need to update existing builds, adding --with-sysroot to all > configure statements is harder. Hardly impossible though. > 2. You can assume DESTDIR is base root (own sysroot), and while > linking and all take the SYSROOT environment as base. So I don't > really understand the '=' in the .la files. You can always add the > SYSROOT prefix to everything in .la if it resides within the SYSROOT. You can always have errors in the build processes where some dependencies lie outside the sysroot, so being able to distinguish the sysrooted paths is a good thing. One additional functionality could be to spot non-sysrooted paths at --mode=finish time, and diagnose those. Also, the "=" comes from GCC's syntax, it's not libtool's invention, and reusing it meant that the sysroot support was much less painful to add than it seemed. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
On 09/27/2010 03:41 PM, Alon Bar-Lev wrote: Thanks for the explanation! On Sun, Sep 26, 2010 at 7:17 AM, Ralf Wildenhues wrote: Also, why not take the value of the sysroot from the DESTDIR automake variable? Because we know DESTDIR far too late, only at 'make install' time and not yet at the time we link against dependent libraries (that may already be installed below the sysroot). But you do relink the libraries when 'make install' is executed. So why not relink it with proper sysroot? Because if you removed sysroot syntax upon "make install", you would not be able to link future code with the newly-installed library. Note that it's perfectly possible to use .la files on the final system that didn't go through "libtool --mode=finish", as long as all the packages you compile are upgraded to Libtool 2.4 (and IIUC, cygwin's packaging system for example is already re-libtoolizing each package, so it's not that hard to do this). Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: pr-msvc-support merge
On 06/09/2010 04:46 PM, Gary V. Vaughan wrote: Why so much cruft in ltmain.m4sh just to drive a different archiver? It seems to me that this would be better and easier to maintain, test and extend as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the script instead of /usr/bin/ar when the system is funky. What about embedded libtool, which is really the common case? Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10
On 12/14/2009 07:25 PM, Adam Mercer wrote: cd /us On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini wrote: I only have this problem with Ubuntu 9.10, does anyone know what could be causing this? What is the output of autoreconf --version? It reports itself as 2.64 Can you attach your /usr/bin/autoreconf so that we can look for Canonical patches? Attached, the source package is available from the following location: <http://packages.ubuntu.com/source/karmic/autoconf> It's an Ubuntu-specific (maybe Debian-specific) patch. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10
I only have this problem with Ubuntu 9.10, does anyone know what could be causing this? What is the output of autoreconf --version? Can you attach your /usr/bin/autoreconf so that we can look for Canonical patches? Thanks! Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dlopening the C runtime library
Right. dlsym(RTLD_NEXT, "open") will give you the one that you shadowed;
this might not be the real symbol yet as there may be other wrappers
loaded, and it might not be the one from libc as applications are
allowed to provide their own definitions of symbols and have them take
precedence.
That looks like what I'm looking for. I don't seem to find an analogous
flag for lt_dlsym, in libtool's documentation, so I'll go with native
dlsym, then.
RTLD_NEXT seems like a better choice, but just in case I am using the
following Autoconf stuff:
m4/libc-so-name.m4:
dnl Sets the variables LIBC_SO_NAME and LIBC_SO_DIR to the directory
dnl and basename for the C library.
AC_DEFUN([GST_LIBC_SO_NAME],
[AC_CACHE_CHECK([how to dlopen the C library], gst_cv_libc_so_name, [
if test $GCC = yes; then
gst_lib_path=`$CC --print-multi-os-directory $CFLAGS $CPPFLAGS`
case $gst_lib_path in
.) gst_lib_path= ;;
*) gst_lib_path=$gst_lib_path/ ;;
esac
else
gst_lib_path=
fi
case $gst_lib_path in
/*) gst_libc_search_path="${gst_lib_path}libc.so*
${gst_lib_path}libc-*.so
${gst_lib_path}libc.sl
${gst_lib_path}libSystem.dylib" ;;
*) gst_libc_search_path="/shlib/libc.so \
/lib/${gst_lib_path}libc.so* \
/usr/lib/${gst_lib_path}libc.so.* \
/usr/lib/${gst_lib_path}libc.sl \
/lib/${gst_lib_path}libc-*.so \
/System/Library/Frameworks/System.framework/System \
/usr/lib/libSystem.dylib"
esac
gst_lib_sysroot=`$CC --print-sysroot`
for i in $gst_libc_search_path; do
if test -f "$gst_lib_sysroot$i"; then
oldwd=`pwd`
gst_cv_libc_so_name=`basename $i`
gst_cv_libc_so_dir=`dirname $i`
cd "$gst_cv_libc_so_dir" && gst_cv_libc_so_dir=`pwd`
cd $oldwd
break
fi
done])
LIBC_SO_NAME=$gst_cv_libc_so_name
LIBC_SO_DIR=$gst_cv_libc_so_dir
AC_SUBST(LIBC_SO_NAME)
AC_SUBST(LIBC_SO_DIR)
])
libc.la.in:
# libc.la - a libtool library file
# Generated by GNU libtool
# Created for GNU Smalltalk's dynamic loading mechanism.
# The name that we can dlopen(3).
dlname='@LIBC_SO_NAME@'
# Names of this library.
library_names='@LIBC_SO_NAME@'
# Libraries that this one depends upon.
dependency_libs=''
# Is this an already installed library?
installed=yes
# Directory that this library needs to be installed in:
libdir='@LIBC_SO_DIR@'
in configure.ac:
GST_LIBC_SO_NAME
AC_CONFIG_FILES([libc.la])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
On 12/03/2009 08:20 AM, Ralf Wildenhues wrote: We should probably change the code so that the override can be done before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, and that the compile test uses the right flag. Using a "real" cache variable will do. I'll give it a shot. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Incorrect dependency on GLIBC_PRIVATE symbol, who to blame?
On 10/11/2009 11:41 AM, Kent Boortz wrote: (F) The linker, it should know about GLIBC_PRIVATE, and search for non private occurrences first, then if not found do another scan for private ones? No, GLIBC_PRIVATE is not very different from ABC_XYZ from the linker's point-of-view. :-) > (A) Red Hat, the "/usr/lib/libunwind.la" should not have ' -lc -lgcc' > as a dependency, those are implicit and should never be in a > ".la", except maybe when building the compiler/linker itself? Maybe. Does hacking the libunwind.la fix it? > (C) Intel, SuSE has the exact same content of "libunwind.la", but > 'postdeps' contains a "-lm" before "-lc", so should icc/icpc "-v" > on Red Hat? You accidentally a part of the sentence, but anyway I do not think sprinkling -lm's is the right solution. > (G) Linux system devs, for defining that symbols twice? That's very tricky indeed, but I think that part is fine as long as -lc is never given on the command line. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Multipurpose binaries with different names
On 07/24/2009 11:25 AM, Jan Engelhardt wrote:
Hi,
when one has a program that does something like
if(strcmp(argv[0], "gunzip") == 0)
uncompress();
else
compress();
and this program also uses a libtool library, then the - lets use this
example - just-built "gzip" file will be around 4 kilobytes only, it is
a libtool wrapper scripts for .libs/gzip. "gunzip" would then be a
symlink to "gzip", but calling gunzip results in the libtool script
calling gzip instead, thereby leading to the wrong mode of operation.
This makes it hard to run libtooled programs from within the compilation
directory. A possible workaround is that the libtool wrapper script
honors $0 a little more:
Since anyway you have to use install-programs-hook to create the
multipurpose binary, you can add another name (e.g. gztool) and invoke
it like "gztool gzip" or "gztool gunzip" while uninstalled:
#ifdef _WIN32
executable_name = strrchr (argv[0], '\\');
if (!executable_name || strchr (executable_name, '/'))
executable_name = strrchr (argv[0], '/');
#else
executable_name = strrchr (argv[0], '/');
#endif /* _WIN32 */
if (executable_name)
executable_name++;
else
executable_name = argv[0];
if (!strcasecmp (executable_name, "gztool" EXEEXT)
|| (EXEEXT[0] && !strcasecmp (executable_name, "gztool")
|| !strcasecmp (executable_name, "lt-gztool" EXEEXT)
|| (EXEEXT[0] && !strcasecmp (executable_name, "lt-gztool")))
{
program_name = strdup (argv[1]);
argv++, argc--;
}
else
{
int n = strlen (executable_name);
program_name = strdup (executable_name);
/* Strip the executable extension if needed. */
if (EXEEXT[0]
&& n > strlen (EXEEXT)
&& !strcasecmp (program_name + n - strlen (EXEEXT), EXEEXT))
program_name[n - strlen (EXEEXT)] = 0;
}
if (strcmp (program_name, "gzip"))
exit (compress ());
else
exit (uncompress ());
Make gztool noinst_PROGRAMS and you're done.
Paolo
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Detecting that AC_PROG_LIBTOOL has been invoked
m4_define([m4_provided], [ m4_provide_if([AC_PROG_LIBTOOL], [], [ m4_provide_if([LT_INIT], [], [m4_warn([syntax], [Libtool required by $1])])])])]) ... m4_provided([MY_MACRO_NAME]) I didn't count the number of closing brackets. What is the m4_provide_if? I didn't find it in the manual of autoconf and m4. It's in m4sugar. Anyways, does this guarantee me that the user did INVOKE the give macros, not merely that they exist? Yes. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Detecting that AC_PROG_LIBTOOL has been invoked
The reason why I'm asking this is that I wrote some macros that rely on Libtool's magic handling of -R and even though it's clearly stated in the doc/comments/README that Libtool is mandatory, people keep running in troubles because they didn't use Libtool, so I'd like to trigger an error, somehow, to tell them that they did something wrong. You can use m4_provide_if like this: m4_define([m4_provided], [ m4_provide_if([AC_PROG_LIBTOOL], [], [ m4_provide_if([LT_INIT], [], [m4_warn([syntax], [Libtool required by $1])])])])]) ... m4_provided([MY_MACRO_NAME]) I didn't count the number of closing brackets. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Opening libraries by soname
In debian, libncurses.so is not installed unless libncurses-dev is also installed. Therefore, programs should open libncurses.so.5 directly. No. Ideally the installation script for your program would create a symlink from a private directory for your program to the libncurses that your program should open, which would probably point to the SONAME symlink. Good idea. How do I find the SONAME symlink portably, though? One possibility could be to require the -dev package when building, create a program that links against -lncurses, and use ldd or equivalents to find the SONAME -- but again, ldd is not portable... Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Opening libraries by soname
The only way I see that happen in a sane way is to have all three libtool version numbers passed to a new lt_dlopenadvise API (CVS HEAD) and have libltdl compute the soversion from there. Yes, that's a good idea for the interface. But the implementation is no less of a mess. First, as you pointed out, it is heavily dependent on the OS. The libtool scripts already knows all the special cases, they should be rewritten in C; but a small problem is that for some OSes the AGE is not encoded in the soname and the user of the API should know it and pass it (so that CURRENT - AGE is used instead of CURRENT, etc.). The number of system calls is not a problem to be easily fixed. People will not want to give a specific soname. They will want to give CURRENT value and possibly a REVISION value (defaulting to 0); then any library will be ok with A.B.C satisfying "A = CURRENT and C >= REVISION" or "A < CURRENT <= A + B". On some OSes we can make educated guesses (especially if the AGE is passed), but on others (actually on all, in the worst case) one needs to read all of /usr/lib. Finally, there can be only one .la file for each copy of the library, right? On which OSes is it a problem to load dependent libraries separately? Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Opening libraries by soname
In debian, libncurses.so is not installed unless libncurses-dev is also
installed. Therefore, programs should open libncurses.so.5 directly.
However, this is not possible with ltdl_openext. Would a patch be
accepted to extend ltdl_openext("libncurses.5") like this:
- of course, opening "libncurses.5" tries to open libncurses.5.so and
libncurses.5.la first
- on some systems it might succeed, as on Darwin. on other it will
fail, but it will recognize the soversion suffix and try to open
libncurses.so.5.
- failing to do so, it will try libncurses.la and check the current/age
items to detect if the library supports that soversion.
Paolo
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: func_infer_tag() broken
At a slight tangent; maybe m4sh could provide a shell function calling macro (off the top of my head): Isn't this a bit heavyweight? | It should be even with an integer return value. If you are at the | end of a function (or in an if just before the end of the function, you | got it) it is possible to replace it with (exit NUM), but I don't see a | good reason to do so. Doesn't the exit actually terminate the script for (at least) some shells? No, it is in a subshell. Anyway it is among the shell function features that m4sh now explicitly tests. It will complain at the start of the script (telling to write to [EMAIL PROTECTED] even if shell functions are not used, and also bailing out if they are). BTW, we're thinking of moving the generation of ltmain.sh to m4sh when the shell function support in autoconf pans out... It is already there. There is the detection system outlined above; plus, a single macro is provided, AS_REQUIRE_SHELL_FN, which outputs the function into the initialization section of the script. That's basically all you need. Feel free to mail for help. Paolo ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: avoiding C++, Fortran tags
I am using the attached macro as a backport of AC_LIBTOOL_TAGS to
libtool 1.5.
Paolo
# backported from libtool 1.6 by Paolo Bonzini
# When AC_LIBTOOL_TAGS is used, I redefine _LT_AC_TAGCONFIG
# to be more similar to the libtool 1.6 implementation, which
# uses an m4 loop and m4 case instead of a shell loop. This
# way the CXX/GCJ/F77/RC tests are not always expanded.
# AC_LIBTOOL_TAGS
# ---
# tags to enable
AC_DEFUN([AC_LIBTOOL_TAGS],
[m4_define([_LT_TAGS],[$1])
m4_define([_LT_AC_TAGCONFIG], [
if test -f "$ltmain"; then
if test ! -f "${ofile}"; then
AC_MSG_WARN([output file `$ofile' does not exist])
fi
if test -z "$LTCC"; then
eval "`$SHELL ${ofile} --config | grep '^LTCC='`"
if test -z "$LTCC"; then
AC_MSG_WARN([output file `$ofile' does not look like a libtool script])
else
AC_MSG_WARN([using `LTCC=$LTCC', extracted from `$ofile'])
fi
fi
AC_FOREACH([_LT_TAG], _LT_TAGS,
[m4_case(_LT_TAG,
[CXX], [
if test -n "$CXX" && test "X$CXX" != "Xno"; then
AC_LIBTOOL_LANG_CXX_CONFIG
available_tags="$available_tags _LT_TAG"
fi],
[F77], [
if test -n "$F77" && test "X$F77" != "Xno"; then
AC_LIBTOOL_LANG_F77_CONFIG
available_tags="$available_tags _LT_TAG"
fi],
[GCJ], [
if test -n "$GCJ" && test "X$GCJ" != "Xno"; then
AC_LIBTOOL_LANG_GCJ_CONFIG
available_tags="$available_tags _LT_TAG"
fi],
[RC], [
if test -n "$RC" && test "X$RC" != "Xno"; then
AC_LIBTOOL_LANG_RC_CONFIG
available_tags="$available_tags _LT_TAG"
fi],
[m4_errprintn(m4_location[: error: invalid tag name: ]"_LT_TAG")
m4_exit(1)])
])
fi
])dnl _LT_AC_TAG_CONFIG
])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Defines dependent on static/dynamic build
> I seem to recall that libtool used to define something when compiling > a shared library, but that this support was removed. Presumably this > was because there was some other way to accomplish the same thing. > > Does anyone know of a way to get libtool to behave the way I need? You may add somewhere #ifdef PIC #define __DYNAMIC__ #else #define __STATIC__ #endif Not really foolproof though, cos there may be interactions on platforms which always use position-independent code and thus have no reason to #define PIC. Better to do pic_flag="$pic_flag -D__DYNAMIC__" and then add somewhere #ifndef __DYNAMIC__ #define __STATIC__ #endif Paolo ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 tag woes
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
> Does this help? > AC_LIBTOOL_TAGS([]) That's only in CVS (actually, I checked and it is not in 1.5, so it must be in CVS). I don't see it that bad that C is not a proper tag, actually. It would also be good if enable_shared and enable_static became proper tag variables instead of globals. BTW, the October patch for -shared and -static handling (which I just noted) is a complete duplicate of the special tags disable-shared and disable-static. It should be reverted IMO, it is just featurism. When *I* proposed such a change (with no attached patch, granted :-) I was told to use the multi-language branch instead. Paolo ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.5 tag woes
I have just upgraded to libtool 1.5 (Debian's package which is taken out of CVS) and here are my first experiences. I'd like to make a custom tag so that, for a particular libtool library, PIC code is also compiled with -fomit-frame-pointer (I really need the register that is lost by the GOT code), and that shared libraries are disabled unless GCC 3.3 or later is found (I also need the visibility attribute to regain speed accessing global variables). However, I have had serious problems trying to do this, because there is a complete dearth of docs about tags. So far, my only solution has been to write an Autoconf macro that wraps AC_LIBTOOL_CONFIG with a customizable preamble: this way, I can put the code to do my custom changes in the preamble and invoke _LT_AC_LANG_C_CONFIG to create the tag. An alternative, however, would be to just duplicate the contents of the default tag into my custom tag, then make the modifications, and then invoke the standard AC_LIBTOOL_CONFIG. This however has upward-compatibility problems in case another configuration variable is added to the tags; is there a way to copy tags in an upward-compatible way? Finally, I am quite disgruntled by the 250kb of shell code that is included in every project even if the CXX/GCJ/F77/RC tags are never used; my solution has been to redefine AC_LIBTOOL_CXX_CONFIG and friends to a colon, but this is quite of a hack. Again I ask if there is a nicer way to strip down my already huge (750kb) configure script. WRT the docs, I'd like to understand what part of the tag API is considered public. With this information, I may even write down something about it... Paolo ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
