Re: [png-mng-implement] -version-number and BeOS
Hi John, * John Bowler wrote on Wed, May 17, 2006 at 04:17:21AM CEST: > From: Ralf Wildenhues > >What I still don't understand is the following additional change you > >also suggest: > > > >> $ diff libpng-1.2.9beta7/ltmain.sh libpng-1.2.9beta11 3248c3248 > >> < current=`expr $number_major + $number_minor - 1` > >> --- > >> > current=`expr $number_major + $number_minor` > >> 3323c3323 > >> < major=`expr $current - $age + 1` > >> --- > >> > major=`expr $current - $age` > > > >There is a comment above this code that explains why this should be >> necessary, no? > > This is the irix/nonstopux case, I don't think there is any comment; I > wasn't able to find any explanation of why the irix case adds 1 to get > the major version number. I did notice the comment for the first case > which says: > > 'then there is irix which has an extra 1 added just for fun' AFAIK IRIX doesn't or at one point in time didn't allow for a major version number of 0. That's why Libtool always added 1: because version numbers of 0 are commonly used elsewhere, so it wouldn't be nice to force everyone else to adjust. > That's clearly a reference to the second case adding of 1, not a > reference to whatever irix behaviour the second piece of code is trying > to accommodate. > > The issue here is that libpng on irix has (currently) a major version > number of '0', as it does on all other operating systems. Why should the version number be constant across operating systems? This is a requirement that is impossible to fulfill portably. I fully understand that the maintenance hassles incurred by this limitations: explaining to users that their libfoo 1.2.3 has different numbers 4.5.6 elsewhere; but fundamentally, it simply isn't possible to generate a uniform numbering scheme. > So we need to be able to set the major version number to 0 (currently > impossible because ltmain.sh objects to the value of '-1' for current) > and, ideally we don't want to do OS specific stuff in configure to fix > up the arguments to libtool for irix... That would defeat the point > of libtool. Well, the point of libtool is that you give it the same version information for all systems, and that it will map that to some version representation that keeps the semantics w.r.t. compatible and incompatible changes right. A library on IRIX need not be compatible with a library on GNU/Linux: they will never be linked together. > Well, there is obviously something weird going on on IRIX. libpng has > worked on IRIX for a long time, but maybe not with shared libraries. > Still it seems weird that libtool should make a major version number > of 0 impossible and not offer any explanation of what is going on. Good point. We should document this somewhere, after clarifying where exactly the constraint came from and whether it still applies. Cheers, Ralf
Re: HEAD link-order.at fails when hardcode_direct=yes
On Tue, Apr 25, 2006 at 02:55:09PM -0500, Albert Chin wrote: > On systems with hardcode_direct=yes, the following section in > tests/link-order.at will fail: > AT_CHECK([if $EGREP relinking stderr; then > $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout > else :; fi], [0], [ignore], [], [echo "wrong link order"]) > > Why? Because "-L.*\/new\/lib -lb" will be converted to > .*\/new\/lib/liblb$shrext_cmds. > > Patch attached. Note, the new RE doesn't fully address what you > intended. The original libtool output: > libtool: install: warning: relinking `src/liba.la' > stdout: > libtool: install: (cd /opt/build/libtool/tests/testsuite.dir/14; /bin/sh > /opt/build/libtool/libtool --mode=relink cc -z +O2 +Olit=all +Onofltacc > +Oentrysched +Odataprefetch +Onolimit -no-undefined -o src/liba.la src/a.lo > src/libb.la -L/opt/build/libtool/tests/testsuite.dir/14/old/lib -lcee -rpath > /opt/build/libtool/tests/testsuite.dir/14/new/lib ) > libtool: relink: cc -b -Wl,+h -Wl,liba.sl.0 -Wl,+b > -Wl,/opt/build/libtool/tests/testsuite.dir/14/new/lib -o > src/.libs/liba.sl.0.0 src/.libs/a.o > /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl > -L/opt/build/libtool/tests/testsuite.dir/14/old/lib > /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl -lc > > Note the link order above is: > /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl > -L/opt/build/libtool/tests/testsuite.dir/14/old/lib > /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl > rather than what you probably want: > /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl > /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl > > But the ".*" pattern sucks up the > "-L/opt/build/libtool/tests/testsuite.dir/14/old/lib". Updated patch for new hardcode_direct_static variable: http://lists.gnu.org/archive/html/libtool-patches/2006-05/msg00018.html Patch against HEAD. 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/link-order.at: Take hardcode_direct and hardcode_direct_static into consideration when testing link order. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.9 diff -u -p -r1.9 link-order.at --- tests/link-order.at 5 Feb 2006 09:56:44 - 1.9 +++ tests/link-order.at 17 May 2006 00:58:16 - @@ -20,6 +20,7 @@ AT_SETUP([Link order test.]) AT_KEYWORDS([libtool]) +eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|hardcode_direct_static|shrext_cmds)='` LDFLAGS="$LDFLAGS -no-undefined" prefix_old=`pwd`/old @@ -68,10 +69,18 @@ case $host_os in aix* | interix*) ;; # These systems have different path syntax *) # Do not error if we do not relink (e.g. static-only systems) - AT_CHECK([if $EGREP relinking stderr; then - $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout - else :; fi], [0], [ignore], [], [echo "wrong link order"]) - ;; + case $hardcode_direct$hardcode_direct_static in + yesno) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; + *) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " -L.*\/new\/lib -lb -L.*\/old\/lib -lcee" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; + esac esac for i in old new; do
Re: LT_AC_PROG_SED
Ralf Wildenhues wrote: Hi Gary, Hi Ralf! Sorry for the long delay. * Gary V. Vaughan wrote on Fri, Feb 10, 2006 at 11:52:04AM CET: > Okay to commit? Comments inline. Please note my comments are completely untested, so please take them with a grain of salt. ACK. I think these patches are still worth applying, but for the small changes described below. Any objections? Index: ChangeLog from Gary V. Vaughan <[EMAIL PROTECTED]> * libtool.m4 (LT_AC_PROG_SED): Rename to AC_PROG_SED and only define if autoconf failed to provide a definition. AC_SUBST([SED]) for compatibility with future autoconf release of AC_PROG_SED. Provide an autoupdate alias to LT_AC_PROG_SED for projects that used this undocumented macro. Index: libtool-1-5/libtool.m4 === --- libtool-1-5.orig/libtool.m4 +++ libtool-1-5/libtool.m4 @@ -5987,17 +5987,15 @@ AC_DEFUN([LT_AC_PROG_RC], [AC_CHECK_TOOL(RC, windres, no) ]) +m4_ifndef([AC_PROG_SED], [ # NOTE: This macro has been submitted for inclusion into # # GNU Autoconf as AC_PROG_SED. When it is available in # # a released version of Autoconf we should remove this# # macro and use it instead. # -# LT_AC_PROG_SED -# -- -# Check for a fully-functional sed program, that truncates -# as few characters as possible. Prefer GNU sed if found. -AC_DEFUN([LT_AC_PROG_SED], + +AC_DEFUN([AC_PROG_SED], With old aclocal, this will pull in libtool.m4 for users of AC_PROG_SED. This is definitely not ok. The offending line should, of course, read: `m4_defun([AC_PROG_SED], [' [AC_MSG_CHECKING([for a sed that does not truncate output]) AC_CACHE_VAL(lt_cv_path_SED, [# Loop through the user's path and test for sed and gsed. @@ -6047,5 +6045,13 @@ for lt_ac_sed in $lt_ac_sed_list /usr/xp done ]) SED=$lt_cv_path_SED +AC_SUBST([SED]) AC_MSG_RESULT([$SED]) -]) +])#AC_PROG_SED +])#m4_ifndef + +# Old name: +AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED]) +dnl aclocal-1.4 backwards compatibility: +dnl AC_DEFUN([LT_AC_PROG_SED], []) + With old aclocal, this will pull in libtool.m4 for users of LT_AC_PROG_SED. Yes, and they'll need it to get that LT_AC_PROG_SED expanded correctly! That may actually be ok for them, but it won't do what you want: forward compatiblity plus automatic independence of libtool.m4 without user changes, as soon as autoconf-2.60 is out. Right? Ah, maybe you rather want users to switch to AC_PROG_SED, but help them with the autoupdate note? Yes. LT_AC_PROG_SED was never documented, although unfortunately is in use nevertheless. If they don't autoupdate, the AU_ALIAS will get them autoconf's AC_PROG_SED if autoconf is new enough or else our m4_defun replacement. If they are already using AC_PROG_SED (presumably from autoconf), even old aclocal won't pull in libtool.m4 just for LT_AC_PROG_SED. There is still the problem with pulling in an old installed libtool.m4 with an `AC_DEFUN([LT_AC_PROG_SED], [' declaration... but we don't address that problem in branch-1-5 for any other macros at the moment either. Index: ChangeLog from Gary V. Vaughan <[EMAIL PROTECTED]> * libltdl/m4/lt~obsolete (LT_AC_PROG_SED): Removed in favour of... * libltdl/m4/libtool.m4 (LT_AC_PROG_SED): Declarations for compatibility with old versions of libtool, and old versions of aclocal. Index: libtool-HEAD/libltdl/m4/libtool.m4 === --- libtool-HEAD.orig/libltdl/m4/libtool.m4 +++ libtool-HEAD/libltdl/m4/libtool.m4 @@ -6758,6 +6758,11 @@ AC_MSG_RESULT([$SED]) ])#AC_PROG_SED ])#m4_ifndef +# Old name: +AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED]) Is it allowed to AU_ALIAS a macro that is not AC_DEFUN'ed? (I just changed AC_PROG_SED to be m4_defun'ed, not AC_DEFUN'ed). I can't find any reason why not. Both autoupdate and autoconf do the right thing here (I didn't test with ancient autotools though). +dnl aclocal-1.4 backwards compatibility: +dnl AC_DEFUN([LT_AC_PROG_SED], []) With old aclocal, this will pull in libtool.m4 for users of LT_AC_PROG_SED. See above. # _LT_CHECK_XSI_SHELL # --- Index: libtool-HEAD/libltdl/m4/lt~obsolete.m4 === --- libtool-HEAD.orig/libltdl/m4/lt~obsolete.m4 +++ libtool-HEAD/libltdl/m4/lt~obsolete.m4 @@ -58,7 +58,6 @@ m4_ifndef([AC_LIBTOOL_PROG_COMPILER_PIC] m4_ifndef([AC_LIBTOOL_PROG_LD_SHLIBS], [AU_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS])]) m4_ifndef([AC_LIBTOOL_POSTDEP_PREDEP], [AU_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP])]) m4_ifndef([LT_AC_PROG_EGREP], [AU_DEFUN([LT_AC_PROG_EGREP])]) -m4_ifndef([LT_AC_PROG_SED],[AU_DEFUN([LT_AC_PROG_SED])]) Doing this will pull in an older also-installed
Re: HEAD link-order.at fails when hardcode_direct=yes
Hi Albert, Albert Chin wrote: Updated patch for new hardcode_direct_static variable: http://lists.gnu.org/archive/html/libtool-patches/2006-05/msg00018.html Patch against HEAD. 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/link-order.at: Take hardcode_direct and hardcode_direct_static into consideration when testing link order. Thanks. Applied both this change and the linked patch. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: LT_AC_PROG_SED
Hi Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 03:21:48PM CEST: > > Sorry for the long delay. Don't worry. My latency has been just as long; the backlog is still large, and it will take a while for me to wade through it... > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Fri, Feb 10, 2006 at 11:52:04AM CET: > >> Okay to commit? > > > >Comments inline. Please note my comments are completely untested, > >so please take them with a grain of salt. > > ACK. I think these patches are still worth applying, but for the small > changes described below. Any objections? Comments below. > >>+# Old name: > >>+AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED]) > >>+dnl aclocal-1.4 backwards compatibility: > >>+dnl AC_DEFUN([LT_AC_PROG_SED], []) > >>+ > > > >With old aclocal, this will pull in libtool.m4 for users of > >LT_AC_PROG_SED. > > Yes, and they'll need it to get that LT_AC_PROG_SED expanded correctly! Right. Dummy me. > >That may actually be ok for them, but it won't do what you want: > >forward compatiblity plus automatic independence of libtool.m4 > >without user changes, as soon as autoconf-2.60 is out. Right? > > > >Ah, maybe you rather want users to switch to AC_PROG_SED, but > >help them with the autoupdate note? > > Yes. LT_AC_PROG_SED was never documented, although unfortunately > is in use nevertheless. If they don't autoupdate, the AU_ALIAS > will get them autoconf's AC_PROG_SED if autoconf is new enough or else > our m4_defun replacement. If they are already using AC_PROG_SED > (presumably from autoconf), even old aclocal won't pull in libtool.m4 > just for LT_AC_PROG_SED. > > There is still the problem with pulling in an old installed libtool.m4 > with an `AC_DEFUN([LT_AC_PROG_SED], [' declaration... but we don't > address that problem in branch-1-5 for any other macros at the moment > either. Aahh. That's why you can't change the branch-1-5 version from AC_DEFUN([LT_AC_PROG_SED], ...) to m4_defun([LT_AC_PROG_SED], ...) now: if the user has 1.5.24's libtool.m4 and 1.5.22's libtool.m4 both in aclocal's search path, both will be pulled in. Yuck. General rule: within the branch-1-5 branch, you cannot ever remove an AC_DEFUNed name. Not. ever. > >> > >>+# Old name: > >>+AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED]) > > > >Is it allowed to AU_ALIAS a macro that is not AC_DEFUN'ed? > >(I just changed AC_PROG_SED to be m4_defun'ed, not AC_DEFUN'ed). > > I can't find any reason why not. Both autoupdate and autoconf do > the right thing here (I didn't test with ancient autotools though). OK. > >>+dnl aclocal-1.4 backwards compatibility: > >>+dnl AC_DEFUN([LT_AC_PROG_SED], []) > > > >With old aclocal, this will pull in libtool.m4 for users of > >LT_AC_PROG_SED. > > See above. OK. > >>Index: libtool-HEAD/libltdl/m4/lt~obsolete.m4 > >>=== > >>--- libtool-HEAD.orig/libltdl/m4/lt~obsolete.m4 > >>+++ libtool-HEAD/libltdl/m4/lt~obsolete.m4 > >>@@ -58,7 +58,6 @@ m4_ifndef([AC_LIBTOOL_PROG_COMPILER_PIC] > >>m4_ifndef([AC_LIBTOOL_PROG_LD_SHLIBS], > >>[AU_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS])]) > >>m4_ifndef([AC_LIBTOOL_POSTDEP_PREDEP], > >>[AU_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP])]) > >>m4_ifndef([LT_AC_PROG_EGREP],[AU_DEFUN([LT_AC_PROG_EGREP])]) > >>-m4_ifndef([LT_AC_PROG_SED],[AU_DEFUN([LT_AC_PROG_SED])]) > > > > > >Doing this will pull in an older also-installed libtool.m4: some > >aclocal versions will not fall for the 1.4 hack above but still won't > >see the AU_ALIAS. Actually, AU_ALIAS isn't matched before 1.9.5. > > Good point. The lt~obsolete.m4 part of the patch is wrong, I don't want > to apply that part now. Fine. You can add the AC_SUBST to branch-1-5, but you cannot AU_ALIAS there, and you cannot AC_DEFUN([AC_PROG_SED]) there. So IMHO best to leave branch-1-5 as is otherwise. Iff you want to add AC_PROG_SED, then probably best to m4_defun([AC_PROG_SED], ...) AC_DEFUN([LT_AC_PROG_SED], [AC_DIAGNOSE([obsolete], [...])dnl AC_PROG_SED]) so that you avoid the backward compatibility traps of both an AU_DEFUNed or AU_ALIASed LT_AC_PROG_SED (untested BTW). The HEAD patch is fine without the lt~obsolete change and with LT_AC_PROG_SED. Cheers, Ralf
Re: HEAD link-order.at fails when hardcode_direct=yes
Hi Albert, Gary, * Albert Chin wrote on Wed, May 17, 2006 at 02:44:49PM CEST: > > + case $hardcode_direct$hardcode_direct_static in > + yesno) > +AT_CHECK([if $EGREP relinking stderr; then > + $EGREP " .*\/new\/lib/libb$shrext_cmds > .*\/old\/lib/libcee$shrext_cmds" stdout > + else :; fi], [0], [ignore], [], [echo "wrong link order"]) > +;; You shouldn't grep for $shrext_cmds. It's called *_cmds because it may contain commands. The right way is to module=no eval shared_ext=\"$shrext_cmds\" * Gary V. Vaughan wrote on Wed, May 17, 2006 at 04:34:44PM CEST: > > > >2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> > > > > * tests/link-order.at: Take hardcode_direct and > > hardcode_direct_static into consideration when testing > > link order. > > Thanks. Applied both this change and the linked patch. Thanks. Are you volunteering for the backport to branch-1-5 (which has a similar issue) or should I do it? Cheers, Ralf
Re: Ignore hardcode_direct=yes if results in static lib entry
Hello, * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > The following patch addresses > http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > added a new variable, hardcode_direct_static, to indicate if > hardcode_direct=yes would hardcode a static library dependency. This > impacts HP-UX/PA and AIX. > > Patch against HEAD. This patch is missing a documentation update (doc/libtool.texi). I'm not sure whether it should be backported, probably not. Does the testsuite pass with this? Cheers, Ralf > 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> > > * libltdl/config/ltmain.m4sh, libltdl/m4/libtool.m4 > (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG, > _LT_LANG_FC_CONFIG) [ aix4*, aix5*, hpux10*, hpux11* ]: > Introduce a new variable, hardcode_direct_static, which > would ignore hardcode_direct=yes if the result would create a > static library dependency. Static library dependencies are > immune to $shlibpath_var.
Re: Ignore hardcode_direct=yes if results in static lib entry
Ralf Wildenhues wrote: Hello, Howdy! * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: The following patch addresses http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I added a new variable, hardcode_direct_static, to indicate if hardcode_direct=yes would hardcode a static library dependency. This impacts HP-UX/PA and AIX. Patch against HEAD. This patch is missing a documentation update (doc/libtool.texi). I'll commit one presently. I'm not sure whether it should be backported, probably not. Looks like a new feature to me... no backport rqd imho. Does the testsuite pass with this? It passes on my Gentoo and Tiger laptops. I believe Albert has seen no regressions on his architectures (judging by the related testsuite patch). 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> * libltdl/config/ltmain.m4sh, libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG) [ aix4*, aix5*, hpux10*, hpux11* ]: Introduce a new variable, hardcode_direct_static, which would ignore hardcode_direct=yes if the result would create a static library dependency. Static library dependencies are immune to $shlibpath_var. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: HEAD link-order.at fails when hardcode_direct=yes
Ralf Wildenhues wrote: Hi Albert, Gary, Howdy! * Albert Chin wrote on Wed, May 17, 2006 at 02:44:49PM CEST: + case $hardcode_direct$hardcode_direct_static in + yesno) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; You shouldn't grep for $shrext_cmds. It's called *_cmds because it may contain commands. The right way is to module=no eval shared_ext=\"$shrext_cmds\" Oops. Should've spotted that myself. I'll fix that presently too. * Gary V. Vaughan wrote on Wed, May 17, 2006 at 04:34:44PM CEST: 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/link-order.at: Take hardcode_direct and hardcode_direct_static into consideration when testing link order. Thanks. Applied both this change and the linked patch. Thanks. Are you volunteering for the backport to branch-1-5 (which has a similar issue) or should I do it? Luckily, in my reply to your next email we've agreed that it doesn't need a backport. ;-) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: Ignore hardcode_direct=yes if results in static lib entry
Hi Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: > Ralf Wildenhues wrote: > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > >>The following patch addresses > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > >>added a new variable, hardcode_direct_static, to indicate if > >>hardcode_direct=yes would hardcode a static library dependency. This > >>impacts HP-UX/PA and AIX. > >This patch is missing a documentation update (doc/libtool.texi). > > I'll commit one presently. Thanks. It would be great if you could explain that "static library dependency" does _not_ have to do with static libraries at all -- what a confusing name IMHO! Maybe we should think of a better one. Is that what HP-UX is using in their documentation? > >I'm not sure whether it should be backported, probably not. > > Looks like a new feature to me... no backport rqd imho. Fine with me. Cheers, Ralf
Re: HEAD link-order.at fails when hardcode_direct=yes
Hi Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:15:29PM CEST: > Ralf Wildenhues wrote: > >>>2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> > >>> > >>> * tests/link-order.at: Take hardcode_direct and > >>> hardcode_direct_static into consideration when testing > >>> link order. > >> > >>Thanks. Applied both this change and the linked patch. > > > >Thanks. Are you volunteering for the backport to branch-1-5 (which has > >a similar issue) or should I do it? > > Luckily, in my reply to your next email we've agreed that it doesn't > need a backport. ;-) Nope. The test was broken before the new feature. The test fix Albert suggested before implementing hardcode_direct_static needs a backport. It's just the new feature that doesn't. Cheers, Ralf
Re: HEAD link-order.at fails when hardcode_direct=yes
Ralf Wildenhues wrote: Hi Gary, Hallo Ralf! * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:15:29PM CEST: Ralf Wildenhues wrote: 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/link-order.at: Take hardcode_direct and hardcode_direct_static into consideration when testing link order. Thanks. Applied both this change and the linked patch. Thanks. Are you volunteering for the backport to branch-1-5 (which has a similar issue) or should I do it? Luckily, in my reply to your next email we've agreed that it doesn't need a backport. ;-) Nope. The test was broken before the new feature. The test fix Albert suggested before implementing hardcode_direct_static needs a backport. It's just the new feature that doesn't. Oh right... I hadn't noticed tests/linkorder.test in the branch-1-5 tree. I'll do the backport. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: Ignore hardcode_direct=yes if results in static lib entry
> > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > >>The following patch addresses > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > >>added a new variable, hardcode_direct_static, to indicate if > > >>hardcode_direct=yes would hardcode a static library dependency. This > > >>impacts HP-UX/PA and AIX. I think this should be set for OpenBSD as well, no? If I understand this correctly, then this setting will kill off one of the biggest complaints the OpenBSD folks have against Libtool. :-) But say: do we actually know of systems that have hardcode_direct=yes and that cause it to put the path into the DT_RPATH and not just the full path in the DT_NEEDED? If not, we don't need this new flag, and reordering what we like to do in ltmain would be the better solution. Oh well. I put this patch off for a reason: it requires lots of thought... Cheers, Ralf
Re: LT_AC_PROG_SED
Ralf Wildenhues wrote: Hi Gary, Hallo Ralf! I'm attaching the revised branch-1-5 version of the patch for approval. More inline... Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Fri, Feb 10, 2006 at 11:52:04AM CET: There is still the problem with pulling in an old installed libtool.m4 with an `AC_DEFUN([LT_AC_PROG_SED], [' declaration... but we don't address that problem in branch-1-5 for any other macros at the moment either. Aahh. That's why you can't change the branch-1-5 version from AC_DEFUN([LT_AC_PROG_SED], ...) to m4_defun([LT_AC_PROG_SED], ...) now: if the user has 1.5.24's libtool.m4 and 1.5.22's libtool.m4 both in aclocal's search path, both will be pulled in. Yuck. General rule: within the branch-1-5 branch, you cannot ever remove an AC_DEFUNed name. Not. ever. Agreed. This is worth documenting in HACKING IMHO. You can add the AC_SUBST to branch-1-5, but you cannot AU_ALIAS there, and you cannot AC_DEFUN([AC_PROG_SED]) there. So IMHO best to leave branch-1-5 as is otherwise. Iff you want to add AC_PROG_SED, then probably best to m4_defun([AC_PROG_SED], ...) AC_DEFUN([LT_AC_PROG_SED], [AC_DIAGNOSE([obsolete], [...])dnl AC_PROG_SED]) so that you avoid the backward compatibility traps of both an AU_DEFUNed or AU_ALIASed LT_AC_PROG_SED (untested BTW). Attached tested with released and bleeding edge autotools. The HEAD patch is fine without the lt~obsolete change and with LT_AC_PROG_SED. Thanks for the review. I'll commit presently. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: LT_AC_PROG_SED
Gary V. Vaughan wrote: I'm attaching the revised branch-1-5 version of the patch for approval. More inline... Forgot the attachment. (Note to self: Really must migrate back to gnus) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook Index: libtool--release--1.5/ChangeLog === --- libtool--release--1.5.orig/ChangeLog 2006-05-15 17:40:59.0 +0100 +++ libtool--release--1.5/ChangeLog 2006-05-17 16:38:51.0 +0100 @@ -1,3 +1,12 @@ +2006-05-17 Gary V. Vaughan <[EMAIL PROTECTED]> + + * libtool.m4 (LT_AC_PROG_SED): Rename to AC_PROG_SED and only + define if autoconf failed to provide a definition. + AC_SUBST([SED]) for compatibility with future autoconf release + of AC_PROG_SED. Provide an LT_AC_PROG_SED wrapper with attendant + obsolesence warning for projects that used this undocumented + macro. + 2006-05-15 Bruno Haible <[EMAIL PROTECTED]>, Ralf Wildenhues <[EMAIL PROTECTED]> @@ -252,7 +261,7 @@ 2005-11-26 Peter O'Gorman <[EMAIL PROTECTED]> - * ltmain.in (link mode): Add missing $LTCFLAGS for a $LTCC. + * ltmain.in (link mode): Add missing $LTCFLAGS for a $LTCC. * libtool.m4 [darwin]: Use $LTCC $LTCFLAGS to create reloadable objects. @@ -519,7 +528,7 @@ 2005-10-17 Ralf Wildenhues <[EMAIL PROTECTED]> - * ltmain.in [darwin]: Don't check for "bundle" in file path. + * ltmain.in [darwin]: Don't check for "bundle" in file path. Reported by Christoph Egger <[EMAIL PROTECTED]>. 2005-10-13 Peter O'Gorman <[EMAIL PROTECTED]> Index: libtool--release--1.5/libtool.m4 === --- libtool--release--1.5.orig/libtool.m4 2006-05-15 17:41:00.0 +0100 +++ libtool--release--1.5/libtool.m4 2006-05-17 16:37:02.0 +0100 @@ -620,7 +620,7 @@ # # Check whether the given compiler option works AC_DEFUN([AC_LIBTOOL_COMPILER_OPTION], -[AC_REQUIRE([LT_AC_PROG_SED]) +[AC_REQUIRE([AC_PROG_SED]) AC_CACHE_CHECK([$1], [$2], [$2=no ifelse([$4], , [ac_outfile=conftest.$ac_objext], [ac_outfile=$4]) @@ -2142,7 +2142,7 @@ [assume the C compiler uses GNU ld @<:@default=no@:>@])], [test "$withval" = no || with_gnu_ld=yes], [with_gnu_ld=no]) -AC_REQUIRE([LT_AC_PROG_SED])dnl +AC_REQUIRE([AC_PROG_SED])dnl AC_REQUIRE([AC_PROG_CC])dnl AC_REQUIRE([AC_CANONICAL_HOST])dnl AC_REQUIRE([AC_CANONICAL_BUILD])dnl @@ -6417,17 +6417,15 @@ [AC_CHECK_TOOL(RC, windres, no) ]) +m4_ifndef([AC_PROG_SED], [ # NOTE: This macro has been submitted for inclusion into # # GNU Autoconf as AC_PROG_SED. When it is available in # # a released version of Autoconf we should remove this# # macro and use it instead. # -# LT_AC_PROG_SED -# -- -# Check for a fully-functional sed program, that truncates -# as few characters as possible. Prefer GNU sed if found. -AC_DEFUN([LT_AC_PROG_SED], + +m4_defun([AC_PROG_SED], [AC_MSG_CHECKING([for a sed that does not truncate output]) AC_CACHE_VAL(lt_cv_path_SED, [# Loop through the user's path and test for sed and gsed. @@ -6478,5 +6476,14 @@ done ]) SED=$lt_cv_path_SED +AC_SUBST([SED]) AC_MSG_RESULT([$SED]) -]) +])#AC_PROG_SED +])#m4_ifndef + +# Old name: +AC_DEFUN([LT_AC_PROG_SED], +[AC_PROG_SED +AC_DIAGNOSE([obsolete], +[Please update your configure.ac. $0 is superceded by A][C_PROG_SED])dnl +])#LT_AC_PROG_SED
RE: [png-mng-implement] -version-number and BeOS
From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] >John Bowler: >> The issue here is that libpng on irix has (currently) a major version >> number of '0', as it does on all other operating systems. > >Why should the version number be constant across operating systems? It isn't. The *major* version number is the same across all operating systems (all the ones libpng supports.) In so far as this issue is concerned I believe libpng is supported on a sufficient variety of platforms to exercise all the different cases in ltmain.sh - so I think we are testing all the different varieties of version number mangling in libtool. libpng has an existing (one-makefile-per-os) build system which produces shared libraries for each operating system with a particular version number. Across minor revisions (including API adds) the major number does not change and must not change (on any platform). Across a major revision the library and include file *names* change, and we keep the same major version number. When we tried to get a configure script to work in 1.2.9 (a minor revision from package version 1.2.8) we obviously wanted the configure stuff to generate the same shared library names+*major* versions as the makefiles. Indeed this is a requirement - we need to continue to support libpng12 without a major shared library revision. Since we wanted to swap to a configure script build by default we had to have it generate the required major versions across all platforms. When I tried to do this with --version-info I discovered that I couldn't get the correct result (even with a change to major version number) on freebsd. IIRC to set the minor part of the version number on *linux* I had to supply a non-zero 'age' but if I did that it would change the *major* version on freebsd. This is discussed at length in the png-implement archives. The conclusion was that the required value for --version-info had to be changed for different Oses. When I tried this with --version-number, however, I found it was portable; I could set a single version number for all Oses. libtool correctly removes the spurious parts - so the version number is 0:9:0 and we get libpng12.so.0.9.0 on linux and libpng12.so.0 on freebsd. Notice that we *did* change our version numbering scheme to get this to work - but only in the minor part (we had libpng12.so.0.1.2.8 before on linux). Of course we then found that the irix build fails. This is all documented on the png-implement archive. The important points are: 1) We want to use minor versioning on the platforms which support it. 2) The major version must not change on any platform between successive (minor revision) configure builds. 3) We could change the major version to be (say) '1' at the next major release, but we can't change it in libpng 1.2.x John Bowler <[EMAIL PROTECTED]>
Re: LT_AC_PROG_SED
Hi Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 06:10:24PM CEST: > Gary V. Vaughan wrote: > >I'm attaching the revised branch-1-5 version of the patch for approval. > >More inline... OK, here's another problem with this: I know we don't support Autoconf-2.13 any more with branch-1-5 Libtool, but we're actually not far away from supporting it; so close, that some ports collections ship with a small patch to allow to use it with 2.13, with a couple dozen line patch or so. Autoconf-2.13 has neither m4_defun nor m4_require. IMHO we should just not use this patch. There's no real breakage if you drop it, so it doesn't fix a bug, right? And when the user updates to Libtool-2.0, he'll still get the move to AC_PROG_SED through autoupdate. Cheers, Ralf
Re: LT_AC_PROG_SED
* Ralf Wildenhues wrote on Wed, May 17, 2006 at 06:31:20PM CEST: > > IMHO we should just not use this patch. Except for the AC_SUBST, of course. Sorry about that. Cheers, Ralf
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: > > Ralf Wildenhues wrote: > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > >>The following patch addresses > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > >>added a new variable, hardcode_direct_static, to indicate if > > >>hardcode_direct=yes would hardcode a static library dependency. This > > >>impacts HP-UX/PA and AIX. > > > >This patch is missing a documentation update (doc/libtool.texi). > > > > I'll commit one presently. > > Thanks. It would be great if you could explain that "static library > dependency" does _not_ have to do with static libraries at all -- what > a confusing name IMHO! Maybe we should think of a better one. Is that > what HP-UX is using in their documentation? I couldn't find a name for this in the HP documentation so I made something up :) However, the output of 'chatr' has 'static' in the type of the DT_NEEDED line so that's where I came up with the name. -- albert chin ([EMAIL PROTECTED])
Re: LT_AC_PROG_SED
Ralf Wildenhues wrote: Hi Gary, Hallo Ralf! OK, here's another problem with this: I know we don't support Autoconf-2.13 any more with branch-1-5 Libtool, but we're actually not far away from supporting it; so close, that some ports collections ship with a small patch to allow to use it with 2.13, with a couple dozen line patch or so. Autoconf-2.13 has neither m4_defun nor m4_require. Really? If we can do it so easily, I think we should integrate such a patch. Now that branch-1-5 is in maintenance mode, I don't think it incurrs too much overhead. Can you point me at an appropriate patch? I think it would be nice to leave behind our (hopefully) last 1.5.x release that continues to work with Autoconf 2.13. IMHO we should just not use this patch. There's no real breakage if you drop it, so it doesn't fix a bug, right? And when the user updates to Libtool-2.0, he'll still get the move to AC_PROG_SED through autoupdate. It does fix the missing AC_SUBST bug, so I think that part has to go in. The AC_PROG_SED vs LT_AC_PROG_SED is just candy really, so I don't think it would be so bad to drop the rest of the patch. However, if the only problem is Autoconf-2.13 compatibility, I'd advocate committing as is, and fixing the compatibility in a separate patch (which could exchange the m4_defun for an m4_define). What do you think? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: HEAD link-order.at fails when hardcode_direct=yes
Gary V. Vaughan wrote: Ralf Wildenhues wrote: > Are you volunteering for the backport to branch-1-5 (which has > a similar issue) or should I do it? I'll do the backport. Okay to commit? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook Index: libtool--release--1.5/ChangeLog === --- libtool--release--1.5.orig/ChangeLog 2006-05-17 17:51:57.0 +0100 +++ libtool--release--1.5/ChangeLog 2006-05-17 17:52:55.0 +0100 @@ -1,3 +1,8 @@ +2006-05-17 Albert Chin-A-Young <[EMAIL PROTECTED]> + + * tests/link-order.test: Take hardcode_direct into consideration + when testing link order. + 2006-05-15 Bruno Haible <[EMAIL PROTECTED]>, Ralf Wildenhues <[EMAIL PROTECTED]> Index: libtool--release--1.5/tests/link-order.test === --- libtool--release--1.5.orig/tests/link-order.test 2006-05-17 17:51:52.0 +0100 +++ libtool--release--1.5/tests/link-order.test 2006-05-17 17:52:25.0 +0100 @@ -12,6 +12,10 @@ retcode=0 +eval `$libtool --config | $EGREP '^(hardcode_direct|shrext_cmds)='` +module=no +eval shared_ext=\"$shrext_cmds\" + rm -rf linkorder.dir mkdir linkorder.dir top_dir=`pwd`/linkorder.dir @@ -62,12 +66,24 @@ *-*-aix* | *-*-interix*) ;; # These systems have different path syntax *) # Do not error if we do not relink (e.g. static-only systems) - if $EGREP relinking $srcdir/stderr; then -if $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' $srcdir/stdout; then :; else - echo "$0: wrong link order" 1>&2 - retcode=1 + case $hardcode_direct in + yes) +if $EGREP relinking $srcdir/stderr; then + if $EGREP " .*\/new\/lib/libb$shared_ext .*\/old\/lib/libcee$shared_ext" $srcdir/stdout; then :; else +echo "$0: wrong link order" 1>&2 +retcode=1 + fi fi - fi +;; + *) +if $EGREP relinking $srcdir/stderr; then + if $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' $srcdir/stdout; then :; else +echo "$0: wrong link order" 1>&2 +retcode=1 + fi +fi +;; + esac ;; esac
Re: HEAD link-order.at fails when hardcode_direct=yes
Hi Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 06:55:54PM CEST: > Gary V. Vaughan wrote: > >Ralf Wildenhues wrote: > >> Are you volunteering for the backport to branch-1-5 (which has > >> a similar issue) or should I do it? > > > >I'll do the backport. > > Okay to commit? Go for it! Thanks! Cheers, Ralf > +2006-05-17 Albert Chin-A-Young <[EMAIL PROTECTED]> > + > + * tests/link-order.test: Take hardcode_direct into consideration > + when testing link order. > +
Re: Ignore hardcode_direct=yes if results in static lib entry
Hallo Ralf! Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: The following patch addresses http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I added a new variable, hardcode_direct_static, to indicate if hardcode_direct=yes would hardcode a static library dependency. This impacts HP-UX/PA and AIX. I think this should be set for OpenBSD as well, no? I'm not familiar with OpenBSD. Now that we have a test to expose it, we just need someone to run it on OpenBSD and find out :-) If I understand this correctly, then this setting will kill off one of the biggest complaints the OpenBSD folks have against Libtool. :-) Cool! But say: do we actually know of systems that have hardcode_direct=yes and that cause it to put the path into the DT_RPATH and not just the full path in the DT_NEEDED? If not, we don't need this new flag, and reordering what we like to do in ltmain would be the better solution. Parameterising in this fashion will allow us to cope with such a host if/when we find it very easily, where the reordering solution would require more work. I like the current approach better for that reason. Oh well. I put this patch off for a reason: it requires lots of thought... Sorry, I didn't see your objections when working through the front of my backlog :-( Pragmatically it does solve a real problem though... better to do that before 2.0 IMHO. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
some missing _LT_DECL_SED requirements
Eric reported this against CVS M4 recently: http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html OK? Cheers, Ralf * libltdl/m4/libtool.m4 (_LT_LINKER_OPTION): Require _LT_DECL_SED. (_LT_CMD_GLOBAL_SYMBOLS, _LT_LINKER_SHLIBS): Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Likewise. Report by Eric Blake. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.64 diff -u -r1.64 libtool.m4 --- libltdl/m4/libtool.m4 14 May 2006 08:43:58 - 1.64 +++ libltdl/m4/libtool.m4 15 May 2006 16:13:17 - @@ -1308,6 +1308,7 @@ # Check whether the given linker option works AC_DEFUN([_LT_LINKER_OPTION], [m4_require([_LT_FILEUTILS_DEFAULTS])dnl +m4_require([_LT_DECL_SED]) AC_CACHE_CHECK([$1], [$2], [$2=no save_LDFLAGS="$LDFLAGS" @@ -3116,6 +3117,7 @@ AC_REQUIRE([AC_OBJEXT])dnl AC_REQUIRE([LT_PATH_NM])dnl AC_REQUIRE([LT_PATH_LD])dnl +m4_require([_LT_DECL_SED])dnl m4_require([_LT_DECL_EGREP])dnl m4_require([_LT_TAG_COMPILER])dnl @@ -3907,6 +3909,7 @@ AC_REQUIRE([LT_PATH_NM])dnl m4_require([_LT_FILEUTILS_DEFAULTS])dnl m4_require([_LT_DECL_EGREP])dnl +m4_require([_LT_DECL_SED])dnl m4_require([_LT_CMD_GLOBAL_SYMBOLS])dnl m4_require([_LT_TAG_COMPILER])dnl AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries]) Index: libltdl/m4/ltdl.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v retrieving revision 1.26 diff -u -r1.26 ltdl.m4 --- libltdl/m4/ltdl.m4 23 Mar 2006 22:39:41 - 1.26 +++ libltdl/m4/ltdl.m4 15 May 2006 16:13:17 - @@ -255,6 +255,7 @@ m4_require([_LT_CHECK_OBJDIR])dnl m4_require([_LT_HEADER_DLFCN])dnl m4_require([_LT_CHECK_DLPREOPEN])dnl +m4_require([_LT_DECL_SED])dnl dnl Don't require this, or it will be expanded earlier than the code dnl that sets the variables it relies on:
Re: some missing _LT_DECL_SED requirements
Hallo Ralf, Eric: Ralf Wildenhues wrote: Eric reported this against CVS M4 recently: http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html OK? Yes please. We're sure to keep tripping over these things as we twiddle the dependency graph of our macros and affect the order their expansions arrive in configure. We could really use a test to check we have all the appropriate DECLs required in each of our macros... I can't think of an easy way to do it though :-( * libltdl/m4/libtool.m4 (_LT_LINKER_OPTION): Require _LT_DECL_SED. (_LT_CMD_GLOBAL_SYMBOLS, _LT_LINKER_SHLIBS): Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Likewise. Report by Eric Blake. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: some missing _LT_DECL_SED requirements
* Gary V. Vaughan wrote on Wed, May 17, 2006 at 07:17:30PM CEST: > Ralf Wildenhues wrote: > >Eric reported this against CVS M4 recently: > >http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html > > > >OK? > > Yes please. Except I forgot that the missing bit was $Xsed, not $SED. So we'd also need: > > * libltdl/m4/libtool.m4 (_LT_LINKER_OPTION): Require > > _LT_DECL_SED. > > (_LT_CMD_GLOBAL_SYMBOLS, _LT_LINKER_SHLIBS): Likewise. > > * libltdl/m4/ltdl.m4 (LTDL_INIT): Likewise. > > Report by Eric Blake. (_LT_DECL_SED): Set $Xsed here, using $SED. Moved from... (_LT_SETUP): ...here. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.67 diff -u -r1.67 libtool.m4 --- libltdl/m4/libtool.m4 17 May 2006 14:28:40 - 1.67 +++ libltdl/m4/libtool.m4 17 May 2006 17:32:01 - @@ -181,7 +181,6 @@ # Sed substitution that helps us do robust quoting. It backslashifies # metacharacters that are still active within double-quoted strings. -Xsed='sed -e 1s/^X//' sed_quote_subst='s/\([["`$\\]]\)/\\\1/g' # Same as above, but do not quote variable references. @@ -6796,6 +6795,7 @@ m4_defun([_LT_DECL_SED], [AC_PROG_SED test -z "$SED" && SED=sed +Xsed="$SED -e 1s/^X//" _LT_DECL([], [SED], [1], [A sed program that does not truncate output]) _LT_DECL([], [Xsed], ["\$SED -e 1s/^X//"], [Sed that helps us avoid accidentally triggering echo(1) options like -n])
Re: some missing _LT_DECL_SED requirements
Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, May 17, 2006 at 07:17:30PM CEST: Ralf Wildenhues wrote: Eric reported this against CVS M4 recently: http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html OK? Yes please. Except I forgot that the missing bit was $Xsed, not $SED. So we'd also need: * libltdl/m4/libtool.m4 (_LT_LINKER_OPTION): Require _LT_DECL_SED. (_LT_CMD_GLOBAL_SYMBOLS, _LT_LINKER_SHLIBS): Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Likewise. Report by Eric Blake. (_LT_DECL_SED): Set $Xsed here, using $SED. Moved from... (_LT_SETUP): ...here. All the more evidence for a nice automated check! :-) Looks good. Please go ahead. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:59:23PM +0200, Ralf Wildenhues wrote: > > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > > > >>The following patch addresses > > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > > >>added a new variable, hardcode_direct_static, to indicate if > > > >>hardcode_direct=yes would hardcode a static library dependency. This > > > >>impacts HP-UX/PA and AIX. > > I think this should be set for OpenBSD as well, no? Possibly. OpenBSD does seem to have this problem, from my limited testing. -- albert chin ([EMAIL PROTECTED])
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:00:04PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > The following patch addresses > > http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > added a new variable, hardcode_direct_static, to indicate if > > hardcode_direct=yes would hardcode a static library dependency. This > > impacts HP-UX/PA and AIX. > > > > Patch against HEAD. > > Does the testsuite pass with this? Yes. -- albert chin ([EMAIL PROTECTED])
Re: HEAD link-order.at fails when hardcode_direct=yes
On Wed, May 17, 2006 at 04:48:24PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, May 17, 2006 at 02:44:49PM CEST: > > > > + case $hardcode_direct$hardcode_direct_static in > > + yesno) > > +AT_CHECK([if $EGREP relinking stderr; then > > + $EGREP " .*\/new\/lib/libb$shrext_cmds > > .*\/old\/lib/libcee$shrext_cmds" stdout > > + else :; fi], [0], [ignore], [], [echo "wrong link order"]) > > +;; > > You shouldn't grep for $shrext_cmds. It's called *_cmds because it may > contain commands. The right way is to > module=no > eval shared_ext=\"$shrext_cmds\" The patch below fixes this. I skipped it because I knew I wouldn't need it for HP-UX/AIX :) 2006-05-17 Albert Chin <[EMAIL PROTECTED]> Ralf Wildenhues <[EMAIL PROTECTED]> * tests/link-order.at: Don't use $shrext_cmds directly because it might contain commands. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.10 diff -u -p -r1.10 link-order.at --- tests/link-order.at 17 May 2006 14:28:40 - 1.10 +++ tests/link-order.at 17 May 2006 16:38:15 - @@ -23,6 +23,9 @@ AT_KEYWORDS([libtool]) eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|hardcode_direct_static|shrext_cmds)='` LDFLAGS="$LDFLAGS -no-undefined" +module=no +eval shared_ext=\"$shrext_cmds\" + prefix_old=`pwd`/old prefix_new=`pwd`/new mkdir src $prefix_old $prefix_new $prefix_old/lib $prefix_new/lib @@ -72,7 +75,7 @@ aix* | interix*) ;; # These systems hav case $hardcode_direct$hardcode_direct_static in yesno) AT_CHECK([if $EGREP relinking stderr; then - $EGREP " .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds" stdout + $EGREP " .*\/new\/lib/libb$shared_ext .*\/old\/lib/libcee$shared_ext" stdout else :; fi], [0], [ignore], [], [echo "wrong link order"]) ;; *)
back out AS_SHELL_SANITIZE: get compile mode up to speed
This patch fixes a long-standing compile time regression of HEAD over branch-1-5. I'd like to back out AS_SHELL_SANITIZE now, and maybe eventually add AS_BOURNE_COMPATIBLE when we can assume Autoconf-2.60 (in a couple of years). Rationale: we can throw a bunch of its code out now, and the resulting libtool script shows a noticeable speedup of the overall build in some test code. Also, this way we can be sure right now that the code doesn't have the recent issues of AS_SHELL_SANITIZE any more (certainly that argument will turn against me in due time; that's where AS_BOURNE_COMPATIBLE should come into play). This also has the advantage that we may be certain that the CDPATH piece in libtool.m4 is superfluous (we don't have to cater for older Autoconf versions any more). Then, there are a couple more low hanging fruit to kill: $SP2NL, $NL2SP, whether `unset' works, all can be computed at configure time. With all of this in place, a mere $LIBTOOL -n --mode=compile $CC -c foo.c is marginally faster with CVS HEAD than with branch-1-5 (both around 70ms on my test system), and takes about half as long as $LIBTOOL --mode=compile $CC -c foo.c with an empty source file and gcc-3.4.4 (around 130ms). Without this patch, CVS HEAD ranges at about 140ms excluding the compiler, and 200ms including it, so this actually halves the script overhead for compile mode in the best case. All of this at the expense of a slightly slower and larger configure and config.status. To put this in perspective: over here, this change makes running the old part of the HEAD test suite take 4m38s instead of 5m53s. :-)) Some rationale about why I don't think the expensive locale variable treatment from Autoconf is necessary in Libtool: Autoconf tries to work here even in the remote case that you're on IRIX, force configure to use that borked shell that allows to set variables read-only, and also actually have been stupid enough to set some of the locale variables read-only. If you meet someone that matches this description, point him to this message, and tell him to get a clue. Any reasons against applying this now? FYI, in case you're starting to worry, I probably won't do more speedup work before 2.0. Cheers, Ralf Fix mode=compile time regression of CVS HEAD over branch-1-5. * libltdl/m4/libtool.m4 (_LT_CHECK_XSI_SHELL): Rename to... (_LT_CHECK_SHELL_FEATURES): ...this. (_LT_SETUP): Adjust caller. (_LT_CHECK_XSI_SHELL): New libtool variables `lt_unset', `SP2NL', `NL2SP', to contain results from tests for unset, taken from AS_BOURNE_COMPATIBLE, and ASCII vs EBCDIC, taken... * libltdl/config/general.m4sh: ...from here, and used... * libltdl/config/ltmain.m4sh: ...here everywhere now. * (AS_SHELL_SANITIZE): Replace by faster, actually necessary part of its expansion, taken from current Autoconf CVS. Do not save and set all locale variables any more, but only LANG, LC_ALL, LC_CTYPE, LC_COLLATE, LC_MESSAGES. (func_mode_execute): Adjust. * libltdl/m4/libtool.m4 (_LT_CONFIG): No need to unset CDPATH here any more. * libtoolize.m4sh: Compute `SP2NL' and `NL2SP' here, too. Index: libltdl/config/general.m4sh === RCS file: /cvsroot/libtool/libtool/libltdl/config/general.m4sh,v retrieving revision 1.3 diff -u -r1.3 general.m4sh --- libltdl/config/general.m4sh 11 Jan 2006 17:24:56 - 1.3 +++ libltdl/config/general.m4sh 17 May 2006 17:12:38 - @@ -105,19 +105,6 @@ sed_double_backslash='s/^\(\(''''''\)*''''\)\$/\1\\$/; s/\([[^\\]]\(''''''\)*''''\)\$/\1\\$/g' -# test EBCDIC or ASCII -case `echo X|tr X '\101'` in - A) # ASCII based system -# \n is not interpreted correctly by Solaris 8 /usr/ucb/tr - SP2NL='tr \040 \012' - NL2SP='tr \015\012 \040\040' - ;; - *) # EBCDIC based system - SP2NL='tr \100 \n' - NL2SP='tr \r\n \100\100' - ;; -esac - # Standard options: opt_dry_run=false opt_help=false Index: libltdl/config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.44 diff -u -r1.44 ltmain.m4sh --- libltdl/config/ltmain.m4sh 17 May 2006 01:58:40 - 1.44 +++ libltdl/config/ltmain.m4sh 17 May 2006 17:12:38 - @@ -77,18 +77,34 @@ TIMESTAMP="@TIMESTAMP@" [EMAIL PROTECTED]@ +# Be Bourne compatible +if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then + emulate sh + NULLCMD=: + # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which + # is contrary to our usage. Disable this feature. + alias -g '${1+"$@"}'='"$@"' + setopt NO_GLOB_SUBST +else + case `(set -o) 2>/dev/null` in *posix*) set -o posix;; esac +fi +BIN_SH=xpg4; export BIN_SH # for Tru64 +DUALCASE=1; export DUALCASE # for MKS sh + # NLS nuisances: We save the
Re: Ignore hardcode_direct=yes if results in static lib entry
* Albert Chin wrote on Wed, May 17, 2006 at 06:35:06PM CEST: > On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: > > * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: > > > Ralf Wildenhues wrote: > > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > > > >>The following patch addresses > > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > > >>added a new variable, hardcode_direct_static, to indicate if > > > >>hardcode_direct=yes would hardcode a static library dependency. This > > > >>impacts HP-UX/PA and AIX. > > Thanks. It would be great if you could explain that "static library > > dependency" does _not_ have to do with static libraries at all -- what > > a confusing name IMHO! Maybe we should think of a better one. Is that > > what HP-UX is using in their documentation? > > I couldn't find a name for this in the HP documentation so I made > something up :) However, the output of 'chatr' has 'static' in the > type of the DT_NEEDED line so that's where I came up with the name. OK. So let's name the thingy hardcode_direct_absolute. I'm still not convinced this approach is right at all; here's why: First, there are more bugs in the description: you're not going after the fact that the absolute DT_NEEDED entry cannot be overridden by $shlibpath_var, but that the absolute DT_NEEDED entry just isn't overridden by any other paths, not even DT_RPATH. Here's why: it may be possible that the system allows absolute DT_NEEDED entries, but that shlibpath_overrides_runpath=no. Then you're still out of luck when trying to "relocate" stuff. But once indirect dependencies come into play, this issue is still important, because now you don't only have the runpaths in that library at hand, but also those of the objects that are already loaded and higher up in the graph. What I'm trying to say: the current description doesn't make it clear that from a Libtool POV these variables are orthogonal to each other. I actually believe that the absolute DT_NEEDED is actually the normal case with most of the systems we have hardcode_direct=yes for; I just need some time to go check and prove that. Then, the right fix would be to kill this variable again and just reorder the hardcode methods in ltmain.in. Cheers, Ralf
Re: some missing _LT_DECL_SED requirements
* Gary V. Vaughan wrote on Wed, May 17, 2006 at 07:48:14PM CEST: > Ralf Wildenhues wrote: > > > >>> * libltdl/m4/libtool.m4 (_LT_LINKER_OPTION): Require > >>> _LT_DECL_SED. > >>> (_LT_CMD_GLOBAL_SYMBOLS, _LT_LINKER_SHLIBS): Likewise. > >>> * libltdl/m4/ltdl.m4 (LTDL_INIT): Likewise. > >>> Report by Eric Blake. > >(_LT_DECL_SED): Set $Xsed here, using $SED. Moved from... > >(_LT_SETUP): ...here. > > All the more evidence for a nice automated check! :-) I don't think so. Let's make it less unnecessary automation for once. Less factorization, less requirements stuff; after all, there is IMHO no need to factorize unless the stuff is actually supposed to possibly used in different combinations. But I've ranted about AC_REQUIRE/m4_require and Libtool macros before, enough of that now... > Looks good. Please go ahead. Thanks! Applied. Cheers, Ralf
Re: some missing _LT_DECL_SED requirements
Hallo Ralf! Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, May 17, 2006 at 07:48:14PM CEST: Ralf Wildenhues wrote: * libltdl/m4/libtool.m4 (_LT_LINKER_OPTION): Require _LT_DECL_SED. (_LT_CMD_GLOBAL_SYMBOLS, _LT_LINKER_SHLIBS): Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Likewise. Report by Eric Blake. (_LT_DECL_SED): Set $Xsed here, using $SED. Moved from... (_LT_SETUP): ...here. All the more evidence for a nice automated check! :-) I don't think so. Let's make it less unnecessary automation for once. Less factorization, less requirements stuff; after all, there is IMHO no need to factorize unless the stuff is actually supposed to possibly used in different combinations. But I've ranted about AC_REQUIRE/m4_require and Libtool macros before, enough of that now... Perhaps you misunderstand me? I'm advocating sh.test style static check that tries to match uses of, say, $EGREP in an AC_DEFUN with a matching m4_require([_LT_DECL_EGREP]) at ``make test'' time. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: some missing _LT_DECL_SED requirements
Hi Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 10:42:21PM CEST: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Wed, May 17, 2006 at 07:48:14PM CEST: > >>All the more evidence for a nice automated check! :-) > > > >I don't think so. Let's make it less unnecessary automation for once. > >Less factorization, less requirements stuff; after all, there is IMHO no > >need to factorize unless the stuff is actually supposed to possibly used > >in different combinations. But I've ranted about AC_REQUIRE/m4_require > >and Libtool macros before, enough of that now... > > Perhaps you misunderstand me? I'm advocating sh.test style static > check that tries to match uses of, say, $EGREP in an AC_DEFUN with a > matching m4_require([_LT_DECL_EGREP]) at ``make test'' time. Nope, I'm not misunderstanding you, I think. Such an automated check will not save you. You can still get into trouble by requiring macros in the wrong order. I.e., all macros have their requirements listed at the beginning, but still some are expanded before their requirements. IMHO this is an argument for not factorizing more than makes actually sense from a script POV: if I have to think about requirement order of third party macros, and I actually know in which order I want stuff to appear in the output, and what I'm doing is linear, well, then why am I not just writing it that way? Cheers, Ralf
Re: some missing _LT_DECL_SED requirements
[trimmed Eric, as he's probably bored of overhearing us by now ;-)] Ralf Wildenhues wrote: Hi Gary, Hallo Ralf, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 10:42:21PM CEST: > Perhaps you misunderstand me? I'm advocating sh.test style static > check that tries to match uses of, say, $EGREP in an AC_DEFUN with a > matching m4_require([_LT_DECL_EGREP]) at ``make test'' time. Nope, I'm not misunderstanding you, I think. Such an automated check will not save you. > You can still get into trouble by requiring macros in the wrong order. I.e., all macros have their requirements listed at the beginning, but still some are expanded before their requirements. Yikes! I hope that isn't really the case. Autoconf require graph tracing has gone to quite some lengths to ensure that all the macros you AC_REQUIRE are expanded before the body of the macro that requires them. Oh wait, you mean that the expansion order of the required macros can't be inferred? I agree with that, but I don't think it has any bearing on the usefulness of having a warning in macros that use, say, $Xsed without ac_require([_LT_DECL_SED]). IMHO this is an argument for not factorizing more than makes actually sense from a script POV: if I have to think about requirement order of third party macros, and I actually know in which order I want stuff to appear in the output, and what I'm doing is linear, well, then why am I not just writing it that way? ACK. So long as there is (preferably) no code duplication :-D Really, the point is moot, as I have no clue how to reliably extract a list of macros that forgot to require the appropriate DECLs :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 09:55:42PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, May 17, 2006 at 06:35:06PM CEST: > > On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: > > > * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: > > > > Ralf Wildenhues wrote: > > > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > > > > > >>The following patch addresses > > > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > > > >>added a new variable, hardcode_direct_static, to indicate if > > > > >>hardcode_direct=yes would hardcode a static library dependency. This > > > > >>impacts HP-UX/PA and AIX. > > > > Thanks. It would be great if you could explain that "static library > > > dependency" does _not_ have to do with static libraries at all -- what > > > a confusing name IMHO! Maybe we should think of a better one. Is that > > > what HP-UX is using in their documentation? > > > > I couldn't find a name for this in the HP documentation so I made > > something up :) However, the output of 'chatr' has 'static' in the > > type of the DT_NEEDED line so that's where I came up with the name. > > OK. So let's name the thingy hardcode_direct_absolute. Ok. > I'm still not convinced this approach is right at all; here's why: > First, there are more bugs in the description: you're not going after > the fact that the absolute DT_NEEDED entry cannot be overridden by > $shlibpath_var, but that the absolute DT_NEEDED entry just isn't > overridden by any other paths, not even DT_RPATH. > > Here's why: it may be possible that the system allows absolute DT_NEEDED > entries, but that shlibpath_overrides_runpath=no. Then you're still out > of luck when trying to "relocate" stuff. But once indirect dependencies > come into play, this issue is still important, because now you don't > only have the runpaths in that library at hand, but also those of the > objects that are already loaded and higher up in the graph. True. > What I'm trying to say: the current description doesn't make it clear > that from a Libtool POV these variables are orthogonal to each other. Ok, so should I contribute a new patch with the rewording? > I actually believe that the absolute DT_NEEDED is actually the > normal case with most of the systems we have hardcode_direct=yes > for; I just need some time to go check and prove that. Then, the > right fix would be to kill this variable again and just reorder the > hardcode methods in ltmain.in. -- albert chin ([EMAIL PROTECTED])
Re: back out AS_SHELL_SANITIZE: get compile mode up to speed
On Wed, 2006-05-17 at 20:53 +0200, Ralf Wildenhues wrote: > This patch fixes a long-standing compile time regression of HEAD over > branch-1-5. > Any reasons against applying this now? I think this is okay. A question though, in branch-1.5 we only unset modify LC_ALL and LANG, don't we? Why do we need to change the others here? Peter signature.asc Description: This is a digitally signed message part
FYI: 313-gary-swap-lt_dlhandle_iterate-caller-args.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Applied to HEAD. Index: ChangeLog from Gary V. Vaughan <[EMAIL PROTECTED]> * libltdl/ltdl.c (lt_dlhandle_fetch): Arguments to lt_dlhandle_iterate were in the wrong order. Index: libltdl/ltdl.c === RCS file: /sources/libtool/libtool/libltdl/ltdl.c,v retrieving revision 1.238 diff -u -p -u -r1.238 ltdl.c --- libltdl/ltdl.c 25 Nov 2005 18:42:28 - 1.238 +++ libltdl/ltdl.c 17 May 2006 23:11:10 - @@ -1,5 +1,5 @@ /* ltdl.c -- system independent dlopen wrapper - Copyright (C) 1998, 1999, 2000, 2004, 2005 Free Software Foundation, Inc. + Copyright (C) 1998, 1999, 2000, 2004, 2005, 2006 Free Software Foundation, Inc. Originally by Thomas Tanner <[EMAIL PROTECTED]> NOTE: The canonical source of this file is maintained with the @@ -2156,7 +2156,7 @@ lt_dlhandle_fetch (lt_dlinterface_id ifa assert (iface); /* iface is a required argument */ - while ((handle = lt_dlhandle_iterate (handle, iface))) + while ((handle = lt_dlhandle_iterate (iface, handle))) { lt__handle *cur = (lt__handle *) handle; if (cur && cur->info.name && streq (cur->info.name, module_name)) - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook __ This patch notification generated by cvsapply version 0.15 http://savannah.gnu.org/projects/cvs-utils -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEa67kFRMICSmD1gYRAt0/AJ45NvWroLBHWDcLUkohTIv8t2olUwCgvRVm 405t6LWAamlFi5tN283Eq3U= =6bkx -END PGP SIGNATURE-
FYI: 314-gary-rename-to-hardcode_direct_absolute.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Applied to HEAD. Index: ChangeLog from Gary V. Vaughan <[EMAIL PROTECTED]> * libltdl/config/ltmain.m4sh, libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG), tests/link-order.at [ aix4*, aix5*, hpux10*, hpux11* ]: rename hardcode_direct_static to hardcode_direct_absolute. * doc/libtool.texi (libtool script contents): Adjust. Index: doc/libtool.texi === RCS file: /sources/libtool/libtool/doc/libtool.texi,v retrieving revision 1.214 diff -u -p -u -r1.214 libtool.texi --- doc/libtool.texi 17 May 2006 17:59:47 - 1.214 +++ doc/libtool.texi 18 May 2006 00:09:04 - @@ -5355,10 +5355,11 @@ line (such as @[EMAIL PROTECTED]/[EMAIL PROTECTED] @var{hardcode_libdir_flag_spec} is specified. @end defvar [EMAIL PROTECTED] hardcode_direct_static -Static library dependencies do not use @var{shlibpath_var}. Default -to @samp{no}. However, if @var{hardcode_direct} is @samp{yes} but -would create such a static library dependency, set to @samp{yes}. [EMAIL PROTECTED] hardcode_direct_absolute +Some architectures hardcode "absolute" library directories that can not +be overridden by @var{shlibpath_var} when @var{hardcode_direct} is [EMAIL PROTECTED] In that case set @var{hardcode_direct_absolute} to [EMAIL PROTECTED], or otherwise @samp{no}. @end defvar @defvar hardcode_into_libs Index: libltdl/config/ltmain.m4sh === RCS file: /sources/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.45 diff -u -p -u -r1.45 ltmain.m4sh --- libltdl/config/ltmain.m4sh 17 May 2006 14:28:40 - 1.45 +++ libltdl/config/ltmain.m4sh 18 May 2006 00:09:07 - @@ -3833,7 +3833,7 @@ func_mode_link () ;; relink) if test "$hardcode_direct" = yes && - test "$hardcode_direct_static" = no; then + test "$hardcode_direct_absolute" = no; then add="$dir/$linklib" elif test "$hardcode_minus_L" = yes; then add_dir="-L$dir" @@ -3889,7 +3889,7 @@ func_mode_link () add= # Finalize command for both is simple: just hardcode it. if test "$hardcode_direct" = yes && -test "$hardcode_direct_static" = no; then +test "$hardcode_direct_absolute" = no; then add="$libdir/$linklib" elif test "$hardcode_minus_L" = yes; then add_dir="-L$libdir" Index: libltdl/m4/libtool.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.69 diff -u -p -u -r1.69 libtool.m4 --- libltdl/m4/libtool.m4 17 May 2006 20:11:03 - 1.69 +++ libltdl/m4/libtool.m4 18 May 2006 00:09:11 - @@ -3969,7 +3969,7 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' _LT_TAGVAR(hardcode_automatic, $1)=no _LT_TAGVAR(hardcode_direct, $1)=no - _LT_TAGVAR(hardcode_direct_static, $1)=no + _LT_TAGVAR(hardcode_direct_absolute, $1)=no _LT_TAGVAR(hardcode_libdir_flag_spec, $1)= _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)= _LT_TAGVAR(hardcode_libdir_separator, $1)= @@ -4319,7 +4319,7 @@ _LT_EOF _LT_TAGVAR(archive_cmds, $1)='' _LT_TAGVAR(hardcode_direct, $1)=yes - _LT_TAGVAR(hardcode_direct_static, $1)=yes + _LT_TAGVAR(hardcode_direct_absolute, $1)=yes _LT_TAGVAR(hardcode_libdir_separator, $1)=':' _LT_TAGVAR(link_all_deplibs, $1)=yes _LT_TAGVAR(file_list_spec, $1)='${wl}-f,' @@ -4565,7 +4565,7 @@ _LT_EOF _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' _LT_TAGVAR(hardcode_libdir_separator, $1)=: _LT_TAGVAR(hardcode_direct, $1)=yes - _LT_TAGVAR(hardcode_direct_static, $1)=yes + _LT_TAGVAR(hardcode_direct_absolute, $1)=yes _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E' # hardcode_minus_L: Not really in the search PATH, # but as the default location of the library. @@ -4610,7 +4610,7 @@ _LT_EOF ;; *) _LT_TAGVAR(hardcode_direct, $1)=yes - _LT_TAGVAR(hardcode_direct_static, $1)=yes + _LT_TAGVAR(hardcode_direct_absolute, $1)=yes _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E' # hardcode_minus_L: Not really in the search PATH, @@ -4981,10 +4981,10 @@ _LT_TAGDECL([], [hardcode_libdir_separat _LT_TAGDECL([], [hardcode_direct], [0], [Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes DIR into the resulting binary]) -_LT_TAGDECL([],
Re: back out AS_SHELL_SANITIZE: get compile mode up to speed
Hi Peter, * Peter O'Gorman wrote on Thu, May 18, 2006 at 01:14:11AM CEST: > On Wed, 2006-05-17 at 20:53 +0200, Ralf Wildenhues wrote: > > This patch fixes a long-standing compile time regression of HEAD over > > branch-1-5. > > > Any reasons against applying this now? > > I think this is okay. Thanks! Applied. > A question though, in branch-1.5 we only unset modify LC_ALL and LANG, > don't we? Why do we need to change the others here? Well, that is a bug in branch-1-5. I'll fix it. If LC_ALL and LANG are both unset, but LC_COLLATE is set, then that setting is used for collating. We could limit ourselves to LANG and LC_ALL, but only if we *set* the latter. Because of the warning that some systems may not grok LC_ALL=C (I'm pretty sure those systems are not in wide use any more, if at all), I'd rather not do that unconditionally. Cheers, Ralf
Re: some missing _LT_DECL_SED requirements
Good morning Gary, * Gary V. Vaughan wrote on Wed, May 17, 2006 at 11:19:22PM CEST: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Wed, May 17, 2006 at 10:42:21PM CEST: > >> Perhaps you misunderstand me? I'm advocating sh.test style static > >> check that tries to match uses of, say, $EGREP in an AC_DEFUN with a > >> matching m4_require([_LT_DECL_EGREP]) at ``make test'' time. > > > >Nope, I'm not misunderstanding you, I think. Such an automated check > >will not save you. > > > >You can still get into trouble by requiring macros in the wrong order. > >I.e., all macros have their requirements listed at the beginning, but > >still some are expanded before their requirements. > > Yikes! I hope that isn't really the case. Autoconf require graph > tracing has gone to quite some lengths to ensure that all the macros you > AC_REQUIRE are expanded before the body of the macro that requires them. This is what I was thinking of: http://lists.gnu.org/archive/html/bug-gnulib/2006-03/msg00075.html > Oh wait, you mean that the expansion order of the required macros can't > be inferred? That's true as well, but it's not a big problem iff dependencies are all recorded properly. > I agree with that, but I don't think it has any bearing on > the usefulness of having a warning in macros that use, say, $Xsed > without ac_require([_LT_DECL_SED]). Yep. > >IMHO this is an argument for not factorizing more than makes actually > >sense from a script POV: if I have to think about requirement order of > >third party macros, and I actually know in which order I want stuff to > >appear in the output, and what I'm doing is linear, well, then why am > >I not just writing it that way? > > ACK. So long as there is (preferably) no code duplication :-D Certainly. > Really, the point is moot, as I have no clue how to reliably extract > a list of macros that forgot to require the appropriate DECLs :-( Indeed, me neither. I usually compare the generated configure scripts by hand before and after a patch, for our toplevel and some of the old tests' directories. Cheers, Ralf
FYI: branch-1-5: locale reset (was: back out AS_SHELL_SANITIZE: get compile mode up to speed)
* Ralf Wildenhues wrote on Thu, May 18, 2006 at 07:45:42AM CEST: > * Peter O'Gorman wrote on Thu, May 18, 2006 at 01:14:11AM CEST: > > > A question though, in branch-1.5 we only unset modify LC_ALL and LANG, > > don't we? Why do we need to change the others here? > > Well, that is a bug in branch-1-5. I'll fix it. I've applied the following to branch-1-5. Cheers, Ralf * ltmain.in: Reset/unset not only LANG and LC_ALL, but also LC_CTYPE, LC_COLLATE, LC_MESSAGES. (execute mode): Restore them. Noted by Peter O'Gorman. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.126 diff -u -r1.334.2.126 ltmain.in --- ltmain.in 14 May 2006 08:21:23 - 1.334.2.126 +++ ltmain.in 18 May 2006 06:47:13 - @@ -113,12 +113,14 @@ # These must not be set unconditionally because not all systems understand # e.g. LANG=C (notably SCO). # We save the old values to restore during execute mode. -if test "${LC_ALL+set}" = set; then - save_LC_ALL="$LC_ALL"; LC_ALL=C; export LC_ALL -fi -if test "${LANG+set}" = set; then - save_LANG="$LANG"; LANG=C; export LANG -fi +for lt_var in LANG LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES +do + eval "if test \"\${$lt_var+set}\" = set; then + save_$lt_var=\$$lt_var + $lt_var=C + export $lt_var + fi" +done # Make sure IFS has a sensible default lt_nl=' @@ -6464,12 +6466,14 @@ fi # Restore saved environment variables - if test "${save_LC_ALL+set}" = set; then - LC_ALL="$save_LC_ALL"; export LC_ALL - fi - if test "${save_LANG+set}" = set; then - LANG="$save_LANG"; export LANG - fi + for lt_var in LANG LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES + do + eval "if test \"\${save_$lt_var+set}\" = set; then + $lt_var=\$save_$lt_var; export $lt_var + else + $lt_unset $lt_var + fi" + done # Now prepare to actually exec the command. exec_cmd="\$cmd$args"