On Sun, 24 Jun 2012 10:32:14 -0500 "David C. Rankin" <drankinatty@...> 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.