$B%O%8%a%^%7%F(B
$B40A4L5NA$G5.J}$N=P2q$$$r%5%]!%H$7$^$9!#(B [EMAIL PROTECTED][EMAIL PROTECTED](B $BEPO?NA!G/2qHq!%a!%k$N$d$j$H$j!L??1\Mw!7G(HD1\Mw!(B $BA4$F$,L5NA$G$*3Z$7$_D:$1$^$9!#(B $B=P2q$$$,%9%`!%:$K?J$a$i$l$kMM!CO0h!%W%m%U%#!%k$+$i$*Ajj(B $B$r8!:w$G$-$k5!G=$rEk:\$7$^$7$?!#%9%?!%H;~$K$4+J,$N2q$$$?$$(B $B%(%j%[EMAIL PROTECTED](BOK$B!#(B http://ya2.ya2dic.com?num=0001 $B2H$d2qR$N6a$/$K$$$k?M$r4JC1$K8+$D$1$i$l$k$N$G!%j%%k%?%$%`(B $B$G9b3NN($N=P2q$$$r(BGET$B$G$-$^$9!#(B $B$b$A$m$sL%a!%kBP1~$bBP1~$7$^$9!#(B $BEPO?$O$o$:$+#3#0IC$GD64JC1!*(B $BEv%5![EMAIL PROTECTED]K\5$$G=P2q$$$r5a$a$k(B $BJ}$N$?$a$N8rN.%5%$%H$G$9!#(B http://ya2.ya2dic.com?num=0001 $B!z(BPC$B!7HBS$I$A$i$+$i$G$bEv%5!%S%9$rL5NA$G$4MxMQ$G$-$^$9!#(B $B!zL%a!%k$b;HMQ$G$-$^$9$N$G!%3%_%e%K%1!%7%g%s$,$h$j1_3j$Kh$l$^$9!#(B $B!z40`z$J%W%i%$%P%7!4IM}!J]8n$N0BA4BP:v$r9T$C$F$*$j$^$9!#(B
Re: BUG: libtool-1.9f and libtool-1.5.18: install: you must specify a destination
Hi Juergen, * 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. Acknowledged. As one can see, there has been given a destination, so it is not the fault of automake/autoconf/make, because it is pretty much legitimate to use both cp -f and install -c. The reason for this error is, that the -f of cp does NOT expect any further arguments, as opposed to bsd's install. cp -f rather means force and enforces overwriting of any existing files. This is at least true for both of the versions of cp under linux (fileutils-4.1) and under freebsd-4.6 (and under irix, iirc). Therefore libtool's treatment of -f in func_mode_install with cp MUST NOT be prev=-f However, at least bsd's install does know the option -f (opposedly to the install used under linux) and does require further arguments. So a short distinction will be necessary. My workaround for this is in libtool (around line 2442) rsp. ltmain.sh (line 2053) in func_mode_install (): *snip* Thanks for this report. Unless anyone opposes, I will install this slightly different fix, which also cleans up install mode a bit. Failure might basically occur for a coreutils-like package, were that to use libtool and also install a program named `cp'. Regards, Ralf Proposed patch (against HEAD, similar for backport): * 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 6 Jul 2005 16:59:08 - @@ -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. @@ -1719,10 +1719,17 @@ case $arg in -d) isdir=yes ;; - -f) prev=-f ;; - -g) prev=-g ;; - -m) prev=-m ;; - -o) prev=-o ;; + -f) + case $install_prog in + * cp * | */cp *) + prev= ;; + *) + prev=$arg ;; + esac + ;; + -g | -m | -o) + prev=$arg + ;; -s) stripme= -s continue @@ -1734,7 +1741,7 @@ if test -n $prev; then prev= else - dest=$arg + dest=$arg continue fi ;;
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* 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.) Regards, Ralf
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
tracking a recursive macro
I don't really know where to ask for help: trying libtool as the last
macro mentioned is an autoconf fixup for libtool..
I'm trying to build apr with cvs autotools, and essentially do
libtoolize
sinclude(build/{libtool,ltsugar,ltversion,ltoptsion,argz}.m4) in configure.in
(instead of aclocal - AC_PROG_LIBTOOL is in configure.in)
autoheader
autoconf
but at the autoheader stage
autom4te: running: /usr/local/bin/gm4 --nesting-limit=1024
--include=/usr/local/share/autoconf
...
configure.in:2084: /usr/local/bin/gm4: ERROR: Recursion limit of 1024 exceeded,
use -LN to change it
Now, that is the AC_OUTPUT line, and the last thing to appear in
autom4te.cache/traces.0t is
m4trace:configure.in:2084: -1- AC_SUBST([LIB@[EMAIL PROTECTED], [$ac_libobjs])
m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LIB@[EMAIL PROTECTED])
m4trace:configure.in:2084: -1- m4_pattern_allow([^LIB@[EMAIL PROTECTED])
m4trace:configure.in:2084: -1- AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs])
m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LTLIBOBJS])
m4trace:configure.in:2084: -1- m4_pattern_allow([^LTLIBOBJS$])
which is from AC_OUTPUT - AC_OUTPUT_COMMANDS_PRE
# _AC_LIBOBJS_NORMALIZE
# -
# Clean up LIBOBJS and LTLIBOBJS so that they work with 1. ac_objext,
# 2. Automake's ANSI2KNR, 3. Libtool, 4. combination of the three.
# Used with AC_CONFIG_COMMANDS_PRE.
AC_DEFUN([_AC_LIBOBJS_NORMALIZE],
[ac_libobjs=
ac_ltlibobjs=
for ac_i in : $LIB@[EMAIL PROTECTED]; do test x$ac_i = x: continue
# 1. Remove the extension, and $U if already installed.
ac_script='s/\$U\././;s/\.o$//;s/\.obj$//'
ac_i=`echo $ac_i | sed $ac_script`
# 2. Prepend LIBOBJDIR. When used with automake=1.10 LIBOBJDIR
#will be set to the directory where LIBOBJS objects are built.
ac_libobjs=$ac_libobjs \${LIBOBJDIR}$ac_i\$U.$ac_objext
ac_ltlibobjs=$ac_ltlibobjs \${LIBOBJDIR}$ac_i'$U.lo'
done
AC_SUBST([LIB@[EMAIL PROTECTED], [$ac_libobjs])
AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs])
])
Any idea how I can start to track this down?
Cheers,
Patrick
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: tracking a recursive macro
Hi Patrick,
* Patrick Welche wrote on Wed, Jul 06, 2005 at 09:19:52PM CEST:
I don't really know where to ask for help: trying libtool as the last
macro mentioned is an autoconf fixup for libtool..
I'm trying to build apr with cvs autotools, and essentially do
libtoolize
sinclude(build/{libtool,ltsugar,ltversion,ltoptsion,argz}.m4) in
configure.in
(instead of aclocal - AC_PROG_LIBTOOL is in configure.in)
autoheader
autoconf
but at the autoheader stage
autom4te: running: /usr/local/bin/gm4 --nesting-limit=1024
--include=/usr/local/share/autoconf
...
configure.in:2084: /usr/local/bin/gm4: ERROR: Recursion limit of 1024
exceeded, use -LN to change it
Are you aware of the recent macro loop in CVS HEAD/branch-2-0 Libtool in
conjunction with special Autoconf versions?
Which exact Autoconf/Automake/Libtool versions do you use (if CVS
versions include `head ChangeLog`).
Now, that is the AC_OUTPUT line, and the last thing to appear in
autom4te.cache/traces.0t is
m4trace:configure.in:2084: -1- AC_SUBST([LIB@[EMAIL PROTECTED],
[$ac_libobjs])
m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LIB@[EMAIL PROTECTED])
m4trace:configure.in:2084: -1- m4_pattern_allow([^LIB@[EMAIL PROTECTED])
m4trace:configure.in:2084: -1- AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs])
m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LTLIBOBJS])
m4trace:configure.in:2084: -1- m4_pattern_allow([^LTLIBOBJS$])
which is from AC_OUTPUT - AC_OUTPUT_COMMANDS_PRE
# _AC_LIBOBJS_NORMALIZE
# -
# Clean up LIBOBJS and LTLIBOBJS so that they work with 1. ac_objext,
# 2. Automake's ANSI2KNR, 3. Libtool, 4. combination of the three.
# Used with AC_CONFIG_COMMANDS_PRE.
AC_DEFUN([_AC_LIBOBJS_NORMALIZE],
[ac_libobjs=
ac_ltlibobjs=
for ac_i in : $LIB@[EMAIL PROTECTED]; do test x$ac_i = x: continue
# 1. Remove the extension, and $U if already installed.
ac_script='s/\$U\././;s/\.o$//;s/\.obj$//'
ac_i=`echo $ac_i | sed $ac_script`
# 2. Prepend LIBOBJDIR. When used with automake=1.10 LIBOBJDIR
#will be set to the directory where LIBOBJS objects are built.
ac_libobjs=$ac_libobjs \${LIBOBJDIR}$ac_i\$U.$ac_objext
ac_ltlibobjs=$ac_ltlibobjs \${LIBOBJDIR}$ac_i'$U.lo'
done
AC_SUBST([LIB@[EMAIL PROTECTED], [$ac_libobjs])
AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs])
])
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. Then I reported that I was stuck and Ralf Menzel came up with a
fix (actually he tracked it down too, mostly). :)
No, seriously, post something reproducible. Someone will know..
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* 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.) Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
$B=PMh$A$c$C$?$N(B
$B!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y(B $B!y!z(B $B!zL5NA$N=P2q$$7O$,=PMh$A$c$C$?$N!!!y(B $B!y!z(B $B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B $B!!A4$/$NL5NA$J$N$GEPO?$7$F$h!(B $B!!(B http://www.ya2dic.com?num=2001 $B!!(B $B$_$s$J$GEPO?$7$J$$$H3Z$7$a$J$$$h!(B $B!%(%s%H%j!EPO?!!(BFREE$B!*(B $B!%W%m%U1\Mw!!(BFREE$B!*(B $B!%a!%kAwu?.!!(BFREE$B!*(B $B!L%a1\Mw!7G:\!!(BFREE$B!*(B $B!!(B http://www.ya2dic.com?num=2001 $B%(%C%A$J;R!!%m%j$J;R!!G($l$F$k;R!!A40w=89g!*(B $B(;HMQ$7$F$$$k$$A$K2]6bH/@8$J$s$F$3$H$O$$j$^$;$s!*(B $B!!$:$C$HL5NA$G$4MxMQ$K$J$l$^$9!*(B ___ http://lists.gnu.org/mailman/listinfo/libtool
