> Hmmm.  As I understand it, potential directory schemes
> for 64-bit installs break down like this:  64-bit libs may go in /lib64 or
> /lib.  32-bit libs may go in /lib32 or /lib.  So a given distro will use
> /lib64 and /lib, or /lib and /lib32, or /lib64 and /lib32 (often with /lib as a symlink
> to /lib64), or I suppose we could have a pseudo-32-bit case where everything
> is jumbled together in /lib, although that could get messy.
> 
> Anyway, that means that /lib64 should always be the correct
> directory if it exists, otherwise we need to use /lib as a fallback if there
> is no /lib64.  That should also work for 32-bit or similar setups that have only
> /lib.
> 
> However, by my understanding, that means that above fragment
> should work (it's overriding results for /lib with results for
> /lib64 if the latter exists.  I think.)  So either I'm
> misunderstanding, or the error is somewhere else.

I understand your frustration. Before the patches I was on the opposite end and could not build those packages in 64-bit.

I agree we need a smarter method in the configuration process to detect the correct locations. I don't know how to fix this. There is so much I wish I knew how to fix. :-) Perhaps an easier solution is to migrate tqca and tqca-tls to cmake?

I suppose in the short-term you reverse the patches in your build scripts. :-(

Darrell