Re: GNU Libtool 2.1b released (alpha release)
Quoting Gary V. Vaughan [EMAIL PROTECTED]: With only one bug reported and fixed since Feb 1, either this is the most spectacularly well engineered release in the history of libtool, or else it is the least well tested release ever... For what it's worth, swfdec and swfdec-mozilla are fine with libtool CVS trunk. Even make distcheck passes. x86_64, Fedora 8 with all updates. No exotic unices, sorry. -- Regards, Pavel Roskin ___ http://lists.gnu.org/mailman/listinfo/libtool
pkg-config and versioning of static libraries
Hello! I've received a bugreport that GNU Midnight Commander cannot be compiled statically on Gentoo Linux. The fix is to replace -lglib-2.0 with -lglib in the command line. Midnight Commander doesn't use libtool, but glib 2.x does. glib also used pkg-config. Following command is used to request static linking: ./configure LDFLAGS=-Wl,-static The configure script blindly trusts the output of pkg-config. That's what pkg-config developers want us to do - the macro file pkg.m4 comes from pkg-config. To get the list of the libraries (in the form suitable for the compiler command line), following command is run: pkg-config --libs glib-2.0 The result is -lglib-2.0. pkg-config doesn't know that static linking was requested. There is no option for that. So the output is the same for shared and static libraries. For this to work, libglib-2.0.a should be available to the linker. It exists on Debian unstable and Fedora Core 1, but not on Gentoo. It may surprise you, but the existence of libglib-2.0.a appears to be a workaround for a libtool bug. glib by itself doesn't create versioned static libraries. And that behavior comes from libtool. I'm not talking about correct versioning with -version-info, but about hard versioning using the -release option. Let's compile CVS libtool with tests and run following in tests/demo: ./libtool --mode=link gcc -g -O2 -o libhello.la -rpath /usr/local/lib \ -no-undefined -release 5.6 hello.lo foo.lo -lm libhello-5.6.so is created in .libs, but libhello-5.6.a is not. Neither is it created during installation. The problem may be in pkg-config, but if so, I need very good arguments why libtool doesn't use versioning for static libraries. My question is - is the lack of versioning for static libraries a limitation of libtool or is a something that pkg-config should work around? I checked the archives and found that proposals to add versioning for static libraries were posted, but I could not find anything that would explain position of the libtool developers in this question. I don't want to add libtool support for GNU Midnight Commander just because it's linked against glib. If you think it's a good idea, I'd like to hear arguments. -- Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Hello, Russ! I'm the one who suggested the version 2.50 when it was discussed whether the next version should be 2.14, 2.15 or 3.0. The reason was because there was some incompatibility, but not significant to justify the major number change. It is possible to write configure.in compatible with 2.13 and 2.5x. Whether is was possible to write a 100% correct configure.in that would work with 2.5x before the 2.50 release is a big question, because the documentation was hard to understand. I think that it was possible, although some understanding of m4 was required in addition to the old Autoconf manual. Plus clean hands, of course, which means doing thing right, and not just adding quotes until it works. Two wrongs a right does not make. I.E.: I believe it wrong for any maintainter to not move forward with the current versions of autotools regardless of the maintainer's reasons for not doing so. That comes across as pretty arrogant. It may be arrogant, sure, but in the case of Autoconf it's indeed time to move forward. autoconf 2.5x was a disaster for some projects. That it was a disaster because autoconf 2.13 was woefully inadequate and therefore they had to do things they shouldn't have to do to accomplish what they needed to accomplish doesn't change the fact that autoconf 2.5x was a disaster and represents a vast amount of work that would have to be done. At least 75% of that is the work that should have been done before, i.e. underquoting. Many projects have other priorities, since after all autoconf 2.13 was working for them. The vast majority of packages using autoconf have not updated to autoconf 2.5x in my experience with compiling software. Mind you, Autoconf-generated scripts are meant to work not just for maintainers. They are meant to work for users. One hour spend by a developer is nothing compared to 1000 users downloading bash just to run that damned configure script and 1 users giving up. New versions of Autoconf are more portable. If libtool 1.4.3 is going to provide compatibility with MacOS (i.e. zsh, if I understand correctly), then it's absolutely reasonable to require the developer to spend some time and make sure that the configure script provides the same level of compatibility. -- Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Hello! People who stick to the 2.13 guns can stick to the libtool 1.3.3/whatever guns. I see no reason why *new* code (third-party packages) should require a *new* libtool but an *old* autoconf. And the argument that 2.13 works doesn't fly by me: so does 1.4.2 (or whatever the last libtool with near universal acceptance was). That's right unless somebody demonstrates otherwise. I don't think anyone should create themselves a future maintenance burden for the sake of packages that will respond simply by relying on that maintenance to continue, instead of getting with the 2.5x program. I must disagree here. If we say that laziness (a.k.a. conservatism) is not an excuse for the developers who use Autoconf and don't want to upgrade to 2.5x, then twice as much it's not an excuse for Autoconf developers, i.e. for a dozen of highly skilled programmers.. The legitimate reason to require the latest Autoconf is because it's good for the _end_ users. Another legitimate reason is because new tools are more often used together (rather than e.g. old Autoconf with new Libtool), and therefore they are better tested when used together. There may be technical reasons to require latest Autoconf as well, but they are secondary IMHO. I'll probably be flamed to hell and back now... Not in this list. -- Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [ 100058 ] 1.4 - $buildir-path may not contain ~
Hello, Bruce!
In the mean while, I think the only workaround is to not use '~' in pathnames.
Let's not hide the problems. Libtool it misusing IFS. Several macros in
libtool.m4 set IFS to whatever they want and then run a loop including
Autoconf macros assuming that the later can work with and IFS.
I'm sorry to disappoint you. Autoconf provides protection to the configure
script as a whole, but there is no protection for every single macro
against the code setting IFS in aclocal.m4 and configure.in.
By the way, _LT_AC_TAGCONFIG doesn't restore IFS at all! This causes
errors with Autoconf 2.50 that uses : instead of true. If : is in IFS,
it doesn't work.
Autoconf restores IFS inside the loop. Maybe it's not good for speed, but
it's good for reliability. ltmain.in already uses this trick.
This patch fixes the problem with Autoconf 2.50 and the problem with ~
in the directory names.
ChangeLog:
* libtool.m4: If IFS is set before loop restore it in the
beginning of the loop.
(_LT_AC_TAGCONFIG): Restore IFS at the end of the loop.
(_LT_AC_PROG_ECHO_BACKSLASH): s/save_ifs/ac_save_ifs/.
--- libtool.m4
+++ libtool.m4
@@ -297,8 +297,9 @@
#
# So, first we look for a working echo in the user's PATH.
- IFS=${IFS= }; save_ifs=$IFS; IFS=${IFS}${PATH_SEPARATOR}
+ IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}${PATH_SEPARATOR}
for dir in $PATH /usr/ucb; do
+IFS=$ac_save_ifs
if (test -f $dir/echo || test -f $dir/echo$ac_exeext)
test X`($dir/echo '\t') 2/dev/null` = 'X\t'
echo_testing_string=`($dir/echo $echo_test_string) 2/dev/null`
@@ -307,7 +308,7 @@
break
fi
done
- IFS=$save_ifs
+ IFS=$ac_save_ifs
if test X$echo = Xecho; then
# We didn't find a better echo, so look for alternatives.
@@ -3025,6 +3026,7 @@
IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}:,
for tagname in $tagnames; do
+IFS=$ac_save_ifs
# Check whether tagname contains only valid characters
[case `$echo X$tagname | $Xsed -e
's/[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]//g'` in]
) ;;
@@ -3053,6 +3055,7 @@
available_tags=$available_tags $tagname
fi
done
+ IFS=$ac_save_ifs
# Now substitute the updated list of available tags.
if eval sed -e 's/^available_tags=.*\$/available_tags=\$available_tags\/'
\$ofile\ \${ofile}T\; then
@@ -3182,6 +3185,7 @@
# Look at the argument we got. We use all the common list separators.
IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}:,
for pkg in $enableval; do
+IFS=$ac_save_ifs
if test X$pkg = X$p; then
enable_shared=yes
fi
@@ -3221,6 +3225,7 @@
# Look at the argument we got. We use all the common list separators.
IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}:,
for pkg in $enableval; do
+IFS=$ac_save_ifs
if test X$pkg = X$p; then
enable_static=yes
fi
@@ -3260,6 +3265,7 @@
# Look at the argument we got. We use all the common list separators.
IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}:,
for pkg in $enableval; do
+IFS=$ac_save_ifs
if test X$pkg = X$p; then
enable_fast_install=yes
fi
@@ -3311,6 +3317,7 @@
dnl not every word. This closes a longstanding sh security hole.
ac_dummy=ifelse([$2], , $PATH, [$2])
for ac_dir in $ac_dummy; do
+IFS=$ac_save_ifs
test -z $ac_dir ac_dir=.
if test -f $ac_dir/$1; then
lt_cv_path_MAGIC_CMD=$ac_dir/$1
@@ -3420,6 +3427,7 @@
[if test -z $LD; then
IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}${PATH_SEPARATOR-:}
for ac_dir in $PATH; do
+IFS=$ac_save_ifs
test -z $ac_dir ac_dir=.
if test -f $ac_dir/$ac_prog || test -f $ac_dir/$ac_prog$ac_exeext; then
lt_cv_path_LD=$ac_dir/$ac_prog
@@ -3665,6 +3673,7 @@
else
IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}${PATH_SEPARATOR-:}
for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
+IFS=$ac_save_ifs
test -z $ac_dir ac_dir=.
tmp_nm=$ac_dir/${ac_tool_prefix}nm
if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
Regards,
Pavel Roskin
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
CVS problems
Hello! I cannot update libtool from CVS anymore. The problem persists when I check out libtool from scratch. $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs co libtool U libtool/.cvsignore U libtool/AUTHORS U libtool/ChangeLog U libtool/ChangeLog.0 U libtool/Makefile.am U libtool/NEWS U libtool/PORTING U libtool/README U libtool/README-alpha U libtool/THANKS U libtool/TODO U libtool/bootstrap U libtool/commit U libtool/config.guess U libtool/config.sub U libtool/configure.in U libtool/libtool.m4 U libtool/libtoolize.in U libtool/ltdl.m4 U libtool/ltmain.c U libtool/ltmain.in U libtool/mkstamp cvs server: failed to create lock directory in repository `/cvs/libtool/CVSROOT': Permission denied cvs server: failed to obtain dir lock in repository `/cvs/libtool/CVSROOT' cvs [server aborted]: read lock failed - giving up I'm using CVS 1.11.0.1. Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Forbidden strings
Hello, Akim! In Autoconf, the words which include _A?_, A?_, _m4_, m4_ are forbidden, in order to diagnose unexpanded macros. There is (currently) no escape to this rule. Not _m4_. ~/src/libtool % ace nostromo 15:58 configure:5870: error: undefined macro: lt_AR_FLAGS configure:5870: error: undefined macro: AR_FLAGS What should we do? Return to A[CHMSTU] Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: mulit-language-branch BUG: circular macro dependencies
Hello, Robert! I am using the mulit-language-branch of CVS libtool with the CVS sources of autoconf and automake. About a week or two ago CVS version of autoconf now supports detection of circular dependencies. The HEAD branch of libtool is affected as well (libltdl/configure.in only) somthing changed in one of these packages to make autoconf fail. Now autoconf complains about circular dependencies Autoconf has been improved :-) icarus::/icarus/OCC/OCC (112)% autoconf -v That's strange. For me, only tagdemo/configure.in and libltdl/configure.in have circular dependencies. The top level is Ok. configure.in:16: warning: AC_PROG_CPP was called before AC_PROG_CC configure.in:20: AC_REQUIRE: circular dependency of AC_PROG_LIBTOOL configure.in:20: AC_PROG_LIBTOOL is required by... ./aclocal.m4:1233: _AC_LIBTOOL_CXX is expanded from... configure.in:20: _AC_LIBTOOL_CXX is required by... ./aclocal.m4:1207: AC_LIBTOOL_CXX is expanded from... ./aclocal.m4:495: AC_PROG_LIBTOOL is expanded from... configure.in:20: the top level My understanding is that AC_PROG_LIBTOOL in the ml-branch tries to fool autoconf and gets caught by the new dependency tracking code. Concerning libltdl/configure.in, there is indeed a loop: configure.in:36: AC_LTDL_SYMBOL_USCORE is required by... ./aclocal.m4:1265: AC_LTDL_DLSYM_USCORE is expanded from... ./aclocal.m4:1203: AC_LTDL_SYMBOL_USCORE is expanded from... which means that AC_LTDL_SYMBOL_USCORE calls AC_LTDL_DLSYM_USCORE which requires AC_LTDL_SYMBOL_USCORE. Either AC_LTDL_DLSYM_USCORE should be made private (_LT_AC_LTDL_DLSYM_USCORE) and the AC_REQUIRE should be dropped, or AC_LTDL_SYMBOL_USCORE should be split into two parts, and AC_LTDL_DLSYM_USCORE should require the first part that defines $ac_cv_sys_symbol_underscore I don't know how important is it to call AC_LTDL_DLSYM_USCORE independently, so I cannot choose the best solution. and everything else works fine. When I first saw the dependency problems, I tried to find a loop in the dependencies, but I didn't see one. Could someone comment on what happened? I'm afraid that you are trying to find a problem on the top level that actully sits in the subdirs. Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: changequote used incorrectly
Hello, Akim! Yes, this is a bad recommendation. And in fact you frightened me Pavel, by current you mean 2.13, right? I could not find this horror in the CVS documentation. But there is an answer to the above statement: Sorry to all :-( "info --file autoconf.info" looks in /usr/info before the current directory. Not very intuitive :-( So in the case Pavel fixed, I'd suggest to follow the advice of Lars. I'm fixed now :-) I'll try to remove changequote()s from libtool.m4 as long as it remains compatible with Autoconf-2.13 Regards, Pavel Roskin
Something bad happened
Hello, Gary! The latest commit to the head brach in the libtool repository breaks libtool. With autoconf-2.13 and automake-1.4 this looks like this: automake: configure.in: installing `./install-sh' automake: configure.in: installing `./mkinstalldirs' automake: configure.in: installing `./missing' automake: Makefile.am: installing `./INSTALL' automake: Makefile.am: installing `./COPYING' doc/Makefile.am:4: installing `doc/mdate-sh' doc/Makefile.am:4: installing `doc/texinfo.tex' configure.in: 33: required file `../ltconfig' not found With the CVS-current autoconf and automake the breakage is much worse: configure.in:50: /usr/bin/m4: Bad regular expression `[\([`""]\)]': Unmatched ) or \) configure.in:50: [[error: [[[backquotes and double quotes should not be backslashed in: [[configure: WARNING: [\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]]] ]configure.in:50: /usr/bin/m4: Non-numeric argument to built-in `m4exit' /usr/local/bin/autoheader: /tmp/ah1156/traces.sh: line 12: unexpected EOF while looking for matching `'' /usr/local/bin/autoheader: /tmp/ah1156/traces.sh: line 14: syntax error: unexpected end of file autoheader: config.h.in is unchanged configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead configure.in:29: warning: AC_C_CONST was called before AC_PROG_CC_STDC configure.in:33: /usr/bin/m4: Bad regular expression `[\([`""]\)]': Unmatched ) or \) configure.in:33: [[error: [[[backquotes and double quotes should not be backslashed in: [[configure: WARNING: [\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]]] ]configure.in:33: /usr/bin/m4: Non-numeric argument to built-in `m4exit' configure.in: 10: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead configure.in:7: warning: AC_C_CONST was called before AC_PROG_CC_STDC configure.in:10: /usr/bin/m4: Bad regular expression `[\([`""]\)]': Unmatched ) or \) configure.in:10: [[error: [[[backquotes and double quotes should not be backslashed in: [[configure: WARNING: [\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]]] ]configure.in:10: /usr/bin/m4: Non-numeric argument to built-in `m4exit' configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead configure.in:8: /usr/bin/m4: Bad regular expression `[\([`""]\)]': Unmatched ) or \) configure.in:8: [[error: [[[backquotes and double quotes should not be backslashed in: [[configure: WARNING: [\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]]] ]configure.in:8: /usr/bin/m4: Non-numeric argument to built-in `m4exit' configure.in: 16: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead configure.in:7: warning: AC_C_CONST was called before AC_PROG_CC_STDC configure.in:16: /usr/bin/m4: Bad regular expression `[\([`""]\)]': Unmatched ) or \) configure.in:16: [[error: [[[backquotes and double quotes should not be backslashed in: [[configure: WARNING: [\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]]] ]configure.in:16: /usr/bin/m4: Non-numeric argument to built-in `m4exit' configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead configure.in:8: /usr/bin/m4: Bad regular expression `[\([`""]\)]': Unmatched ) or \) configure.in:8: [[error: [[[backquotes and double quotes should not be backslashed in: [[configure: WARNING: [\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]]] ]configure.in:8: /usr/bin/m4: Non-numeric argument to built-in `m4exit' I haven't investigated the problem in depth. It must be an incomplete commit or something like that. I hope you will fix this promptly. Regards, Pavel Roskin
Re: Ensuring compatibility between libtool components
Hello, Alexandre! There are two approaches to extracting the scripts: we may get their contents into the configure script, through some macro, or try to This will make "configure" huge. Not nice, but it should work. arrange for configure to find them in libtool.m4 or aclocal.m4, avoiding the duplication of the scripts, but risking not finding the m4 file. You mean that "aclocal" should put the code into aclocal.m4 because it finds a macro in "configure.in"? I don't know how you are going to prevent autoconf from including that code to "configure". I believe that you will have to fool either aclocal or autoconf, so my opinion will depend on how you are going to do it. Regards, Pavel Roskin
Target for libtool?
Hello! The current Libtool from CVS (head version) fails when I run configure: ltconfig: you must specify a host type if you use `--no-verify' It turns out that the following code from libtool.m4 is at fault: case "$target" in NONE) lt_target="$host" ;; *) lt_target="$target" ;; esac With the CVS Autoconf "$target" is an empty string. "$host" is not empty. This code apparently expects "$target" to be "NONE" for native configurations. Question 1. What has Libtool to do with "$target"? Libtool is a wrapper around the compiler doing the build, not being built. Question 2. If I'm missing something and more serious modifications are not needed, shouldn't we write the following code instead? case "x$target" in xNONE|x) lt_target="$host" ;; *) lt_target="$target" ;; esac This change passes "make check" in libtool (provided that a typo in libltdl/ltdl.c if fixed as well) Just in case, I'm using RedHat Linux 6.1 on i586 with gcc-2.95.2, bash-1.14.7, m4-1.4, CVS/Head verions of Autoconf, Automake and Libtool. Regards, Pavel Roskin
Extra 'g' in libltdl/ltdl.c
Hello! The CVS/Head version of libltdl/ltdl.c begins with 'g' Please be careful and run "make check" before "cvs commit" Time to setup Tinderbox for Auto* tools? Regards, Pavel Roskin
file_magic broken
Hello! It looks like that using "file_magic" as "deplibs_check_method" is broken in the current CVS repository. At least support for LinuxPPC is broken. There may be some reasons not to use pass_all on this platform (because old libc-1.99 is still around), and I don't want to enable pass_all it just as a workaround for a more generic problem. The simplest way to reproduce on Linux-i386: Find "i*86 |" in libtool.m4 and remove it. Then run ./bootstrap ./configure make make will hang after printing: /bin/sh ./libtool --mode=link gcc -g -O2 -o libltdl.la -rpath /usr/local/lib -no-undefined -version-info 2:0:2 ltdl.lo -ldl rm -fr .libs/libltdl.la .libs/libltdl.* .libs/libltdl.* It appears that $FILE is defined to an empty string. It's output is fed to sed or egrep, and they expect input on stdin. Regards, Pavel Roskin
Test case for the problem in Kaffe
Hello! The Kaffe project (www.kaffe.org) is now suffering from a bug in the current (CVS/HEAD) libtool. When an executable is linked both against "normal" libraries and modules to be dlopened the modules always appear first in the compiler command line, regardless of their order in the libtool command line This may cause unresolved symbols when static linking is used and the modules call some functions in the "normal" library. No one test in the libtool testsuite can currently detect the problem. The attached patch makes "mdemo" detect the problem. It can be installed as a separate test or as a patch against mdemo. ChangeLog: * mdemo/Makefile.am: new library libbar.la for testing the linking order * mdemo/main.c: move most functionality to... * mdemo/bar1.c: new file * mdemo/bar2.c: new file defining test_callback() * mdemo/foo1.c (hello): call test_callback * mdemo/foo2.c (hello): Likewise As you can see, mdemo.static cannot be linkled anymore. There is no fix yet. Hopefully people more experiences in dlopen() matters can do it better/faster. Pavel Roskin mdemo.diff.gz
