Re: tr and automake

[Ralf Wildenhues]

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)

> 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?).

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

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

Cheers,
Ralf