24 Jan
2012
24 Jan
'12
3:19 p.m.
Well that
doesn't look right. :-) Can you also post
your tmoc and
tqt-replace-stream files (and also verify that there is only
one of each
file on your system)?
http://humanreadable.nfshost.com/trinity/build_logs/tmoc
http://humanreadable.nfshost.com/trinity/build_logs/tqt-replace
http://humanreadable.nfshost.com/trinity/build_logs/tqt-replace-stream Darrell
OK, I see the problem. Now to figure out why it happens... :-)
In the tqtinterface qtinterface/CMakeLists.txt file, there is an if
statement that looks like this:
if ( NOT HAVE_REAL_TQT )
For anything to work properly on native tqt3, HAVE_REAL_TQT *must* be set.
Yet in the CMakeCache.txt file you sent earlier, HAVE_REAL_TQT does not
show up anywhere.
If HAVE_REAL_TQT was set, the string "Native TQt3 detected" needs to show
up in the tqtinterface build log. Once again I don't see it anywhere in
the build log you sent earlier.
There is a chunk of logic in the tqtinterface ConfigureChecks.cmake file
that looks like this:
if( NOT DEFINED QT_INCLUDE_DIR )
if( QT_PREFIX_DIR STREQUAL "/usr" )
if( EXISTS "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( HAVE_REAL_TQT ON CACHE BOOL "Native TQt3 detected" )
Note the number of ways that the set(HAVE_REAL_TQT) statement can be
bypassed. This logic is incomplete and needs to be repaired.
Specifically, I will need to figure out a way for CMake to load the
qglobal.h file and unambiguously determine the nature of the Qt version
installed.
Tim
24 Jan
24 Jan
3:29 p.m.
New subject: [trinity-devel] tdelibs FTBFS with tqt3
Well that doesn't look right. :-) Can you also
post
your tmoc and
tqt-replace-stream files (and also verify that there is only
one of each
file on your system)?
http://humanreadable.nfshost.com/trinity/build_logs/tmoc
http://humanreadable.nfshost.com/trinity/build_logs/tqt-replace
http://humanreadable.nfshost.com/trinity/build_logs/tqt-replace-stream Darrell
OK, I see the problem. Now to figure out why it happens... :-)
In the tqtinterface qtinterface/CMakeLists.txt file, there is an if
statement that looks like this:
if ( NOT HAVE_REAL_TQT )
For anything to work properly on native tqt3, HAVE_REAL_TQT *must* be set.
Yet in the CMakeCache.txt file you sent earlier, HAVE_REAL_TQT does not
show up anywhere.
If HAVE_REAL_TQT was set, the string "Native TQt3 detected" needs to show
up in the tqtinterface build log. Once again I don't see it anywhere in
the build log you sent earlier.
There is a chunk of logic in the tqtinterface ConfigureChecks.cmake file
that looks like this:
if( NOT DEFINED QT_INCLUDE_DIR )
if( QT_PREFIX_DIR STREQUAL "/usr" )
if( EXISTS "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( HAVE_REAL_TQT ON CACHE BOOL "Native TQt3 detected" )
Note the number of ways that the set(HAVE_REAL_TQT) statement can be
bypassed. This logic is incomplete and needs to be repaired.
Specifically, I will need to figure out a way for CMake to load the
qglobal.h file and unambiguously determine the nature of the Qt version
installed.
Tim 
4:36 p.m.
New subject: [trinity-devel] tdelibs FTBFS with tqt3
OK, I see the
problem. Now to figure out why it
happens... :-)
In the tqtinterface qtinterface/CMakeLists.txt file,
there is an if
statement that looks like this:
if ( NOT HAVE_REAL_TQT )
For anything to work properly on native tqt3,
HAVE_REAL_TQT *must* be set.
Yet in the CMakeCache.txt file you sent earlier,
HAVE_REAL_TQT does not
show up anywhere.
If HAVE_REAL_TQT was set, the string "Native TQt3
detected" needs to
show
up in the tqtinterface build log. Once again I
don't see it anywhere in
the build log you sent earlier.
There is a chunk of logic in the tqtinterface
ConfigureChecks.cmake file
that looks like this:
if( NOT DEFINED QT_INCLUDE_DIR )
if( QT_PREFIX_DIR STREQUAL "/usr" )
if( EXISTS
"${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( QT_INCLUDE_DIR
"${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( HAVE_REAL_TQT ON
CACHE BOOL
"Native TQt3 detected" )
Note the number of ways that the set(HAVE_REAL_TQT)
statement can be
bypassed. This logic is incomplete and needs to
be repaired.
Specifically, I will need to figure out a way for CMake
to load the
qglobal.h file and unambiguously determine the
nature
of the Qt version
> installed.
7:45 p.m.
New subject: [trinity-devel] tdelibs FTBFS with tqt3
Yup, I see the problem now that you pointed me to the
cmake
logic. The cmake logic is like this:
if( NOT DEFINED QT_INCLUDE_DIR )
if( QT_PREFIX_DIR STREQUAL "/usr" )
if( EXISTS
"${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( QT_INCLUDE_DIR
"${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
set( HAVE_REAL_TQT ON CACHE BOOL
"Native TQt3 detected" )
else( )
set( QT_INCLUDE_DIR
"${QT_PREFIX_DIR}/include/qt${QT_VERSION}" )
endif( )
else( )
set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include"
)
endif( )
endif( )
qt_message( " QT_INCLUDE_DIR: ${QT_INCLUDE_DIR}" )
I don't have a ${PREFIX}/include/(t)qt${QT_VERSION} because
my build script installs the header files to
${PREFIX}/include. I did not specify -headerdir in my (t)qt3
configure options. The logic tests fail without that
specific include directory name.
I notice a few things:
1) I can specify -headerdir to the expected location. If
that is the only test, then we need to update the wiki to
ensure everybody always specifies -headerdir =
${PREFIX}/include/(t)qt${QT_VERSION}.
2) To detect when a user builds to install the header files
to ${PREFIX}/include rather than
${PREFIX}/include/(t)qt${QT_VERSION}, a different test is
needed. Possibly detect whether qt-mt.pc or tqt-mt.pc is
installed in the $PKGCONFIG locations. The other day
you showed me how to use pkg-config --cflags-only-I, so
perhaps that is the better test to determine where the
header files are installed and which version of (t)qt3.
3) In Slackware, and probably some other distros too, the
traditional installation location for qt3 was
${PREFIX}/lib${LIBDIRSUFFIX}/${PRGNAM}-${VERSION}. A
challenge with that location is the requirement to create
several sym links to standard locations. Therefore I changed
a lot of that in my new GIT (t)qt3 build scripts to avoid
needing to create all of those sym links. Yet even with that
install location, there will not be an
${PREFIX}/lib${LIBDIRSUFFIX}/$PRGNAM-$VERSION/include/(t)qt{$VERSION}
directory, only
${PREFIX}/lib${LIBDIRSUFFIX}/$PRGNAM-$VERSION/include. So
perhaps the pkg-config option is best.
For now the solution might be as easy as building both qt3
and tqt3 with -headerdir specified to
${PREFIX}/include/(t)qt${QT_VERSION}. I will try that
tonight and post the results. :)
Thanks for your help!
Tim,
Note: I rebuilt tqt3 with -headerdir = /opt/trinity/include/tqt3. The cmake logic
automatically failed because the native (t)qt3 tests apply only when QT_PREFIX_DIR
STREQUAL "/usr".
I wrote a simple patch (for me) to eliminate the /usr test:
============================================================
diff -urN tqtinterface/ConfigureChecks.cmake tqtinterface.new/ConfigureChecks.cmake
--- tqtinterface/ConfigureChecks.cmake 2012-01-24 19:27:56.000000000 -0600
+++ tqtinterface.new/ConfigureChecks.cmake 2012-01-24 19:44:32.000000000 -0600
@@ -47,13 +47,11 @@
# qt headers
if( NOT DEFINED QT_INCLUDE_DIR )
- if( QT_PREFIX_DIR STREQUAL "/usr" )
- if( EXISTS "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
- set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
- set( HAVE_REAL_TQT ON CACHE BOOL "Native TQt3 detected" )
- else( )
- set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include/qt${QT_VERSION}" )
- endif( )
+ if( EXISTS "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
+ set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include/tqt${QT_VERSION}" )
+ set( HAVE_REAL_TQT ON CACHE BOOL "Native TQt3 detected" )
+ elseif( EXISTS "${QT_PREFIX_DIR}/include/qt${QT_VERSION}" )
+ set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include/qt${QT_VERSION}" )
else( )
set( QT_INCLUDE_DIR "${QT_PREFIX_DIR}/include" )
endif( )
============================================================
Mybe the test for /usr should be deleted. There is no predicting where a person might
install (t)qt3. As the cmake process seems to detect where (t)qt3 is installed with
${QT_PREFIX_DIR}, perhaps deleting that /usr tst is the only change needed.
tdelibs built.
tqca-tls and tdebase will not build when I move the tqt3 headers to $PREFIX/include/tqt3.
tqca-tls failed with this error:
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.
When I edited the configure file to show the output the failures were much the same as I
saw with tdelibs. Basically tqca-tls can't find the tqt3 headers.
With the tqt3 headers installed at /opt/trinity/include/tqt3, NUMJOBS=-j3, tdebase fails
with this error:
tasklmbmenu.cpp:(.text+0x5c3): undefined reference to `KickerLib::blendColors(TQColor
const&, TQColor const&)'
With NUMJOBS=-j1, tdebase fails with this error:
cd /dev/shm/tdebase.build/kcontrol/kcontrol && /usr/bin/cmake -E cmake_link_script
CMakeFiles/kcontrol.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -march=i486 -mtune=i686 -fvisibility=hidden -fvisibility-inlines-hidden
-DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h
CMakeFiles/kcontrol.dir/kcontrol_tdeinit_executable.cpp.o -o kcontrol -rdynamic
-L/opt/trinity/lib libtdeinit_kcontrol.so /opt/trinity/lib/libkhtml.so.4.2.0
/opt/trinity/lib/libkutils.so.1.2.0 /opt/trinity/lib/libkparts.so.2.1.0
/opt/trinity/lib/libtdeprint.so.4.2.0 /opt/trinity/lib/libkio.so.4.2.0
/opt/trinity/lib/libtdeui.so.4.2.0 -lfreetype -lfontconfig
/opt/trinity/lib/libtdesu.so.4.2.0 -lutil /opt/trinity/lib/libkwalletclient.so.1.0.1
/opt/trinity/lib/libkjs.so.1.2.0 /opt/trinity/lib/libtdecore.so.4.2.0
/opt/trinity/lib/libDCOP.so.4.2.0 /opt/trinity/lib/libtdefx.so.4.2.0 -ltqt -ltqt-mt
-lXrender -lX11 -lz -lidn -lXcomposite -lXfixes -lICE -lSM -lpcre -ljpeg
-Wl,-rpath,/opt/trinity/lib:/dev/shm/tdebase.build/kcontrol/kcontrol:
CMakeFiles/kcontrol.dir/kcontrol_tdeinit_executable.cpp.o: In function `main':
kcontrol_tdeinit_executable.cpp:(.text+0x17): undefined reference to `kdemain'
collect2: ld returned 1 exit status
make[2]: *** [kcontrol/kcontrol/kcontrol] Error 1
make[2]: Leaving directory `/dev/shm/tdebase.build'
make[1]: *** [kcontrol/kcontrol/CMakeFiles/kcontrol.dir/all] Error 2
make[1]: Leaving directory `/dev/shm/tdebase.build'
make: *** [all] Error 2
Darrell
4720
days inactive
4721
days old
4 comments
2 participants
participants (2)
-
Darrell Anderson -
Timothy Pearson