Re: Bug#517501: libtool: uninitialized shell variable causes link failure when run under zsh

[Török Edwin]

On 2009-02-28 14:29, Ralf Wildenhues wrote:
> tags fixed-upstream
> thanks
>
> [ adding libtool-patches; see  ]
>
> OK, here's the deal: 'emulate sh' turns off the special properties of
> the $path array, but keeps its first entry:
>
> $ zsh -c 'echo $path.; emulate sh; echo $path.'
> /usr/local/bin /usr/bin /bin /usr/bin/X11 /usr/games /usr/X11R6/bin.
> /usr/local/bin.
>
> BTW, this doesn't happen if zsh is invoked as sh:
> $ ln -s /usr/bin/zsh sh; ./sh -c 'echo $path.; emulate sh; echo $path.'
> .
> .
>
> Not sure whether that may be considered a bug in zsh or not, but anyway
> libtool should not assume that the ordinary variable $path is unset.
>
> Your proposed patch does not set $path in all possible cases, so I'm
> applying this one to upstream GNU Libtool to fix it.
>   

Thanks.
Is there a release date planned for next libtool release?
I would like to know if I should apply this patch to ClamAV's
config/ltmain.sh, or wait until a new version of libtool is released
(ClamAV's release is planned for March 16th).

Best regards,
--Edwin

Re: Bug#517501: libtool: uninitialized shell variable causes link failure when run under zsh

[Ralf Wildenhues]

* Török Edwin wrote on Sat, Feb 28, 2009 at 01:49:27PM CET:
> Is there a release date planned for next libtool release?

No.  Well, maybe yes, but isn't there an empirical law like
"publishing the next planned release date will double the
chance of it being missed"?  ;-)

> I would like to know if I should apply this patch to ClamAV's
> config/ltmain.sh, or wait until a new version of libtool is released
> (ClamAV's release is planned for March 16th).

Given that you should not change the Libtool version used at the
very last second to a fresh release, I'd suggest you apply this
patch.

Cheers,
Ralf

Re: Bug#517501: libtool: uninitialized shell variable causes link failure when run under zsh

[Ralf Wildenhues]

tags fixed-upstream
thanks

[ adding libtool-patches; see  ]

OK, here's the deal: 'emulate sh' turns off the special properties of
the $path array, but keeps its first entry:

$ zsh -c 'echo $path.; emulate sh; echo $path.'
/usr/local/bin /usr/bin /bin /usr/bin/X11 /usr/games /usr/X11R6/bin.
/usr/local/bin.

BTW, this doesn't happen if zsh is invoked as sh:
$ ln -s /usr/bin/zsh sh; ./sh -c 'echo $path.; emulate sh; echo $path.'
.
.

Not sure whether that may be considered a bug in zsh or not, but anyway
libtool should not assume that the ordinary variable $path is unset.

Your proposed patch does not set $path in all possible cases, so I'm
applying this one to upstream GNU Libtool to fix it.

Cheers, and thanks again,
Ralf

2009-02-28  Török Edwin(tiny change)
Ralf Wildenhues  

Do not add bogus directory arguments to link command lines.
* libltdl/config/ltmain.m4sh (func_mode_link): Ensure $path is
always initialized before it is used.  Reported for zsh, for
which $path contains $PATH entries even after "emulate sh", see
.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 49e07c3..7fcf4cb 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5624,6 +5624,7 @@ func_mode_link ()
  if test "$link_all_deplibs" != no; then
# Add the search paths of all dependency libraries
for deplib in $dependency_libs; do
+ path=
  case $deplib in
  -L*) path="$deplib" ;;
  *.la)