On Thu, Aug 23, 2012 at 10:38:16AM -0500, Rich Johnston wrote: > On 08/22/2012 07:02 PM, Dave Chinner wrote: > >On Wed, Aug 22, 2012 at 02:49:06PM -0500, Rich Johnston wrote: > >>The later versions of libtool (i.e.2.4+) create a wrapper (bash script) for > >>lstat64 in the src directory. The wrapper calls the real binary created by > >>libtool (.libs/lstat64) > > > >Doesn't happen here. libtool 2.4.2 generates a dynamically linked > >executable. > > > > OK I agree I made an incorrect assumption that it would happen with > later versions of libtool. It does happen with libtool 2.4 on > openSUSE 12.1 and could with other Linux distributions. No special > modifications were made to the build environment. I will correct > the comment to reflect my exact error. Ok, so what we need to do now is understand why the build environment is creating two different styles of binaries from apparently the same configure script and libtool versions. Changing the test without understanding the cause is not the correct way to address the problem. > # lstat64 - temporary wrapper script for .libs/lstat64 > # Generated by libtool (GNU libtool) 2.4 > # > # The lstat64 program cannot be directly executed until all the libtool > # libraries that it depends on are installed. There's your problem. You haven't properly installed all the libraries that are needed for xfstests to build dynamically linked binaries. What libraries are not installed? Did you run make install on your xfsprogs/xfsdump builds? > >I think this error indicates somethign wrong with your build > >environment or platform, not that there is anything wrong with the > >test. > > Don't agree, the build environment was not modified from the default > installation and the script was created by libtool. Perhaps the default installation doesn't install everything that is needed. If libtool is telling you that you haven't installed all the necessary libraries, then your environment is deficient in some way... > Why take the risk of this error when /bin/cat is a perfectly > acceptable substitution and would prevent the possibility of this > happening. What risk? It's a test environment, and there's an implicit assumption that it's been set up correctly and that autoconf detects that everything has been installed correctly before letting the build continue. It's great to know when someone is testing in a non-standard environment, or the build has screwed up in some way. IOWs, the fact that your build is different to everyone else is something we need to understand, not slap a band-aid over and ignore. That is, the first thing to do is root cause analysis. i.e. find out why your build is different. Once the root cause is known we can decide on the best way to address the problem. Indeed, it may be that autoconf is not detecting something correctly or vice versa, and that's the reason for the weird build result and the eventual test failure. So, what libraries are not installed where they can be dynamically linked that libtool is dependent on, how is configure finding them (does it even have tests to check those libraries are installed?), did it pick them out of some default library path outside of a system directory, etc.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
