* Charles Wilson wrote on Mon, Jan 11, 2010 at 03:54:01AM CET: > Ralf Wildenhues wrote: > > That's not how these ancient shells work. > [snip long explanation] > > Oh, that's just...evil. How could that EVER have been expected to work > properly, except in the most trivial of scripts?
Good question. > >> In any case, here's a quick-n-dirty set of test scripts to help narrow > >> down the problem. If someone with access to HPUX can unpack and run > >> 't.sh', and report back the results, we might be able to narrow down the > >> cause of this problem. (Might need to change the shbang lines to use the > >> same shell that's causing issues with libtool). > > > > The tests all pass with HP-UX /bin/sh and /bin/ksh. > > Well, that's...good, I suppose. It means that the problem isn't > specifically in the fork/shell-func/HERE implementation, such that the > failure ALWAYS occurs. But instead, it means that we have a race > condition or resource contention problem (where 'unique names' can be > considered a resource) -- or maybe my test case wasn't sufficiently > complex, and didn't capture the bug exposed by libtool-as-a-whole. We have a combination of shell bugs, not all of which we can characterize exactly, and we try to not trigger them more than necessary. Let's not worry about this too much for now. If it turns out to be a big problem in practice, we will receive bug reports. If somebody (me) gets overly ambitious, I'll add some printf's to find out whether we are triggering leftover temporaries only in specific cases. Without such data I wouldn't bother searching any further, though. > Unfortunately, I don't see a way to avoid this problem on HP/UX -- short > of requiring a less brain-dead shell. Well, even just characterizing a broken shell is a problem if you don't know exactly what the problem is. Bottom line of all this is merely that we always have to expect trouble on some other systems. For an unrelated anectode: AIX has the nice habit of caching some shared objects (with suitable permissions) in-memory even after process termination, such that subsequent processes using the same library are started faster. During Libtool testsuite run, this happens for some libraries in the build tree. My test hosts mostly have their trees on NFS, which refuses to erase directories with files that are still in use somewhere. Result: the testsuite cannot clean up after itself. This frequently causes hiccups and spurious testsuite failures for Libtool. I usually just move the toplevel testsuite.dir away and remove it a year later, when the system is sure to have been rebooted, or ask the operator to run slibclean at her convenience. Cheers, Ralf
