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
