On Tue, Aug 19, 2008, Jeff Johnson wrote:

> I have this linux multilib peculier patch below to integrate (or leave as
> per-vendor private).
>
> Ralf: What say ye? Integrate or leave as private per-vendor patch?

Hmmm... although I understand the wish for automatic and out-of-the-box
testing for more than just "lib", in practice there can be "lib",
"lib32" and "lib64" and whatever else even more obscure directories. And
which one we have to pick up actually depends on the used compiler flags
which in turn select the used ABI.

So, if we here just also check for "lib64", this solves the problem of
this particular vendor, but for others this could be just plain wrong --
as their _compiler_ uses "lib64" only if the 64-bit ABI was explicitly
selected. So, if we would attempt a _REAL_ solution we would have
to actually _COMPILE_ and _LINK_ a test program against all of "lib",
"lib32" and "lib64" and choose the one which actually _WORKS_.

And even in this case if someone has a "lib42" ;-) we would reach "game
over" again. That's why I intentionally checked for just the single
_CANONICAL_ "lib" and instead have explicitly implemented for our
RPM_CHECK_LIB macro the support for _implicitly_ locating a library
through the supplied built-time flags (see acinclude.m4 lines 285-299).
So, instead of using...

$ ./configure --with-foo=/path/to/foo

...and relying on RPM_CHECK_LIB to know about all possible good and bad
"libXX" subdirs (which too easily can go wrong), one just can use the
fully equivalent, more flexible and especially more precise...

$ CPPFLAGS="-I/path/to/foo/include" \
  LDFLAGS="-L/path/to/foo/lib64" \
  ./configure --with-foo=external

This way the "libfoo.* should be happily picked up from
/path/to/foo/lib64, too.

I guess, either the vendor who supplied this "lib64" patch overlooked
the fact that this approach is possible and equivalent or our support
for this approach in RPM_CHECK_LIB is broken for him (and we then should
fix this, of course). But I recommend to _not_ simply add "lib64" to the
list of directories to check...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com