On Aug 19, 2008, at 12:54 PM, Ralf S. Engelschall wrote:

> 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...
>

Yes the windriver patch is linux chauvinistic and substitutes  
pragmatic for generality.

But cross-packaging and cross-building (which is happening @windriver  
with rpm itself)
requires some means of host <-> target libdir search parameterization.

How should that be accomplished? Hmmm, adding -L/usr/lib64 to LIBS  
might suffice.

OTOH, /usr/lib <-> /usr/lib64 is rather more regular/structural, so  
perhaps finessing
      .../lib/...
into a variable might be better than LIBS overrides.

FYI: I have a whole class of @MARK64@ AutoFu patchups that I need to  
solve
somehow. I'd like to have a general and integrated solution rather  
than nasty
changes to configure and Makefile.in using per-vendor private patches  
if possible.

73 de Jeff