Re: [png-mng-implement] -version-number and BeOS

[Ralf Wildenhues]

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

[Albert Chin]

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

[Gary V. Vaughan]

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

[Gary V. Vaughan]

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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

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

[Gary V. Vaughan]

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

[Gary V. Vaughan]

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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

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

[Gary V. Vaughan]

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

[Ralf Wildenhues]

> > >* 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

[Gary V. Vaughan]

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]

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

[John Bowler]

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

[Ralf Wildenhues]

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]

* 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

[Albert Chin]

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

[Gary V. Vaughan]

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]

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

[Ralf Wildenhues]

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

[Gary V. Vaughan]

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

[Ralf Wildenhues]

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

[Gary V. Vaughan]

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

[Ralf Wildenhues]

* 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

[Gary V. Vaughan]

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

[Albert Chin]

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

[Albert Chin]

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

[Albert Chin]

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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

* 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

[Ralf Wildenhues]

* 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

[Gary V. Vaughan]

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

[Ralf Wildenhues]

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

[Gary V. Vaughan]

[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

[Albert Chin]

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

[Peter O'Gorman]

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

[Gary V. Vaughan]

-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

[Gary V. Vaughan]

-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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

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]

* 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"