Re: [PATCH] xfstests: Replace lstat64 with cat in test 120

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs