23 Jun
2012
23 Jun
'12
5:31 a.m.
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?
--
David C. Rankin, J.D.,P.E.
23 Jun
23 Jun
7:52 a.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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
24 Jun
24 Jun
3:32 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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.
--
David C. Rankin, J.D.,P.E.
4:13 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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:
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.
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.
5:45 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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
8:54 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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
25 Jun
25 Jun
7:57 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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.
--
David C. Rankin, J.D.,P.E.
24 Jun
24 Jun
5:46 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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?
--
David C. Rankin, J.D.,P.E.
8:59 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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;
--
David C. Rankin, J.D.,P.E.
9:14 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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
9:33 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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???
--
David C. Rankin, J.D.,P.E.
9:50 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 04:33 PM, David C. Rankin wrote:
On 06/24/2012 04:14 PM, Timothy Pearson 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.
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.
--
David C. Rankin, J.D.,P.E.
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???
9:51 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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.
10 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 04:50 PM, David C. Rankin wrote:
See my recent comment on Bug 1016. ;-)
Tim
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.
10:22 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 05:00 PM, Timothy Pearson wrote:
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 :)
--
David C. Rankin, J.D.,P.E.
On 06/24/2012
04:50 PM, David C. Rankin wrote:
See my recent comment on Bug 1016. ;-)
Tim
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.
10:40 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
"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
11 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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.
--
David C. Rankin, J.D.,P.E.
11:05 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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
25 Jun
25 Jun
4:14 a.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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!
--
David C. Rankin, J.D.,P.E.
3:16 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 24 Jun 2012, Darrell Anderson said:
Or use 'git revert', or 'git revert --no-commit' if you prefer not to
commit it automatically.
"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
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'.
--
NULL && (void)
24 Jun
24 Jun
10:29 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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=1ecf57d6cfc4c0f3703eef6c…
But I can't find anything that lines up with:
Commits 4412d295 and 18696899
Where to look?
--
David C. Rankin, J.D.,P.E.
10:36 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 05:29 PM, David C. Rankin wrote:
On 06/24/2012 05:00 PM, Timothy Pearson wrote:
Found them -- I was looking in the wrong place (typical :)
http://www.trinitydesktop.org/patches/
--
David C. Rankin, J.D.,P.E.
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=1ecf57d6cfc4c0f3703eef6c…
But I can't find anything that lines up with:
Commits 4412d295 and 18696899
Where to look?
10:37 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 05:00 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
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=1ecf57d6cfc4c0f3703eef6c…
But I can't find anything that lines up with:
Commits 4412d295 and 18696899
Where to look?
10:51 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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.
--
David C. Rankin, J.D.,P.E.
10:58 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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
11:06 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 05:58 PM, Darrell Anderson wrote:
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 :)
--
David C. Rankin, J.D.,P.E.
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
9:36 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
On 06/24/2012 04:14 PM, Timothy Pearson wrote:
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'.
--
David C. Rankin, J.D.,P.E.
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
9:39 p.m.
New subject: [trinity-devel] FTBFS tqca-tls (x86_64) can't find TQt3 (i686 builds?)
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...
--
David C. Rankin, J.D.,P.E.
4333
days inactive
4335
days old
27 comments
5 participants
participants (5)
-
Darrell Anderson -
David C. Rankin -
E. Liddell -
Nix -
Timothy Pearson