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.