[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tr and automake

From: Ralf Wildenhues
Subject: Re: tr and automake
Date: Mon, 17 Oct 2005 17:59:20 +0200
User-agent: Mutt/1.5.11

Hi James,

* James Laird wrote on Mon, Oct 17, 2005 at 05:05:51PM CEST:
> On Fri, 14 Oct 2005, Ralf Wildenhues wrote:
> > * James Laird wrote on Tue, Oct 11, 2005 at 04:52:10PM CEST:
> > >
> > > You're right; I think the macros in question may come from libtool rather 
> > > than automake.  They seem to be setting sys_lib_search_path_spec.
> > 
> > Now, I can't reproduce this.  We only use `tr' in a couple of
> > situations, on a couple of systems, and so far I had thought this to be
> > safe.  Which libtool version is this (./libtool --version, or look into
> >
> > 
> > Can you post some output that demonstrates the breakage?
> > (Like: `configure' output, config.log, or even `sh -x configure' output)
> One of the macros that includes tr is AC_LIBTOOL_SYS_DYNAMIC_LINKER.  
> Another is AC_PROG_LD.  The version of libtool we're using is 1.5.14.  I 
> can confirm that tr is used in share/aclocal/libtool.m4 (and I'm pretty 
> sure we haven't modified that file).

OK, if you haven't modified it, then I can guarantee you that it won't
be used, unless you cross-compile: it's only used when $host_os is one
  darwin* | rhapsody* | linux* | mingw*

> I haven't seen any errors caused by the "wrong" tr being used except for
> the one test in configure (which I inherited from my predecessor).  The 
> test looks like:
> AC_MSG_CHECKING([if tr works])
> TR_TEST="`echo Test | tr 'a-z,' 'A-Z '`"
> if test $TR_TEST != "TEST"; then
>   AC_MSG_ERROR([tr program doesn't work])
> else
>   AC_MSG_RESULT([yes])
> fi
> and there is no output beyond printing the error message that tr doesn't 
> work.

Even on above systems, we don't use character ranges, so above test
would not really check what we rely on.  I believe we use it only with
arguments that are safe with Solaris tr as well.

So, AFAICS whatever errors you are seeing do not come from this use of
tr.  If you can convince me we use it unsafely, I will try to change our
use (or use `$TR', together with an appropriate test).

To repeat: please have the original bug reporter show erroneous output
that is supposedly caused by this, so we can clear this up.

> > Well, I can test on Solaris 9 if I know exactly what to look for
> > (which hdf version, autotools versions, can I just try a tarball from
> > somewhere?).
> Our snapshot releases are at 
> use the 1.7 releases.

A test compile of 1.7.51 on a Solaris 9/gcc box went fine, except for
boatloads of compiler warnings.  ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]