Re: tr and automake

[James Laird]

Hello again.

On Fri, 14 Oct 2005, Ralf Wildenhues wrote:
> Hi James,
> 
> * James Laird wrote on Tue, Oct 11, 2005 at 04:52:10PM CEST:
> > On Tue, 11 Oct 2005, Ralf Wildenhues wrote:
> > > * James Laird wrote on Mon, Oct 10, 2005 at 08:11:31PM CEST:
> > > > 
> > > > My package (hdf.ncsa.uiuc.edu/HDF5) has historically tested that the tr 
> > > > utility works correctly at configure time.  Apparently there are two 
> > > > kinds of tr which expect slightly different syntax for their input.
> > > 
> > > What are the exact differences?  What does "the other tr" do in the test
> > > you quoted?
> > 
> > It's a difference in syntax.  This is what I got from the sysadmin:
> > 
> > >COMPATIBILITY
> > >      System V has historically implemented character ranges using
> > >      the syntax ``[c-c]'' instead of the ``c-c'' used by historic
> *snip*
> > >      as ``a\-z''.  In order to get POSIX.2 behavior,  the  POSIX2
> > >      environment  variable  should be set, otherwise the historic
> > >      Svstem V behavior is gotten.
> 
> Ah, thanks, I didn't know that (and I really should've checked SUS
> before answering).
> 
> Can't you set POSIX2, as documented, instead of searching for "the other
> tr"?  *time passes*  Nope, no go.  Setting POSIX2 is not documented on
> Solaris 9, nor does it work.
> 
> > > > We have now encountered a platform where setting the path to point to 
> > > > the 
> > > > "correct" tr confuses the path to some libraries that the compiler 
> > > > needs.  
> > > 
> > > Let me guess: some w32 platform?
> > 
> > Solaris 8, 9, and 10, actually.
> 
> Yep.
> 
> > > In general, two differences between execution from within `configure'
> > > and outside are likely candidates for different behavior: setting of
> > > PATH, and locale settings.  Just FYI.
> > 
> > Right.  Our problem isn't with configure finding one tr and the user
> > finding another, but with configure expecting one tr and the PATH being
> > set to point to another.  Setting the PATH to point to the "correct" tr
> > works on most platforms, but this time it also confused the path to
> > something else, so we're looking for a better solution.
> 
> OK.  
> 
> > 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).

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.

> > Sorry if my explanation left a little to be desired; I'm trying to 
> > maintain legacy tests on a platform that I personally don't have access 
> > to.  :)
> 
> 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 
ftp://ftp.ncsa.uiuc.edu/HDF/pub/outgoing/hdf5/snapshots/
use the 1.7 releases.

> > The symptom of the problem is that the test (included below) fails.  
> > Commenting out the test and using the "wrong" version of tr (the two 
> > versions are explained above) may or may not have repercussions; the build 
> > had a few odd issues but succeeded, but some issues were expected since it 
> > was a new platform.
> 
> Hmm, where does this test originate from?  Ahh, hdf/configure.in, ok.
> I don't like the test too much, here's why:
> - if it turns out we need to choose one of several available `tr'
>   programs, it would be better to set a variable `TR' with the correct
>   one, and use that throughout,
> - the former also can be modified to allow the user to override the
>   default,
> - for general usability, macros that fail as the negative case should
>   accept an optional argument to override this.  Other packages may just
>   want to see if a decent `tr' is available, or not need it in all
>   circumstances.

Exactly.  I would like to replace 'tr' with 'TR' in this test and
everywhere it is used in configure.in.  However, it looks to me like
libtool uses 'tr' in some of its tests.  So if I use 'TR' in my
configure.in tests, I won't necessarily be testing the same utility that
libtool uses.

I want libtool to use a variable 'TR' (if, indeed, libtool is the 
culprit) so that I can safely change configure.in to test that variable.

> > At any rate, since we know there are two different versions of tr, we'd
> > like to enforce that users have the same tr utility that we test with; we
> > have a test to enforce this, but can't change the tests in aclocal.m4 that
> > we didn't write (and which apparently came from libtool?).
> > 
> > Should I just forward this conversation to a libtool list rather than an 
> > automake list?
> 
> I'm not convinced yet that this is a libtool issue.  We can still move
> then.

Thanks a lot,
   James