Tim, All,
I just started a full x86_64 build. 1st since name change and I've hit a snag with tqca-tls. My /etc/profile.d/tqt.sh is executable this time :) The build can't find TQt:
==> Setting PATH and Trinity Environment variables ==> Patching... ==> Starting configure... Configuring qca-tls ... Verifying TQt 3.x Multithreaded (MT) build environment ... fail
There was an error compiling 'conf'. Be sure you have a proper TQt 3.x Multithreaded (MT) build environment set up.
==> ERROR: A failure occurred in build(). Aborting...
HuH??
Looking at the conf.log it looks like a bad joke on 64 bit boxes concerning what was generated:
g++ -c -pipe -Wall -W -O2 -D_REENTRANT -DX11_INC='"/usr/X11R6/include"' -DX11_LIBDIR='"/usr/X11R6/lib64"' -DX11_LIB='"-lXext -lX11 -lm"' -DCC='"gcc"' -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/tqt3/mkspecs/default -I. -I'/usr/include/tqt' -I/opt/tqt3/include -I/usr/X11R6/include -o conf.o conf.cpp g++ -Wl,-rpath,/opt/tqt3/lib64 -o conf conf.o -L/opt/tqt3/lib64 -L/usr/X11R6/lib64 -ltqt-mt -lXext -lX11 -lm -lpthread /usr/bin/ld: cannot find -ltqt-mt collect2: error: ld returned 1 exit status make: *** [conf] Error 1
Where is this /opt/tqt3/lib'64' garbage coming from? Arch just 'lib' not any 'lib64' dir names when handling libraries. Where in this package are the 'lib' or 'lib64' search directories and lib directory names controlled? Like noted earlier, I can build tqca-tls on i686 all day long, but this is one of the first i've built on x86_64 and something isn't quite right. Prior to the name change stuff, this built like clockwork. Where should we look for the culprit here (there isn't much here).
What say the gurus? Ideas?
Where is this /opt/tqt3/lib'64' garbage coming from? Arch just 'lib' not any 'lib64' dir names when handling libraries. Where in this package are the 'lib' or 'lib64' search directories and lib directory names controlled? Like noted earlier, I can build tqca-tls on i686 all day long, but this is one of the first i've built on x86_64 and something isn't quite right. Prior to the name change stuff, this built like clockwork. Where should we look for the culprit here (there isn't much here).
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
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.
On Sun, 24 Jun 2012 10:32:14 -0500 "David C. Rankin" drankinatty@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.
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
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.
On 06/24/2012 03:54 PM, David C. Rankin 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.
Bug 1016 closed - with notes about requirement to update TQt3 build scrips pre-configure for boxes that use FHS standard /lib on 64 bit installs. That leaves a rabbit trail for anyone that runs into the same issue. The note and example left are:
## Fix commits 4412d295 and 18696899 for FHS standard /lib installs # on 64-bit boxes sed -i 's|lib64|lib|g' mkspecs/linux-g++-64/qmake.conf
After making the change (e.g. simply editing mkspecs/linux-g++-64/qmake.conf post-install) tqca-tls built without issue on Arch.
On 06/24/2012 11:13 AM, E. Liddell 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.
PERFECT Logic!
I think the breakdown here is that the logic in qca-tls is NOT working correctly. Here is the build output I get:
TDE Build Started: Jun 23 00:14:24
Building on host Archangel - Adjusting source file to 'bldtde.conf.aa' sourcing config file 'bldtde.conf.aa'
Using Qt = tqt3
tqt3 tqtinterface arts dbus-tqt dbus-1-tqt tqca-tls Found: tqca-tls, i=5 /home/david/tde/pbf/PKGBUILD-tde-tqca-tls Found updating tde-tqca-tls/PKGBUILD updating PKGBUILD md5sum -> e75d4d3c30d2b053eeccb7b551d63c9a deleting build dir from prior build copying pbpkg dir to build dir. copying dependencies-tqca-tls.tar.gz -> /dat_e/bld/tde-tqca-tls changing into build directory '/dat_e/bld/tde-tqca-tls' issuing build command 'sudo makechrootpkg -r /dat_e/ch47' ==> Making package: tde-tqca-tls 14.0.0_dev-1 (Sat Jun 23 05:14:24 UTC 2012) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving Sources... -> Found dependencies-tqca-tls.tar.gz -> Found tqca-tls.patch ==> Validating source files with md5sums... dependencies-tqca-tls.tar.gz ... Passed ==> Extracting Sources... -> Extracting dependencies-tqca-tls.tar.gz with bsdtar ==> Starting build()... ==> Setting PATH and Trinity Environment variables ==> QTDIR: /opt/tqt3, TDEDIR: /opt/trinity ==> Starting configure... Configuring qca-tls ... Verifying TQt 3.x Multithreaded (MT) build environment ... fail
There was an error compiling 'conf'. Be sure you have a proper TQt 3.x Multithreaded (MT) build environment set up.
==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /dat_e/ch47/david/build makepkg --> FAILED, saving logs to '/home/david/tde/err/bld/dependencies/tqca-tls'
The looking at the conf.log file, I have this as the precise failure:
g++ -c -pipe -Wall -W -O2 -D_REENTRANT -DX11_INC='"/usr/X11R6/include"' -DX11_LIBDIR='"/usr/X11R6/lib64"' -DX11_LIB='"-lXext -lX11 -lm"' -DCC='"gcc"' -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/tqt3/mkspecs/default -I. -I'/usr/include/tqt' -I/opt/tqt3/include -I/usr/X11R6/include -o conf.o conf.cpp g++ -Wl,-rpath,/opt/tqt3/lib64 -o conf conf.o -L/opt/tqt3/lib64 -L/usr/X11R6/lib64 -ltqt-mt -lXext -lX11 -lm -lpthread
So somewhere something is not getting the proper directory set to allow TQt to be found. How can I hack ./configure to force it to find TQt in the proper location?
On 06/24/2012 12:46 PM, David C. Rankin wrote:
So somewhere something is not getting the proper directory set to allow TQt to be found. How can I hack ./configure to force it to find TQt in the proper location?
I can't tell what's wrong with this commit. What needs fixing to it finds the libs /lib instead of lib64? I think it is the checklib call:
diff --git a/configure b/configure index 8cbac11..2043c4e 100755 --- a/configure +++ b/configure @@ -60,7 +60,7 @@ if [ -z "$QTDIR" ]; then if [ "$QC_DEBUG" = "Y" ]; then echo $QTDIR not set... trying to find Qt manually fi - for p in /usr/lib/tqt /usr/share/tqt /usr/share/tqt3 /usr/local/lib/tqt /usr/local/share/tqt /usr/lib/tqt3 /usr/local/lib/tqt3 /usr/lib/qt /usr/share/qt /usr/share/qt3 /usr/local/lib/qt /usr/local/share/qt /usr/lib/qt3 /usr/local/lib/qt3 /usr/X11R6/share/qt /usr/qt/3 ; do + for p in /usr/lib/tqt /usr/share/tqt /usr/share/tqt3 /usr/local/lib/tqt /usr/local/share/tqt /usr/lib/tqt3 /usr/local/lib/tqt3 /usr/lib/qt /usr/share/qt /usr/share/qt3 /usr/local/lib/qt /usr/local/share/qt /usr/lib/qt3 /usr/local/lib/qt3 /usr/lib64/tqt /usr/local/lib64/tqt /usr/lib64/tqt3 /usr/local/lib64/tqt3 /usr/lib64/qt /usr/local/lib64/qt /usr/lib64/qt3 /usr/local/lib64/qt3 /usr/X11R6/share/qt /usr/qt/3 ; do if [ -d "$p/mkspecs" ]; then QTDIR=$p break; @@ -394,6 +394,10 @@ public: *lib = "/usr/local/lib"; return true; } + if(checkLibrary("/usr/local/lib64", name)) { + *lib = "/usr/local/lib64"; + return true; + } return false; } @@ -539,9 +543,12 @@ if [ "$?" != "0" ]; then echo "There was an error compiling 'conf'. Be sure you have a proper" echo "TQt 3.x Multithreaded (MT) build environment set up." if [ ! -f "$QTDIR/lib/libtqt-mt.so.3" ]; then - echo - echo "One possible reason is that you don't have" - echo "libtqt-mt.so.3 installed in $QTDIR/lib/." + if [ ! -f "$QTDIR/lib64/libtqt-mt.so.3" ]; then + echo + echo "One possible reason is that you don't have" + echo "libtqt-mt.so.3 installed in $QTDIR/lib/" + echo "or $QTDIR/lib64/." + fi fi echo exit 1;
On 06/24/2012 12:46 PM, David C. Rankin wrote:
So somewhere something is not getting the proper directory set to allow TQt to be found. How can I hack ./configure to force it to find TQt in the proper location?
Do you set QTDIR for your builds? I need to know because the autodetection logic is pretty much split into two parts, one path for if QTDIR is set and a different path if it is not.
Thanks!
Tim
On 06/24/2012 04:14 PM, Timothy Pearson wrote:
Do you set QTDIR for your builds? I need to know because the autodetection logic is pretty much split into two parts, one path for if QTDIR is set and a different path if it is not.
Thanks!
Tim
Yes,
This is with
./configure --qtdir=/opt/tqt3 \ --debug
and it 'still' dumps lib64 into the conf.log file:
Configuring qca-tls ...
QTDIR=/opt/tqt3 QC_WITH_OPENSSL_INC= QC_WITH_OPENSSL_LIB=
Verifying TQt 3.x Multithreaded (MT) build environment ... fail
There was an error compiling 'conf'. Be sure you have a proper TQt 3.x Multithreaded (MT) build environment set up.
==> ERROR: A failure occurred in build().
16:29 archangel:/dat_e/ch47/david/build> cat src/tqca-tls/conf.log g++ -c -pipe -Wall -W -O2 -D_REENTRANT -DX11_INC='"/usr/X11R6/include"' -DX11_LIBDIR='"/usr/X11R6/lib64"' -DX11_LIB='"-lXext -lX11 -lm"' -DCC='"gcc"' -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/tqt3/mkspecs/default -I. -I'/usr/include/tqt' -I/opt/tqt3/include -I/usr/X11R6/include -o conf.o conf.cpp g++ -Wl,-rpath,/opt/tqt3/lib64 -o conf conf.o -L/opt/tqt3/lib64 -L/usr/X11R6/lib64 -ltqt-mt -lXext -lX11 -lm -lpth
There is no /opt/tqt3/lib64 it is '/opt/tqt3/lib' and I can't get it to use it???
On 06/24/2012 04:33 PM, David C. Rankin wrote:
On 06/24/2012 04:14 PM, Timothy Pearson wrote:
Do you set QTDIR for your builds? I need to know because the autodetection logic is pretty much split into two parts, one path for if QTDIR is set and a different path if it is not.
Thanks!
Tim
Yes,
This is with
./configure --qtdir=/opt/tqt3 \ --debug
and it 'still' dumps lib64 into the conf.log file:
Configuring qca-tls ...
QTDIR=/opt/tqt3 QC_WITH_OPENSSL_INC= QC_WITH_OPENSSL_LIB=
Verifying TQt 3.x Multithreaded (MT) build environment ... fail
There was an error compiling 'conf'. Be sure you have a proper TQt 3.x Multithreaded (MT) build environment set up.
==> ERROR: A failure occurred in build().
16:29 archangel:/dat_e/ch47/david/build> cat src/tqca-tls/conf.log g++ -c -pipe -Wall -W -O2 -D_REENTRANT -DX11_INC='"/usr/X11R6/include"' -DX11_LIBDIR='"/usr/X11R6/lib64"' -DX11_LIB='"-lXext -lX11 -lm"' -DCC='"gcc"' -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/opt/tqt3/mkspecs/default -I. -I'/usr/include/tqt' -I/opt/tqt3/include -I/usr/X11R6/include -o conf.o conf.cpp g++ -Wl,-rpath,/opt/tqt3/lib64 -o conf conf.o -L/opt/tqt3/lib64 -L/usr/X11R6/lib64 -ltqt-mt -lXext -lX11 -lm -lpth
There is no /opt/tqt3/lib64 it is '/opt/tqt3/lib' and I can't get it to use it???
Tim,
Just for reference, I've tried this both with the current code and with the commit _reverted_ (and both with/without) setting --qtdir=/opt/tqt3 (to force a manual find). In all cases, some logic somewhere is still writing the /opt/tqt3/lib64 location.
This is on a 64bit box, but there are no lib64 dirs used anywhere in Arch. It has to be simply 'lib'. It is a forest-for-the-trees issue for me at this point. I can't find it.
On 06/24/2012 04:50 PM, David C. Rankin wrote:
Tim,
Just for reference, I've tried this both with the current code and with the commit _reverted_ (and both with/without) setting --qtdir=/opt/tqt3 (to force a manual find). In all cases, some logic somewhere is still writing the /opt/tqt3/lib64 location.
Also, I last built tqca-tls without issue on this x86_64 box on 6/4/12. So the change has been relatively recent.
On 06/24/2012 04:50 PM, David C. Rankin wrote:
Tim,
Just for reference, I've tried this both with the current code and with the commit _reverted_ (and both with/without) setting --qtdir=/opt/tqt3 (to force a manual find). In all cases, some logic somewhere is still writing the /opt/tqt3/lib64 location.
Also, I last built tqca-tls without issue on this x86_64 box on 6/4/12. So the change has been relatively recent.
-- David C. Rankin, J.D.,P.E.
See my recent comment on Bug 1016. ;-)
Tim
On 06/24/2012 05:00 PM, Timothy Pearson wrote:
On 06/24/2012 04:50 PM, David C. Rankin wrote:
Tim,
Just for reference, I've tried this both with the current code and with the commit _reverted_ (and both with/without) setting --qtdir=/opt/tqt3 (to force a manual find). In all cases, some logic somewhere is still writing the /opt/tqt3/lib64 location.
Also, I last built tqca-tls without issue on this x86_64 box on 6/4/12. So the change has been relatively recent.
-- David C. Rankin, J.D.,P.E.
See my recent comment on Bug 1016. ;-)
Tim
Next stupid question:
"How do I go about reverting specific commits in the build files?"
Is it best to do something in GIT to download the source without those commits? Revert the commits with new patches? What says the master?
Currently (and since 3.5.10 Qt3) Arch uses the following:
# fix /opt/qt/lib path [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${QTDIR}/src/Makefile [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${QTDIR}/tools/designer/designer/Makefile [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${QTDIR}/tools/designer/editor/Makefile [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${QTDIR}/tools/assistant/lib/Makefile [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" ${QTDIR}/tools/designer/uilib/Makefile
Qt3/TQt3 has built on Arch like this for years. Would just adding more along these lines be better than trying to manipulate GIT to get rid of the two commits?
Also, Arch isn't the only distro that uses lib instead of lib64 (lib is the standard). The filesystem hierarchy standard (FHS) makes clear that lib64 is an 'Alternate Format' for distros to use while expecting 'lib' to remain the standard. Arch is very particular about being FHS compliant with the standard as opposed to the alternate. Can those two commits be improved to work with both the FHS standard and alternate naming formats for lib? It just seem wrong to target support toward the alternate without retaining support for the standard.
I'll work to get it building around the commits. If you have thoughts on whether trying to do that with GIT or if new patches would be better, that would give me a good direction to go it.
Thanks for helping find the culprit :)
"How do I go about reverting specific commits in the build files?"
Use the --reverse parameter, like this:
cat a5dfd481.diff | patch -p1 --reverse --verbose --no-backup-if-mismatch || exit 1
I do that often when troubleshooting new problems that did not exist a day or two earlier.
Darrell
On 06/24/2012 05:40 PM, Darrell Anderson wrote:
Use the --reverse parameter, like this:
cat a5dfd481.diff | patch -p1 --reverse --verbose --no-backup-if-mismatch || exit 1
I do that often when troubleshooting new problems that did not exist a day or two earlier.
Darrell
All good. I just had to find what needed adjusting. Just frustrating doing the 2 steps forward 3 steps back dance when expecting to be able to move 2 steps forward in the few hours available.
If the changes help the majority, then they are good changes. If they can be made without impact to any -- even better. After the issue was found, I see how the problem was created, but I still don't understand why anybody would want a lib64 directory hanging out under the tqt3 directory. I can't see anybody ever having both a 32-bit and 64-bit version of TQt3 installed at the same time.
By my reading of FHS, that is the only reason you would every want the /lib<alternate> format to be used in the first place. However, if installing in /usr and your distro is one that uses /lib64 for libs in general on 64 bit installs, I can see wanting everything to end up in the same directory, but for installs in /opt, I just think it makes the directory look a lot messier to have lib64 hanging around.
By my reading of FHS, that is the only reason you would every want the /lib<alternate> format to be used in the first place. However, if installing in /usr and your distro is one that uses /lib64 for libs in general on 64 bit installs, I can see wanting everything to end up in the same directory, but for installs in /opt, I just think it makes the directory look a lot messier to have lib64 hanging around.
That is exactly why this PITA system exists: multi-lib support --- to install and run 32-bit software on 64-bit systems. One such app is WINE. For a long time the Adobe flash plugin was another such beast. I think Skype is 32-bit too.
Darrell
On 06/24/2012 06:05 PM, Darrell Anderson wrote:
That is exactly why this PITA system exists: multi-lib support --- to install and run 32-bit software on 64-bit systems. One such app is WINE. For a long time the Adobe flash plugin was another such beast. I think Skype is 32-bit too.
I think the commits that caused issue with arch should make a test of /lib and /usr/lib before hardcoding the /lib64 stuff. If it is an x86_64 box and /lib64 is present, then use lib64 in the makespec files, however if not found, then use the original /lib designation for the Qt lib location. That would have caught and corrected this snafu while still leaving the old behavior unaltered for x86_64 boxes with installs in /lib.
I have to get smarter on writing/understanding conditionals such as the mkspec generations -- at least then when something fails later, I don't have to waste 1/2 hunting and picking through the tree.
Thanks Darrell, Tim for your help!
On 24 Jun 2012, Darrell Anderson said:
"How do I go about reverting specific commits in the build files?"
Use the --reverse parameter, like this:
Or use 'git revert', or 'git revert --no-commit' if you prefer not to commit it automatically.
cat a5dfd481.diff | patch -p1 --reverse --verbose --no-backup-if-mismatch || exit 1
This is unreliable: git diffs are a superset of the format accepted by GNU patch (and some of the extensions can lead to *different output* with certain older versions of patch, not a failed patch application). If you want to apply git diffs by hand like patch does, use 'git apply'.
On 06/24/2012 05:00 PM, Timothy Pearson wrote:
See my recent comment on Bug 1016. ;-)
Tim
How do I find those commits to see what they did? I've looked through the last 7 commits at:
http://git.trinitydesktop.org/cgit/tqt3/log/
e.g:
http://git.trinitydesktop.org/cgit/tqt3/commit/?id=1ecf57d6cfc4c0f3703eef6c9...
But I can't find anything that lines up with:
Commits 4412d295 and 18696899
Where to look?
On 06/24/2012 05:29 PM, David C. Rankin wrote:
On 06/24/2012 05:00 PM, Timothy Pearson wrote:
See my recent comment on Bug 1016. ;-)
Tim
How do I find those commits to see what they did? I've looked through the last 7 commits at:
http://git.trinitydesktop.org/cgit/tqt3/log/
e.g:
http://git.trinitydesktop.org/cgit/tqt3/commit/?id=1ecf57d6cfc4c0f3703eef6c9...
But I can't find anything that lines up with:
Commits 4412d295 and 18696899
Where to look?
Found them -- I was looking in the wrong place (typical :)
http://www.trinitydesktop.org/patches/
On 06/24/2012 05:00 PM, Timothy Pearson wrote:
See my recent comment on Bug 1016. ;-)
Tim
How do I find those commits to see what they did? I've looked through the last 7 commits at:
http://git.trinitydesktop.org/cgit/tqt3/log/
e.g:
http://git.trinitydesktop.org/cgit/tqt3/commit/?id=1ecf57d6cfc4c0f3703eef6c9...
But I can't find anything that lines up with:
Commits 4412d295 and 18696899
Where to look?
The master patch list at http://www.trinitydesktop.org/patches
Also, what you should do is not try to do anything with GIT iteself, but simply create a patch file (i.e. tqt3-lib-location.diff) which reverses the changes in the GIT commit, and apply it as part of your build process.
Tim
On 06/24/2012 05:37 PM, Timothy Pearson wrote:
The master patch list at http://www.trinitydesktop.org/patches
Also, what you should do is not try to do anything with GIT iteself, but simply create a patch file (i.e. tqt3-lib-location.diff) which reverses the changes in the GIT commit, and apply it as part of your build process.
Tim
I got it -- I wall just have to patch the mkspec for linux-g++-64 when I build TQt3. Simple patch -- just took a while to find the issue.
I have tqca-tls building now after editing the mkspec.
I got it -- I wall just have to patch the mkspec for linux-g++-64 when I build TQt3. Simple patch -- just took a while to find the issue.
I have tqca-tls building now after editing the mkspec.
David, do you need to patch mkspec? I ran into the same (or similar) problem last week. The solution is to use the respective (T)Qt3 "platform" configure option:
./configure \ ... -platform ${PLATFORM} \ ...
Where ${PLATFORM} is defined in your build script. For Slackware I do this:
if [ "$LIBDIRSUFFIX" = "64" ]; then PLATFORM="linux-g++-${LIBDIRSUFFIX}" else PLATFORM="linux-g++" fi
As Arch does not use a suffix, possibly all you need do is this:
./configure \ ... -platform linux-g++ \ ...
Darrell
On 06/24/2012 05:58 PM, Darrell Anderson wrote:
I got it -- I wall just have to patch the mkspec for linux-g++-64 when I build TQt3. Simple patch -- just took a while to find the issue.
I have tqca-tls building now after editing the mkspec.
David, do you need to patch mkspec? I ran into the same (or similar) problem last week. The solution is to use the respective (T)Qt3 "platform" configure option:
./configure \ ... -platform ${PLATFORM} \ ...
Where ${PLATFORM} is defined in your build script. For Slackware I do this:
if [ "$LIBDIRSUFFIX" = "64" ]; then PLATFORM="linux-g++-${LIBDIRSUFFIX}" else PLATFORM="linux-g++" fi
As Arch does not use a suffix, possibly all you need do is this:
./configure \ ... -platform linux-g++ \ ...
Darrell
To solve the whole issue with tqca-tls, I just had to edit:
/opt/tqt3/mkspecs/linux-g++-64/qmake.conf
and change:
QMAKE_LIBDIR_QT = $(QTDIR)/lib64
back to:
QMAKE_LIBDIR_QT = $(QTDIR)/lib
Like I said, I still don't see why you would every want a $(QTDIR)/lib64 unless you want to install TQt3 in /usr. If a majority use /usr/lib64, then it is a good change. It was just frustrating as all getout trying to find where in the heck the new **/lib64 stuff was coming from. I would never in 100 years found it in mkspecs/linux-g++-64/qmake.conf. I dorked with building tqca-tls every which way to Sunday and still could make it expose where that 64 was coming from. That's just my shortcoming in understanding how the Qt bits get pulled from the mkspec dirs. I know now :)
On 06/24/2012 04:14 PM, Timothy Pearson wrote:
On 06/24/2012 12:46 PM, David C. Rankin wrote:
So somewhere something is not getting the proper directory set to allow TQt to be found. How can I hack ./configure to force it to find TQt in the proper location?
Do you set QTDIR for your builds? I need to know because the autodetection logic is pretty much split into two parts, one path for if QTDIR is set and a different path if it is not.
Thanks!
Tim
Damnit!
Found it! It is the pkgconfig file installed by TQt3 that is FUBAR!
16:34 archangel:/dat_e/ch47/david/build> cat ../opt/tqt3/lib/pkgconfig/tqt-mt.pc prefix=/opt/tqt3 exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include qt_config=qt warn_on release incremental link_prl nocrosscompiler dlopen_opengl minimal-config small-config medium-config large-config full-config styles tools kernel widgets dialogs iconview workspace inputmethod network canvas table xml opengl sql release dll thread system-mng system-jpeg system-png gif system-zlib nis cups bigcodecs x11sm xshape xinerama xcursor xrandr xrender xftfreetype xkb inputmethod dylib create_prl link_prl qt warn_on depend_includepath qmake_cache x11 x11inc create_libtool create_pc moc x11lib
Name: TQt Description: Libtqt-mt.so.3.3.8 Library Version: 3.3.8 Libs: -L${libdir} -ltqt-mt -L/usr/lib/mysql -L/usr/X11R6/lib64 -lpq -lmysqlclient -lz -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread Cflags: -DQT_SHARED -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -D_REENTRANT -I${includedir}
Whatever logic writes the pkgconfig for TQt3 is borked. It is writing that there is a -L/usr/X11R6/lib64 when that is just 'wrong'.
On 06/24/2012 04:36 PM, David C. Rankin wrote:
Damnit!
Found it! It is the pkgconfig file installed by TQt3 that is FUBAR!
Strike that -- I'm dyslexic today :( That is the X11R6/lib64 that doesn't exist either...
-
Darrell Anderson -
David C. Rankin -
E. Liddell -
Nix -
Timothy Pearson