automake
[Top][All Lists]
Advanced

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

Re: tr and automake


From: James Laird
Subject: Re: tr and automake
Date: Mon, 17 Oct 2005 12:19:46 -0500 (CDT)

Hi, Ralf.

On Mon, 17 Oct 2005, Ralf Wildenhues wrote:
> * 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
> > > ltmain.sh)?
> > > 
> > > 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
> of
>   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.

I'm pretty sure that the tr test was originally added for a reason, but as 
I say, it's not my test (and has been around for several years), so I 
don't know what the original error was.

I can tell by looking that some of HDF5's own tests will fail if the wrong
tr is used in certain circumstances (I see tests when using mpicc, when
using some of HDF5's I/O "filters", etc.).  These tests I can fix to use 
a variable.

I'm not overjoyed about HDF5 using one tr while libtool uses another, but
I'm satisfied that libtool uses tr safely, so I'll live with it.

Thanks for the help!
   James





reply via email to

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