On Sun, 24 Jun 2012 10:32:14 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
On 06/23/2012 02:52 AM, Darrell Anderson wrote:
Commit a5dfd481?
tqca-tls builds here on 64-bit, but Slackware uses lib${LIBSUFFIX}, as do many other
distros.
I don't know how to make any of that work on both types of directories.
Darrell
Thanks Darrell,
How do we fix or undo the commit that breaks building for distros that use
../lib on x86_64??
<rant>
Damn!
Why was this change made without regard to accommodating the prior build
behavior? That is one thing we have to avoid doing. I recall the lib64
discussion and I specifically noted that Arch and others use /lib regardless. We
can't simply implement changes that break build behavior for some and not others
and just -- leave it to the other guy to sort it out.
Issues like this need to be solved TDE wide, not just until it "works for
me."
</rant>
That being said, I think this in this case, it is just broken logic leading to
the build failure. Somewhere in this range from grep:
configure:#include<stdlib.h>
configure: TQString expandLibs(const TQString &lib)
configure: return TQString("-L") + lib;
configure: bool findLibrary(const TQString &name, TQString *lib)
configure: *lib = "";
configure: if(checkLibrary("/usr/local/lib", name)) {
configure: *lib = "/usr/local/lib";
configure: if(checkLibrary("/usr/local/lib64", name)) {
configure: *lib = "/usr/local/lib64";
configure: if [ ! -f "$QTDIR/lib/libtqt-mt.so.3" ]; then
configure: if [ ! -f "$QTDIR/lib64/libtqt-mt.so.3" ]; then
configure: echo "libtqt-mt.so.3 installed in $QTDIR/lib/"
configure: echo "or $QTDIR/lib64/."
If somebody knows how to fix this, please let us know so that a patch can be
tested and pushed. configure logic and undoing git changes has never been a
strong point so I would welcome suggestions here.
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.