Re: FYI: ltmain.m4sh needs to handle spaces in paths
Hi Derek,
* Derek Price wrote on Thu, Jul 07, 2005 at 07:11:40PM CEST:
Ralf Wildenhues wrote:
Oh, I wasn't going to yank it. That was supposed to be a joke.
If you take it as an incentive to fix more cases, the better. :)
Okay, the attached patch to 1.5 fixes loads of quoting issues on Windows
and passes tests on GNU/Linux. Basically, I made the minimal set of
changes I needed to to get a large project containing libraries and
executables to compile on Windows, except that if I set up the elements
of a variable to be quoted in one location, I quoted them everywhere for
consistency.
Wow. Thanks for working on this!
I then backported the changes to get the tests to pass again on Linux.
The backporting to UNIX entailed a few minor changes to libtool.m4,
demo/Makefile.am, and a few tests. The test changes basically just
expect the quotes to appear in output now.
What I *didn't* do is move my libtool workspace to a name with a space
and try to run the test suite on LINUX, so there are probably still a
few changes that need to be made to handle spaces in directories on
LINUX. I also didn't try targets with spaces or relative paths within a
project with spaces. This should pretty much only handle spaces in `pwd`.
OK. I would like to test this as much as possible, in order to prevent
regressions, so test cases would be very much necessary.
One big problem of this patch is that it breaks two ways of backward
compatibility. First, a library installed with a libtool with this
patch cannot be linked against by an older libtool. Second, the patched
libtool also does not recognize older, already-installed .la files. For
a stable series like branch-1-5, I really would not like to do this.
OTOH, I believe it is an important goal for libtool to have this added
functionality. So the way I'd believe would be best would be to put in
branch-1-5 the functionality to _parse_ installed .la files that contain
the quotes (but do not contain spaces in paths), but only enable in HEAD
or maybe branch-2-0 the code that puts in the quotes. In any case HEAD
should be able to link against older .la files which do not contain the
quoting.
That way, at least there would be a clean upgrade path
1.5.18 - 1.5.next - 2.x
without a trap in 2.x.
Also, we should probably ship an upgrade script which could rewrite
installed .la files to the new notation.
Furthermore, libltdl would need to be adapted as well (and tests written
for that).
Another solution^Whack would be to do the same thing as done previously
with backwards-incompatible extensions: put the new style into a new
variable (e.g., $quoted_dependency_libs). While somewhat more
convenient, it is also ugly and leads to bloat in the .la files. Dunno
what's the best here. :-/
A few small glitches with your patch are noted below for convenience.
Regards,
Ralf
2005-07-07 Derek R. Price [EMAIL PROTECTED]
* libtool.m4: Quote paths in $hardcode_libdir_flag_spec.
* ltmain.in: Quote paths potentially containing spaces. Use set and
$@ to loop on variables potentially containing quoted elements.
* demo/Makefile.am (hc-libflag): Use eval to process quoted
arguments inside variables.
* tests/link-order.test, tests/link.test: Expect quoted arguments.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.95
diff -u -p -r1.314.2.95 libtool.m4
--- libtool.m43 Jul 2005 18:15:58 - 1.314.2.95
+++ libtool.m47 Jul 2005 17:00:45 -
@@ -2753,7 +2753,7 @@ if test $GXX = yes; then
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
-_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
+_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath
\${wl}$libdir\'
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
# If archive_cmds runs LD, not CC, wlarc should be empty
While ok for most cases, in general it is not ok to quote ${wl}. For
example, on Solaris it might get expanded to `-Qoption ld '; quoting
like this: ${wl}\$libdir\$
should be ok, though.
*big snip*
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.76
diff -u -p -r1.334.2.76 ltmain.in
--- ltmain.in 3 Jul 2005 16:57:34 - 1.334.2.76
+++ ltmain.in 7 Jul 2005 17:00:49 -
@@ -251,12 +251,12 @@ func_extract_an_archive ()
f_ex_an_ar_dir=$1; shift
f_ex_an_ar_oldlib=$1
-$show
FYI: BUG: libtool-1.9f and libtool-1.5.18: install: you must specify a destination
* Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 07:05:01PM CEST: * Juergen Leising wrote on Wed, Jul 06, 2005 at 09:03:49AM CEST: The following error message appears due to a bug in func_mode_install (): /bin/sh ../../../libtool --mode=install cp -f 'libeic.la' '/usr/local/lib/bastard/libeic.la' libtool: install: you must specify a destination libtool: install: Try `libtool --help --mode=install' for more information. Proposed patch (against HEAD, similar for backport): I have installed this slightly simpler patch, which also allows backslash as directory separator, to all branches. I decided to ignore the slight chance of misparse that may ensue with a group named `cp': install -g cp ... Cheers, Ralf HEAD/branch-2-0: * config/ltmain.m4sh (func_mode_install): Do not assume `-f' needs an argument if the install program is `cp'. Cleanup install mode somewhat. Reported by Juergen Leising [EMAIL PROTECTED]. Index: config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v retrieving revision 1.72 diff -u -r1.72 ltmain.m4sh --- config/ltmain.m4sh 3 Jul 2005 16:55:50 - 1.72 +++ config/ltmain.m4sh 8 Jul 2005 13:41:32 - @@ -1685,15 +1685,15 @@ # install_prog (especially on Windows NT). if test $nonopt = $SHELL || test $nonopt = /bin/sh || # Allow the use of GNU shtool's install command. - $ECHO X$nonopt | $Xsed | $GREP shtool /dev/null; then + $ECHO X$nonopt | $GREP shtool /dev/null; then # Aesthetically quote it. func_quote_for_eval $nonopt install_prog=$func_quote_for_eval_result - arg=$1 + arg=$1 shift else install_prog= - arg=$nonopt + arg=$nonopt fi # The real first argument should be the name of the installation program. @@ -1713,28 +1713,33 @@ do if test -n $dest; then files=$files $dest - dest=$arg + dest=$arg continue fi case $arg in -d) isdir=yes ;; - -f) prev=-f ;; - -g) prev=-g ;; - -m) prev=-m ;; - -o) prev=-o ;; + -f) + case $install_prog in + *[[\\\ /]]cp\ *) ;; + *) prev=$arg ;; + esac + ;; + -g | -m | -o) + prev=$arg + ;; -s) stripme= -s continue ;; - -*) ;; - + -*) + ;; *) # If the previous option needed an argument, then skip it. if test -n $prev; then prev= else - dest=$arg + dest=$arg continue fi ;; branch-1-5: * ltmain.in (install mode): Do not assume `-f' needs an argument if the install program is `cp'. Cleanup install mode somewhat. Reported by Juergen Leising [EMAIL PROTECTED]. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.76 diff -u -r1.334.2.76 ltmain.in --- ltmain.in 3 Jul 2005 16:57:34 - 1.334.2.76 +++ ltmain.in 8 Jul 2005 13:42:26 - @@ -5361,7 +5361,7 @@ # install_prog (especially on Windows NT). if test $nonopt = $SHELL || test $nonopt = /bin/sh || # Allow the use of GNU shtool's install command. - $echo X$nonopt | $Xsed | grep shtool /dev/null; then + $echo X$nonopt | grep shtool /dev/null; then # Aesthetically quote it. arg=`$echo X$nonopt | $Xsed -e $sed_quote_subst` case $arg in @@ -5374,7 +5374,7 @@ shift else install_prog= - arg=$nonopt + arg=$nonopt fi # The real first argument should be the name of the installation program. @@ -5399,28 +5399,31 @@ do if test -n $dest; then files=$files $dest - dest=$arg + dest=$arg continue fi case $arg in -d) isdir=yes ;; - -f) prev=-f ;; - -g) prev=-g ;; - -m) prev=-m ;; - -o) prev=-o ;; + -f) + case $install_prog in + *[\\\ /]cp\ *) ;; + *) prev=$arg ;; + esac + ;; + -g | -m | -o) prev=$arg ;; -s) stripme= -s continue ;; - -*) ;; - + -*) + ;; *) # If the previous option needed an argument, then skip it. if test -n $prev; then prev= else - dest=$arg + dest=$arg continue fi ;; ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.14 on mingw: DLLs must be installed executable
Hi Bruno, * Bruno Haible wrote on Fri, Jul 08, 2005 at 03:07:33PM CEST: Using libtool 1.5.14 to install libiconv built for mingw, any program linked against the such installed libiconv-2.dll crashes on startup with a dialog box: The application failed to initialize properly (0xc022) The reason, as explained in http://www.mail-archive.com/cygwin@cygwin.com/msg23724.html is that libtool installs the DLL without the execution bit. Here is a fix. Erm, the fix is fine, but what caused the breakage in the first place? Surely this hasn't been broken all the time? Cheers, Ralf 2005-07-08 Bruno Haible [EMAIL PROTECTED] * libtool.m4 (postinstall_cmds) [cygwin,mingw,pw32]: Make DLL executable after installing it. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
FYI: tests/sh.test uses $SED without setting it
* Derek Price wrote on Fri, Jul 08, 2005 at 05:20:14PM CEST:
Ralf Wildenhues wrote:
* Derek Price wrote on Thu, Jul 07, 2005 at 07:06:37PM CEST:
While working on some other stuff, I noticed that tests/sh.test is
calling $SED without it being set, though this was only causing a
*snip*
You omitted the patch. I believe you are talking about branch-1-5
Libtool, right? How about setting SED and Xsed in tests/defs?
That would be fine, though it looks like tests/sh.test is the only test
using $SED on 1.5. I've attached my original patch anyho in case you
want it - it just adds `: ${SED=sed}' to an early line of tests/sh.test
to set a default without overriding any environment.
Alright. I have applied this to branch-1-5. This issue is not present
in the other branches. IMHO it does not matter which sed is chosen
here.
Thanks!
Ralf
2005-07-08 Derek R. Price [EMAIL PROTECTED]
* tests/defs (SED): Default variable contents to `sed'.
Fixes false PASS of sh.test.
Index: tests/defs
===
RCS file: /cvsroot/libtool/libtool/tests/Attic/defs,v
retrieving revision 1.5.2.3
diff -u -r1.5.2.3 defs
--- tests/defs 8 Apr 2005 13:00:50 - 1.5.2.3
+++ tests/defs 8 Jul 2005 15:26:53 -
@@ -17,8 +17,9 @@
progname=`echo $0 | sed 's%^.*/%%'`
libtool=../libtool
-make=${MAKE-make}
SHELL=${CONFIG_SHELL-/bin/sh}
+: ${MAKE=make}
+: ${SED=sed}
if echo a | (grep -E '(a|b)') /dev/null 21; then
EGREP='grep -E'
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: FYI: tests/sh.test uses $SED without setting it
* Ralf Wildenhues wrote on Fri, Jul 08, 2005 at 05:28:06PM CEST:
--- tests/defs8 Apr 2005 13:00:50 - 1.5.2.3
+++ tests/defs8 Jul 2005 15:26:53 -
@@ -17,8 +17,9 @@
progname=`echo $0 | sed 's%^.*/%%'`
libtool=../libtool
-make=${MAKE-make}
SHELL=${CONFIG_SHELL-/bin/sh}
+: ${MAKE=make}
+: ${SED=sed}
if echo a | (grep -E '(a|b)') /dev/null 21; then
EGREP='grep -E'
Argh. I'm very sorry.
2005-07-08 Ralf Wildenhues [EMAIL PROTECTED]
* tests/defs (make): Undo bogus change I did, and also
wrongly attributed to Derek R. Price.
Index: tests/defs
===
RCS file: /cvsroot/libtool/libtool/tests/Attic/defs,v
retrieving revision 1.5.2.4
diff -u -r1.5.2.4 defs
--- tests/defs 8 Jul 2005 15:27:52 - 1.5.2.4
+++ tests/defs 8 Jul 2005 15:47:00 -
@@ -17,8 +17,8 @@
progname=`echo $0 | sed 's%^.*/%%'`
libtool=../libtool
+make=${MAKE-make}
SHELL=${CONFIG_SHELL-/bin/sh}
-: ${MAKE=make}
: ${SED=sed}
if echo a | (grep -E '(a|b)') /dev/null 21; then
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
FYI: libtool-1.5.18 -- installed files owned by non-root user
* Peter Breitenlohner wrote on Wed, Jul 06, 2005 at 09:34:24AM CEST: What about simply chown -R root $(DESTDIR)$(ltdldatadir) \ chgrp -R root $(DESTDIR)$(ltdldatadir) || : where failure of chown/chgrp is ignored? Who cares about some noise when `make install' is done by non-root or on non-posix systems, in particular when the cause of such noise can easily be deduced. FYI: I have applied this to all three branches. Thanks, Ralf HEAD/branch-2-0: 2005-07-08 Peter Breitenlohner [EMAIL PROTECTED] * Makefile.am (install-data-local): Have root own of installed files (but do not fail, for user installs). Index: Makefile.am === RCS file: /cvsroot/libtool/libtool/Makefile.am,v retrieving revision 1.153 diff -u -r1.153 Makefile.am --- Makefile.am 2 May 2005 09:20:24 - 1.153 +++ Makefile.am 8 Jul 2005 15:54:01 - @@ -254,6 +254,8 @@ done; \ ( cd $(srcdir)/m4 $(AMTAR) chf - $$aclocalfiles; ) \ | ( umask 0 cd $(DESTDIR)$(aclocaldir) $(AMTAR) xf -; ) + chown -R root $(DESTDIR)$(ltdldatadir) \ + chgrp -R root $(DESTDIR)$(ltdldatadir) || : install-data-hook: chmod +x $(DESTDIR)$(pkgdatadir)/config/config.guess branch-1-5: 2005-07-08 Peter Breitenlohner [EMAIL PROTECTED] * libltdl/Makefile.am (local-install-files): Have root own of installed files (but do not fail, for user installs). Index: libltdl/Makefile.am === RCS file: /cvsroot/libtool/libtool/libltdl/Makefile.am,v retrieving revision 1.42.2.6 diff -u -r1.42.2.6 Makefile.am --- libltdl/Makefile.am 2 May 2005 12:52:07 - 1.42.2.6 +++ libltdl/Makefile.am 8 Jul 2005 15:53:30 - @@ -47,3 +47,5 @@ $(mkinstalldirs) $(DESTDIR)$(ltdldatadir) ( cd $(srcdir) $(AMTAR) chf - $(ltdldatafiles); ) \ | ( umask 0 cd $(DESTDIR)$(ltdldatadir) $(AMTAR) xf -; ) + chown -R root $(DESTDIR)$(ltdldatadir) \ + chgrp -R root $(DESTDIR)$(ltdldatadir) || : ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: FYI: libtool-1.5.18 -- installed files owned by non-root user
Hallo Ralf,
Sorry for the late review:
On 8 Jul 2005, at 16:57, Ralf Wildenhues wrote:
2005-07-08 Peter Breitenlohner [EMAIL PROTECTED]
* Makefile.am (install-data-local): Have root own of installed
files (but do not fail, for user installs).
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.153
diff -u -r1.153 Makefile.am
--- Makefile.am2 May 2005 09:20:24 -1.153
+++ Makefile.am8 Jul 2005 15:54:01 -
@@ -254,6 +254,8 @@
done; \
( cd $(srcdir)/m4 $(AMTAR) chf - $$aclocalfiles; ) \
| ( umask 0 cd $(DESTDIR)$(aclocaldir) $(AMTAR) xf -; )
+chown -R root $(DESTDIR)$(ltdldatadir) \
+chgrp -R root $(DESTDIR)$(ltdldatadir) || :
What about:
-chown -R root $(DESTDIR)$(ltdldatadir) 2/dev/null
-chgrp -R root $(DESTDIR)$(ltdldatadir) 2/dev/null
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
ChangeLog ltmain.in
CVSROOT:/cvsroot/libtool TIMESTAMP: (1.1220.2.261 2005/07/08 13:48:27) Module name:libtool Branch: branch-1-5 Changes by: [EMAIL PROTECTED] Log Message: * ltmain.in (install mode): Do not assume `-f' needs an argument if the install program is `cp'. Cleanup install mode somewhat. Reported by Juergen Leising [EMAIL PROTECTED]. ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog [branch-2-0]
CVSROOT:/cvsroot/libtool Module name:libtool Branch: branch-2-0 Changes by: Ralf Wildenhues [EMAIL PROTECTED] 05/07/08 13:47:11 Modified files: . : ChangeLog Log message: * config/ltmain.m4sh (func_mode_install): Do not assume `-f' needs an argument if the install program is `cp'. Cleanup install mode somewhat. Reported by Juergen Leising [EMAIL PROTECTED]. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/ChangeLog.diff?only_with_tag=branch-2-0tr1=1.1667.2.258tr2=1.1667.2.259r1=textr2=text ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
FYI: BUG: libtool-1.9f and libtool-1.5.18: install: you must specify a destination
* Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 07:05:01PM CEST: * Juergen Leising wrote on Wed, Jul 06, 2005 at 09:03:49AM CEST: The following error message appears due to a bug in func_mode_install (): /bin/sh ../../../libtool --mode=install cp -f 'libeic.la' '/usr/local/lib/bastard/libeic.la' libtool: install: you must specify a destination libtool: install: Try `libtool --help --mode=install' for more information. Proposed patch (against HEAD, similar for backport): I have installed this slightly simpler patch, which also allows backslash as directory separator, to all branches. I decided to ignore the slight chance of misparse that may ensue with a group named `cp': install -g cp ... Cheers, Ralf HEAD/branch-2-0: * config/ltmain.m4sh (func_mode_install): Do not assume `-f' needs an argument if the install program is `cp'. Cleanup install mode somewhat. Reported by Juergen Leising [EMAIL PROTECTED]. Index: config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v retrieving revision 1.72 diff -u -r1.72 ltmain.m4sh --- config/ltmain.m4sh 3 Jul 2005 16:55:50 - 1.72 +++ config/ltmain.m4sh 8 Jul 2005 13:41:32 - @@ -1685,15 +1685,15 @@ # install_prog (especially on Windows NT). if test $nonopt = $SHELL || test $nonopt = /bin/sh || # Allow the use of GNU shtool's install command. - $ECHO X$nonopt | $Xsed | $GREP shtool /dev/null; then + $ECHO X$nonopt | $GREP shtool /dev/null; then # Aesthetically quote it. func_quote_for_eval $nonopt install_prog=$func_quote_for_eval_result - arg=$1 + arg=$1 shift else install_prog= - arg=$nonopt + arg=$nonopt fi # The real first argument should be the name of the installation program. @@ -1713,28 +1713,33 @@ do if test -n $dest; then files=$files $dest - dest=$arg + dest=$arg continue fi case $arg in -d) isdir=yes ;; - -f) prev=-f ;; - -g) prev=-g ;; - -m) prev=-m ;; - -o) prev=-o ;; + -f) + case $install_prog in + *[[\\\ /]]cp\ *) ;; + *) prev=$arg ;; + esac + ;; + -g | -m | -o) + prev=$arg + ;; -s) stripme= -s continue ;; - -*) ;; - + -*) + ;; *) # If the previous option needed an argument, then skip it. if test -n $prev; then prev= else - dest=$arg + dest=$arg continue fi ;; branch-1-5: * ltmain.in (install mode): Do not assume `-f' needs an argument if the install program is `cp'. Cleanup install mode somewhat. Reported by Juergen Leising [EMAIL PROTECTED]. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.76 diff -u -r1.334.2.76 ltmain.in --- ltmain.in 3 Jul 2005 16:57:34 - 1.334.2.76 +++ ltmain.in 8 Jul 2005 13:42:26 - @@ -5361,7 +5361,7 @@ # install_prog (especially on Windows NT). if test $nonopt = $SHELL || test $nonopt = /bin/sh || # Allow the use of GNU shtool's install command. - $echo X$nonopt | $Xsed | grep shtool /dev/null; then + $echo X$nonopt | grep shtool /dev/null; then # Aesthetically quote it. arg=`$echo X$nonopt | $Xsed -e $sed_quote_subst` case $arg in @@ -5374,7 +5374,7 @@ shift else install_prog= - arg=$nonopt + arg=$nonopt fi # The real first argument should be the name of the installation program. @@ -5399,28 +5399,31 @@ do if test -n $dest; then files=$files $dest - dest=$arg + dest=$arg continue fi case $arg in -d) isdir=yes ;; - -f) prev=-f ;; - -g) prev=-g ;; - -m) prev=-m ;; - -o) prev=-o ;; + -f) + case $install_prog in + *[\\\ /]cp\ *) ;; + *) prev=$arg ;; + esac + ;; + -g | -m | -o) prev=$arg ;; -s) stripme= -s continue ;; - -*) ;; - + -*) + ;; *) # If the previous option needed an argument, then skip it. if test -n $prev; then prev= else - dest=$arg + dest=$arg continue fi ;;
FYI: branch-1-5: root-owned libtool files in build tree after relink
* Ralf Wildenhues wrote on Sun, Jul 03, 2005 at 10:39:46AM CEST:
I noted a work-around in the MirBSD port of Libtool for root-created
leftovers in .libs after a `make install' which requires relinking,
*snip*
Could you confirm that this patch below fixes the issue instead?
FYI: I have applied this patch to branch-1-5 (it's already in the other
branches).
I like the idea of not writing to the build tree at all during relinking
(and also relinking in less situations), but both of these issues are
orthogonal to the question whether the relink step, if done, needs to
clean up after itself. So they will be addressed in another patch..
Regards,
Ralf
2005-07-03 Albert Chin-A-Young [EMAIL PROTECTED]
* ltmain.in: When a library is installed, dependent on a
convenience library, and it involves relinking, the object
files extracted from the convenience library are not removed
after the relink. This is a problem if you build as non-root,
install as root, then try to remove the build directory as
non-root; Clean up properly if relink fails; Change
$realnameU to ${realname}T to be consistent.
Missing backport of 2004-03-24 patch reported against MirLibtool
by Marc Matteo [EMAIL PROTECTED].
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.74
diff -u -r1.334.2.74 ltmain.in
--- ltmain.in 1 Jul 2005 02:23:01 - 1.334.2.74
+++ ltmain.in 3 Jul 2005 08:31:39 -
@@ -4009,13 +4009,30 @@
IFS=$save_ifs
eval cmd=\$cmd\
$show $cmd
- $run eval $cmd || exit $?
+ $run eval $cmd || {
+ lt_exit=$?
+
+ # Restore the uninstalled library and exit
+ if test $mode = relink; then
+ $run eval '(cd $output_objdir $rm ${realname}T $mv
${realname}U $realname)'
+ fi
+
+ exit $lt_exit
+ }
done
IFS=$save_ifs
# Restore the uninstalled library and exit
if test $mode = relink; then
$run eval '(cd $output_objdir $rm ${realname}T $mv $realname
${realname}T $mv $realnameU $realname)' || exit $?
+
+ if test -n $convenience; then
+ if test -z $whole_archive_flag_spec; then
+ $show ${rm}r $gentop
+ $run ${rm}r $gentop
+ fi
+ fi
+
exit $EXIT_SUCCESS
fi
@@ -5615,7 +5632,16 @@
IFS=$save_ifs
eval cmd=\$cmd\
$show $cmd
- $run eval $cmd || exit $?
+ $run eval $cmd || {
+ lt_exit=$?
+
+ # Restore the uninstalled library and exit
+ if test $mode = relink; then
+ $run eval '(cd $output_objdir $rm ${realname}T $mv
${realname}U $realname)'
+ fi
+
+ exit $lt_exit
+ }
done
IFS=$save_ifs
fi
FYI: libtool 1.5.14 on mingw: DLLs must be installed executable
* Bruno Haible wrote on Fri, Jul 08, 2005 at 04:38:16PM CEST: Ralf Wildenhues wrote: Erm, the fix is fine, but what caused the breakage in the first place? Surely this hasn't been broken all the time? For me, it has been broken all the time: It's the first time I've succeeded building a working DLL with mingw and libtool 1.5.x. Maybe something about my setup is particular: it's Windows XP, NTFS, with security permission settings that have been modified by someone else. In other words, it may be not the default config, but it's a config you can easily end up with, without seeing other obvious breakage. OK. Applied to all three branches (patch against branch-2-0/HEAD below). Thanks! Cheers, Ralf 2005-07-08 Bruno Haible [EMAIL PROTECTED] * m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) postinstall_cmds [cygwin,mingw,pw32]: Make DLL executable after installing it. Index: m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v retrieving revision 1.125.2.65 diff -u -r1.125.2.65 libtool.m4 --- m4/libtool.m4 3 Jul 2005 18:15:30 - 1.125.2.65 +++ m4/libtool.m4 8 Jul 2005 14:56:47 - @@ -1817,6 +1817,7 @@ dldir=$destdir/`dirname \$dlpath`~ test -d \$dldir || mkdir -p \$dldir~ $install_prog $dir/$dlname \$dldir/$dlname~ + chmod a+x \$dldir/$dlname~ if test -n '\''$stripme'\'' test -n '\''$striplib'\''; then $run eval '\''$striplib \$dldir/$dlname'\'' || exit \$?; fi'
FYI: libtool-1.5.18 -- installed files owned by non-root user
* Peter Breitenlohner wrote on Wed, Jul 06, 2005 at 09:34:24AM CEST: What about simply chown -R root $(DESTDIR)$(ltdldatadir) \ chgrp -R root $(DESTDIR)$(ltdldatadir) || : where failure of chown/chgrp is ignored? Who cares about some noise when `make install' is done by non-root or on non-posix systems, in particular when the cause of such noise can easily be deduced. FYI: I have applied this to all three branches. Thanks, Ralf HEAD/branch-2-0: 2005-07-08 Peter Breitenlohner [EMAIL PROTECTED] * Makefile.am (install-data-local): Have root own of installed files (but do not fail, for user installs). Index: Makefile.am === RCS file: /cvsroot/libtool/libtool/Makefile.am,v retrieving revision 1.153 diff -u -r1.153 Makefile.am --- Makefile.am 2 May 2005 09:20:24 - 1.153 +++ Makefile.am 8 Jul 2005 15:54:01 - @@ -254,6 +254,8 @@ done; \ ( cd $(srcdir)/m4 $(AMTAR) chf - $$aclocalfiles; ) \ | ( umask 0 cd $(DESTDIR)$(aclocaldir) $(AMTAR) xf -; ) + chown -R root $(DESTDIR)$(ltdldatadir) \ + chgrp -R root $(DESTDIR)$(ltdldatadir) || : install-data-hook: chmod +x $(DESTDIR)$(pkgdatadir)/config/config.guess branch-1-5: 2005-07-08 Peter Breitenlohner [EMAIL PROTECTED] * libltdl/Makefile.am (local-install-files): Have root own of installed files (but do not fail, for user installs). Index: libltdl/Makefile.am === RCS file: /cvsroot/libtool/libtool/libltdl/Makefile.am,v retrieving revision 1.42.2.6 diff -u -r1.42.2.6 Makefile.am --- libltdl/Makefile.am 2 May 2005 12:52:07 - 1.42.2.6 +++ libltdl/Makefile.am 8 Jul 2005 15:53:30 - @@ -47,3 +47,5 @@ $(mkinstalldirs) $(DESTDIR)$(ltdldatadir) ( cd $(srcdir) $(AMTAR) chf - $(ltdldatafiles); ) \ | ( umask 0 cd $(DESTDIR)$(ltdldatadir) $(AMTAR) xf -; ) + chown -R root $(DESTDIR)$(ltdldatadir) \ + chgrp -R root $(DESTDIR)$(ltdldatadir) || :
Re: FYI: tests/sh.test uses $SED without setting it
* Ralf Wildenhues wrote on Fri, Jul 08, 2005 at 05:28:06PM CEST:
--- tests/defs8 Apr 2005 13:00:50 - 1.5.2.3
+++ tests/defs8 Jul 2005 15:26:53 -
@@ -17,8 +17,9 @@
progname=`echo $0 | sed 's%^.*/%%'`
libtool=../libtool
-make=${MAKE-make}
SHELL=${CONFIG_SHELL-/bin/sh}
+: ${MAKE=make}
+: ${SED=sed}
if echo a | (grep -E '(a|b)') /dev/null 21; then
EGREP='grep -E'
Argh. I'm very sorry.
2005-07-08 Ralf Wildenhues [EMAIL PROTECTED]
* tests/defs (make): Undo bogus change I did, and also
wrongly attributed to Derek R. Price.
Index: tests/defs
===
RCS file: /cvsroot/libtool/libtool/tests/Attic/defs,v
retrieving revision 1.5.2.4
diff -u -r1.5.2.4 defs
--- tests/defs 8 Jul 2005 15:27:52 - 1.5.2.4
+++ tests/defs 8 Jul 2005 15:47:00 -
@@ -17,8 +17,8 @@
progname=`echo $0 | sed 's%^.*/%%'`
libtool=../libtool
+make=${MAKE-make}
SHELL=${CONFIG_SHELL-/bin/sh}
-: ${MAKE=make}
: ${SED=sed}
if echo a | (grep -E '(a|b)') /dev/null 21; then
Re: FYI: libtool-1.5.18 -- installed files owned by non-root user
Hallo Ralf,
Sorry for the late review:
On 8 Jul 2005, at 16:57, Ralf Wildenhues wrote:
2005-07-08 Peter Breitenlohner [EMAIL PROTECTED]
* Makefile.am (install-data-local): Have root own of installed
files (but do not fail, for user installs).
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.153
diff -u -r1.153 Makefile.am
--- Makefile.am2 May 2005 09:20:24 -1.153
+++ Makefile.am8 Jul 2005 15:54:01 -
@@ -254,6 +254,8 @@
done; \
( cd $(srcdir)/m4 $(AMTAR) chf - $$aclocalfiles; ) \
| ( umask 0 cd $(DESTDIR)$(aclocaldir) $(AMTAR) xf -; )
+chown -R root $(DESTDIR)$(ltdldatadir) \
+chgrp -R root $(DESTDIR)$(ltdldatadir) || :
What about:
-chown -R root $(DESTDIR)$(ltdldatadir) 2/dev/null
-chgrp -R root $(DESTDIR)$(ltdldatadir) 2/dev/null
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
Re: Alternate SONAME values
Hi Keith, * Keith Packard wrote on Fri, Jul 08, 2005 at 06:59:10AM CEST: On Fri, 2005-07-08 at 09:24 +0530, Ganesan Rajagopal wrote: But libXaw.so.major_number is the default behaviour for libtool. Are you using -release instead of -version-info or -version-number? I think -version-number will give you exactly what you need. I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so And, yes, I'm already using -version-number (which I added to libtool) as X has always used the same version number on all platforms (yes, this is bad, but I can't do anything about it). I have thought a little bit about this, quite a bit of open questions still, before I can allow myself an informed opinion about this. (I'll freely admit that you probably know more about the topic than I do. :) First, to stay with your GNU/Linux example, unless you also have libXaw.so.6 as symlink, how will ld.so find your library (as installed library; or alternatively as user-installed test version below $HOME)? Second, have you tried this on a different system? Especially for AIX (without runtime linking) Darwin w32 (cygwin/mingw) I don't know off the head whether this could be made to work. Next, what is the general rule for applications which may use libraries that link against different Xaw major versions? Here, big trouble may ensue. It sounds like you don't want to encourage this anyway, but I'm not certain. (Carrying this on and allowing other libs several major versions installed, you may end up with libraries libfoo6-bar2-Xaw7, since the dependent libraries have to carry over that versioning.) Last, I do believe that if Libtool were to allow this, it might have to adapt its deplib search algorithm as well, at least on some systems. This in turn should avoid backwards-incompatibility (i.e., older libtool versions not being able to link against the libs created by newer libtool). Haven't thought about this in detail yet, but I'd really like to avoid breaking applications that depend on libXaw* and happen to use (an older version of) libtool, if possible. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Keith == Keith Packard [EMAIL PROTECTED] writes: On Fri, 2005-07-08 at 09:24 +0530, Ganesan Rajagopal wrote: But libXaw.so.major_number is the default behaviour for libtool. Are you using -release instead of -version-info or -version-number? I think -version-number will give you exactly what you need. I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so Sorry, my bad. I completely misunderstood your question. For some stupid reason I kept seeing libXaw.so.6 instead of libXaw6.so.6. I should've read your mail more carefully. I apologize for attempting to educate you on things that you obviously already know! I don't know a solution to your problem, but now that I have actually understood your mail fully, let me go back and respond to it. May be this time, I'll respond more intelligently :-) And, yes, I'm already using -version-number (which I added to libtool) I knew you're the X Window System Guru, but didn't realize you dug into libtool internals too! Oops, sorry to be preaching to the master :-). Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 08:31 +0200, Ralf Wildenhues wrote: First, to stay with your GNU/Linux example, unless you also have libXaw.so.6 as symlink, how will ld.so find your library (as installed library; or alternatively as user-installed test version below $HOME)? The current ELF shared library mechanism in glibc uses SONAMEs exclusively when locating libraries. The filename is irrelevant. Second, have you tried this on a different system? Especially for AIX (without runtime linking) Darwin w32 (cygwin/mingw) No, I haven't. I have little experience with these systems, so I don't even know if this scheme will work. Hence my question to this list where I imagine there are people with experience on those systems. The key question is whether the system uses SONAMES or filenames to locate libraries. I don't know off the head whether this could be made to work. Next, what is the general rule for applications which may use libraries that link against different Xaw major versions? You're SOL. The different versions all share the same symbol names. Fortunately, this doesn't happen in practice as you don't generally find libraries using Xaw in the wild. And, of course, we actively discourage anyone from using any version of Xaw; it's a terrible library. Here, big trouble may ensue. It sounds like you don't want to encourage this anyway, but I'm not certain. (Carrying this on and allowing other libs several major versions installed, you may end up with libraries libfoo6-bar2-Xaw7, since the dependent libraries have to carry over that versioning.) Last, I do believe that if Libtool were to allow this, it might have to adapt its deplib search algorithm as well I don't care about this; I remove all .la files on my system as they are only trouble. Of course, this breaks any application using libltdl, but so far that hasn't been a big deal. I consider this latter a bug in ltdl and not a reason to install .la files. I have local hacks for libtool which prevent the .la files from being installed in the first place, which has certainly saved me a lot of pain as I constantly move libraries around on my system. , at least on some systems. This in turn should avoid backwards-incompatibility (i.e., older libtool versions not being able to link against the libs created by newer libtool). Haven't thought about this in detail yet, but I'd really like to avoid breaking applications that depend on libXaw* and happen to use (an older version of) libtool, if possible. As long as you have no .la files, there's no problem as the libtool search mechanisms are not used. So, the fix here is to just not install any of the libXaw*.la files. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Russ == Russ Allbery [EMAIL PROTECTED] writes: Ganesan Rajagopal [EMAIL PROTECTED] writes: I didn't know this. But trying to make -version-info get the SONAME you need is an abuse of libtool in any case. I think -version-number option available in recent versions of libtool is perfect for this. When introducing libtool with a libraries like X that have a well-established SONAME, one does not get to change the SONAME just because new applications using libtool shouldn't try to override the SONAME. It may be libtool abuse in a new application with no established library versioning, but for X, it's the difference between a working build system and a broken build system. Please re-read what I said :-). Using -version-info (note that this is a different option) to get the SONAME correct is an abuse of libtool because you can't expect it to work reliably. However, using -version-number is not an abuse, it's available for exactly this reason. Once again from the libtool manual === `-version-number MAJOR[:MINOR[:REVISION]]' If OUTPUT-FILE is a libtool library, compute interface version information so that the resulting library uses the specified major, minor and revision numbers. This is designed to permit libtool to be used with existing projects where identical version numbers are already used across operating systems. New projects should use the `-version-info' flag instead. === There are ten-year-old binaries that expect a particular SONAME for the X libraries and can't simply be rebuilt. It's very, very important that they not break. We're very much in agreement :-). Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Ekstrem Malzemelerin Ortak Platformu
Title: www.ExtShop.com Değerli Müşterilerimiz;www.extshop.com sanal mağzamız alternatif ve ekstrem ürünleri tek bir platform altında toplamak amacı ile kurulmuştur.Distribütörü olduğumuz ürünler ile satışa başladık ve birçok farklı sektörlerdeki diğer distribütörlerin desteğini alarak geniş ürün ağımıza sahip olduk.Her geçen gün ürün adedimiz ve farklı konulardaki malzemelerin sayfamıza eklenmesi devam etmektedir. Şu an sahip olduğumuz ana başlıklar; Sportif amaçlı dalış ekipmanları ve Optimist yelkenli teknesi, OKCULUK,DAĞCILIK,KIŞ KAYAK SPORLARI, TENİS gibi diğer spor melzeme ekipmanlarını mağzamızdan temin edebilirsiniz. 7 gün 24 saat alışveriş yapabileceğiniz www.extshop.com sitemiz eğer üye olursanız hem yeni gelen ürünlerimizden hemde olabilecek kampanyalarımızdan sizi haberdar eder ve tüm sitedeki ürünlerden toplam %1 üyelik indiriminden yararlanırsınız.Alışverişlerinizde havale ile ödeme seçeneğini kullanırsanız %5 havale indiriminden yararlanabilirsiniz.Yüz elli (150) YTL'nin üzerindeki siparişlerinizde taşıma tarafımızdan karşılanır.Eğer sipariş bedeliniz yüzelli yeni Türk Lirası'nın altında ise Türkiye'nin her bölgesine taşıma Sekiz yeni Türk Lirası Eli Kuruş (8.50) YTL KDV dahil taşıma ücreti faturanıza otamatik olarak yansıtılır.Taşıma UPS güvencesi ile yapılır.Saygılarımızlawww.extshop.com Daha detaylı bilgi için www.extshop.com web sitesine girebilirsiniz. Bu e-mail size piMailer programı kullanılarak gönderilmiştir. piMailer by performans ___ http://lists.gnu.org/mailman/listinfo/libtool
Ekstrem Malzemelerin Ortak Platformu
Title: www.ExtShop.com Değerli Müşterilerimiz;www.extshop.com sanal mağzamız alternatif ve ekstrem ürünleri tek bir platform altında toplamak amacı ile kurulmuştur.Distribütörü olduğumuz ürünler ile satışa başladık ve birçok farklı sektörlerdeki diğer distribütörlerin desteğini alarak geniş ürün ağımıza sahip olduk.Her geçen gün ürün adedimiz ve farklı konulardaki malzemelerin sayfamıza eklenmesi devam etmektedir. Şu an sahip olduğumuz ana başlıklar; Sportif amaçlı dalış ekipmanları ve Optimist yelkenli teknesi, OKCULUK,DAĞCILIK,KIŞ KAYAK SPORLARI, TENİS gibi diğer spor melzeme ekipmanlarını mağzamızdan temin edebilirsiniz. 7 gün 24 saat alışveriş yapabileceğiniz www.extshop.com sitemiz eğer üye olursanız hem yeni gelen ürünlerimizden hemde olabilecek kampanyalarımızdan sizi haberdar eder ve tüm sitedeki ürünlerden toplam %1 üyelik indiriminden yararlanırsınız.Alışverişlerinizde havale ile ödeme seçeneğini kullanırsanız %5 havale indiriminden yararlanabilirsiniz.Yüz elli (150) YTL'nin üzerindeki siparişlerinizde taşıma tarafımızdan karşılanır.Eğer sipariş bedeliniz yüzelli yeni Türk Lirası'nın altında ise Türkiye'nin her bölgesine taşıma Sekiz yeni Türk Lirası Eli Kuruş (8.50) YTL KDV dahil taşıma ücreti faturanıza otamatik olarak yansıtılır.Taşıma UPS güvencesi ile yapılır.Saygılarımızlawww.extshop.com Daha detaylı bilgi için www.extshop.com web sitesine girebilirsiniz. Bu e-mail size piMailer programı kullanılarak gönderilmiştir. piMailer by performans ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tracking a recursive macro
Hi Patrick, * Patrick Welche wrote on Thu, Jul 07, 2005 at 04:41:37PM CEST: On Wed, Jul 06, 2005 at 09:41:41PM +0200, Ralf Wildenhues wrote: Are you aware of the recent macro loop in CVS HEAD/branch-2-0 Libtool in conjunction with special Autoconf versions? /me checks it isn't 1 April... What, you think I'm trying to fool you? nope Which exact Autoconf/Automake/Libtool versions do you use (if CVS versions include `head ChangeLog`). autoconf of 5 July, automake and libtool of 4th. Should be fine. We hopefully fixed all of that before this. Any idea how I can start to track this down? Well, what I did was go back patches until I had the one, then go up and down macro calls and comment out random stuff to find out what's going on. Divide and conquer.. Here goes - a mere 2084 of configure.in.. Did you intend to also post something else here? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Keith == Keith Packard [EMAIL PROTECTED] writes: No, I haven't. I have little experience with these systems, so I don't even know if this scheme will work. Hence my question to this list where I imagine there are people with experience on those systems. The key question is whether the system uses SONAMES or filenames to locate libraries. Even if they do use file names to locate libraries, can't you continue to additionaly ship filenames matching the SONAMES? I mean having a symlink libXaw.so.6.0.0 - libXaw6.so.6.0.0. In fact, thinking further about the scenario you presented with version-less file names: === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6 Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7 Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw.so === Can't you just manually create and ship versioned .so file names? Like === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6, libXaw6.so Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7, libXaw7.so Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw8.so, libXaw.so === You need to create libXaw6.so - libXaw.so.6 links manually after libtool. This seems to be a simpler approach to tweaking the SONAMEs that libtool generates. Of course, I might still be missing something here, so I'll stop with this mail :-). And, of course, we actively discourage anyone from using any version of Xaw; it's a terrible library. Then why make this any easier ;-). What's wrong with the current scheme of not shipping .so symlinks with the library but shipping them in a -dev package, one for each library major version? The -dev packages do conflict with each other. This already makes it possible, if not easy, to link to older libraries for some one who really cares. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi, Keith Packard wrote: I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so There is no need to name the real file libXaw6.so.6.0.1, as the 6 is mentioned twice this way (libXaw.so.6.0.1 suffices). The unversioned symlink and the .la file are the only things that conflict between versions; I'd think that there is some sort of a current ABI which would get its symlink/.la installed. Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as -old-abi. Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi Keith, * Keith Packard wrote on Fri, Jul 08, 2005 at 08:47:37AM CEST: On Fri, 2005-07-08 at 08:31 +0200, Ralf Wildenhues wrote: First, to stay with your GNU/Linux example, unless you also have libXaw.so.6 as symlink, how will ld.so find your library (as installed library; or alternatively as user-installed test version below $HOME)? The current ELF shared library mechanism in glibc uses SONAMEs exclusively when locating libraries. The filename is irrelevant. No. If a DSO with matching SONAME is already mapped, ld.so is done. If not, it searches for a library with a file name which matches the SONAME, unless the SONAME - file name pair is listed in /etc/ld.so.cache. That's why I asked how you would work with uninstalled or user-installed (for testing) libraries. Please note that ldconfig -n sets the appropriate symlinks which contain the SONAMEd file name if not present. So, you'd end up with libXaw6.la, and libXaw6.so.6.0.1 libXaw6.so.6 libXaw6.so libXaw.so.6 all pointing to the same file. I might still have completely misunderstood you here -- please correct me if I'm wrong. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
* Ralf Wildenhues wrote on Fri, Jul 08, 2005 at 04:15:53PM CEST: Keith, could you confirm that this would be enough for your needs, when given as install mode switch? Current idea would be to have it install the first name from library_names only, do not delete the symlinks nor s/the first name/all but the last name, in case there are several names/ create new ones, do not install the .la file. Sorry, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
FYI: libtool 2.1a failed mdemo-make.test on Solaris
* Ralf Wildenhues wrote on Thu, Jun 23, 2005 at 12:25:01PM CEST: * Sven Verdoolaege wrote on Thu, Jun 23, 2005 at 09:11:36AM CEST: On Thu, Jun 23, 2005 at 08:31:48AM +0200, Ralf Wildenhues wrote: It's this version that fails on solaris. Let's see: ls libltdl/argz.h created by running `make' in $top_builddir? Yes. I ran make check without a make first. This seems to work on Linux... Yes, but that works only because GNU/Linux has argz.h. Running make first makes tests/mdemo-make.test pass on Solaris. Ah, ok. Thanks for this report. It's a bit tricky to reproduce: You need a system which has no argz.h, then configure, then `make check' without prior make. If you had ever run `make' before in this build tree, even after `make clean' the dependency information is stored in libltdl/.deps/*.Plo, and thus hides this bug. Now the gnulib snippet in libltdl/Makefile.am leaves us with the possibility of using the lib_OBJECTS variable to fix this(?). OK, nobody from the other two lists responded, so I am doing a different fix which does not depend on undocumented features (and seems cleaner as well). I have applied this patch to HEAD and branch-2-0 (does not apply to branch-1-5). Cheers, Ralf * libltdl/Makefile.am (libltdl_la_DEPENDENCIES): Depend on $(BUILT_SOURCES) as well, so that argz.h gets created through `make libltdlc.la'. Reported by Sven Verdoolaege [EMAIL PROTECTED]. Index: libltdl/Makefile.am === RCS file: /cvsroot/libtool/libtool/libltdl/Makefile.am,v retrieving revision 1.80 diff -u -r1.80 Makefile.am --- libltdl/Makefile.am 22 Apr 2005 10:10:30 - 1.80 +++ libltdl/Makefile.am 8 Jul 2005 16:14:47 - @@ -63,7 +63,7 @@ libltdl_la_CPPFLAGS= -DLTDLOPEN=libltdl $(AM_CPPFLAGS) libltdl_la_LDFLAGS = $(AM_LDFLAGS) $(VERSION_INFO) $(LT_DLPREOPEN) libltdl_la_LIBADD = $(LTLIBOBJS) -libltdl_la_DEPENDENCIES= $(LT_DLLOADERS) $(LTLIBOBJS) +libltdl_la_DEPENDENCIES= $(LT_DLLOADERS) $(LTLIBOBJS) $(BUILT_SOURCES) libltdlc_la_SOURCES= $(libltdl_la_SOURCES) libltdlc_la_CPPFLAGS = -DLTDLOPEN=libltdlc $(AM_CPPFLAGS) ___ http://lists.gnu.org/mailman/listinfo/libtool
how to use circular dependencies
Hi all, I'm trying to get libtool to link a program that depends on a circular list of static (libtool) libraries. I'm using a command line like: ../../libtool --mode=link --preserve-dup-deps g77 -Wall -I../include -O0 -o partrj -static *.o ../ui/libParTrjUI.la ../models/libSPPModels.la ../share/libSPPShare.la ../models/libSPPModels.la ../grid/libSPPgrid.la ../fields/libSPPFields.la ../share/libSPPShare.la ../menus/libParTrjMenu.la ../strings/src/libSPPStrings.la ../hash/libHash.la ../dbg/libSPPdbg.la ../t89files/libSPPt89.la unfortunately this ends up not working because libtool is removing/reordering some of the libraries: g77 -Wall -I../include -O0 -o partrj bunch of .o files ../ui/.libs/libParTrjUI.a ../models/.libs/libSPPModels.a ../grid/.libs/libSPPgrid.a ../fields/.libs/libSPPFields.a ../share/.libs/libSPPShare.a ../menus/.libs/libParTrjMenu.a ../strings/src/.libs/libSPPStrings.a ../hash/.libs/libHash.a ../dbg/.libs/libSPPdbg.a ../t89files/.libs/libSPPt89.a --preserve-dup-deps doesn't seem to have an effect. I also tried remaking the command line using -L and -l options instead of explicitly specifying the .la file, with the same effect of libtool stripping out libraries from the link line. I found a post on libtool-patches from 2002, where someone else had run into this issue. They expected linker flags of -Wl,-( libs -Wl,-) to fix it. I changed my link line above to use these linker flags in the libtool command line, but I still get the same error. It appears as if the patch was never applied (why?)? I am using libtool version '1.5.18 (1.1220.2.246 2005/05/16 10:00:18'. What am I doing wrong? How can one link in circular dependencies using libtool? Thanks, -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Thu, Jul 07, 2005 at 05:02:26PM -0500, Tim Mooney wrote: In regard to: Re: FYI: ksh bug on Tru64 UNIX causes current libtool...: * Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: This is a gentle reminder that this issue with Libtool HEAD/branch-2-0 on Tru64 sh is still unsolved. It'd be nice to get a solution into the next 2.0 release candidate, should such a solution exist. Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one does. I.e., does echo Xbla | sed 1s,^X,, work there? (Libtool currently does not quote this consistently.) I haven't seen any responses to this, so I will: it does need it quoted: 05:00 PM dogbert ~$PS1='$ ' /bin/sh $ echo Xbla | sed 1s,^X,, X,,: not found $ sed: Function 1s, cannot be parsed. What system is this? Works fine on 4.0D and 5.1. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 14:10 +0530, Ganesan Rajagopal wrote: Keith == Keith Packard [EMAIL PROTECTED] writes: No, I haven't. I have little experience with these systems, so I don't even know if this scheme will work. Hence my question to this list where I imagine there are people with experience on those systems. The key question is whether the system uses SONAMES or filenames to locate libraries. Even if they do use file names to locate libraries, can't you continue to additionaly ship filenames matching the SONAMES? I mean having a symlink libXaw.so.6.0.0 - libXaw6.so.6.0.0. Yes, that is one possibility. It complicates the install process as libtool always wants to install the bare .so version of the file (libXaw.so), and this would give us three potential versions of that file, depending on which library you happened to install last. Plus, it means I can use automake to construct these libraries in the same directory, which is obviously not a huge deal. There are also packaging systems which dislike having multiple major versions of the same library installed at the same time. Gtk+, in particular, appends '-2.0' to every library name precisely to avoid this particular issue. We wanted to take advantage of distinct filenames for all packages. In fact, thinking further about the scenario you presented with version-less file names: === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6 Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7 Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw.so === Can't you just manually create and ship versioned .so file names? Like === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6, libXaw6.so Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7, libXaw7.so Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw8.so, libXaw.so === You need to create libXaw6.so - libXaw.so.6 links manually after libtool. This seems to be a simpler approach to tweaking the SONAMEs that libtool generates. Of course, I might still be missing something here, so I'll stop with this mail :-). This is actually harder than it seems as I wouldn't be able to use libtool to install the library, and automake really doesn't want you to avoid that. I can't fix things up after the fact as the bare libXaw.so would be trashed by the libtool install step. And, of course, we actively discourage anyone from using any version of Xaw; it's a terrible library. Then why make this any easier ;-). What's wrong with the current scheme of not shipping .so symlinks with the library but shipping them in a -dev package, one for each library major version? The install process for the packages isn't really a problem; rather it's the automake install process which doesn't provide this distinction. The -dev packages do conflict with each other. This already makes it possible, if not easy, to link to older libraries for some one who really cares. Sure, but some packging systems (RPM?) don't even like run-time packages to share the same library name with different major so versions. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 14:07 +0200, Ralf Wildenhues wrote: No. If a DSO with matching SONAME is already mapped, ld.so is done. If not, it searches for a library with a file name which matches the SONAME, unless the SONAME - file name pair is listed in /etc/ld.so.cache. Sure, but the SONAME still has to be right, so I can't build libXaw6.so.6.0.1 with SONAME libXaw6.so.6, symlink it to libXaw.so.6 and expect applications asking for libXaw.so.6 to work. Which means that with current libtool, I must ask it to build libXaw.so.6 and then link that to libXaw6.so.6, which I also can't do as that will trash any libXaw.so when libtool installs the library. I don't mind getting libtool to build libXaw.so.6, but I can't ask libtool to *install* a libXaw.la that points at that file. Thanks for reminding me that the filename is still relevant for libraries not in ld.so.cache; I'll have to make sure I create the links at install time. Of course, if we do hack libtool to support alternate SONAME values, we could also hack it to manage these symlinks for us. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 16:15 +0200, Ralf Wildenhues wrote: Keith, could you confirm that this would be enough for your needs, when given as install mode switch? Current idea would be to have it install the first name from library_names only, do not delete the symlinks nor create new ones, do not install the .la file. As mentioned previously, I actually do need multiple unversioned .so files installed at the same time... Or do you also need to prevent creating the symlinks in the build tree (below $builddir/.libs/), maybe because you actually build all three library major versions in the same directory? Then we'd need to do something at link mode. Oh, I don't care about this; I can construct parallel directories if necessary (there actually were parallel directories a few days ago as the library was autotooled by people unfamiliar with the *_la_CFLAGS behaviour of automake) -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 11:23 +0200, Simon Richter wrote: Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as -old-abi. I have to support two of these library versions as 'current' for other reasons, so applications need to be able to link against either libXaw7 or libXaw8 at build time, so I need two unversioned .so files... You see, libXaw8 includes XPrint support, which is not universally loved by the X community, so applications not interested in printing shoud link against libXaw7 as libXaw8 is not present on most Linux systems. Yes, there are probably too many constraints on the solution space. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
