On 06/24/2012 12:45 PM, Darrell Anderson wrote:
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
I reopened 1016 because it isn't fixed for all. We need to find a way to properly handle the lib/lib64 issue because unless your distro uses lib64, tqca-tls Fails to Build.