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. -- David C. Rankin, J.D.,P.E.