24 Jun
2012
24 Jun
'12
8:54 p.m.
On 06/24/2012 12:45 PM, Darrell Anderson wrote:
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.
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