26 Jan
2012
26 Jan
'12
1:22 a.m.
After building tqt3, to /opt/trinity and tqtinterface to /usr i am
attempting to build arts (git). It fails just after reaching 100%. Any
ideas?
[100%] Building CXX object
qtmcop/CMakeFiles/qtmcop-shared.dir/qiomanager.cc.o
cd /mnt/sda6/build/qtmcop && /usr/bin/c++ -Dqtmcop_shared_EXPORTS
-DHAVE_CONFIG_H -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -O2
-march=i486 -mtune=i686 -fPIC -I/usr/local/include/tqt
-I/mnt/sda6/build/qtmcop -I/mnt/sda6/build/mcop
-I/mnt/sda7/trinity-3.5.13/git/tde/main/dependencies/arts/mcop -include
tqt.h -o CMakeFiles/qtmcop-shared.dir/qiomanager.cc.o -c
/mnt/sda7/trinity-3.5.13/git/tde/main/dependencies/arts/qtmcop/qiomanager.cc
In file included from
/mnt/sda7/trinity-3.5.13/git/tde/main/dependencies/arts/qtmcop/qiomanager.cc:299:0:
/mnt/sda6/build/qtmcop/qiomanager_p.moc: In static member function ‘static
QMetaObject* Arts::QIOWatch::staticMetaObject()’:
/mnt/sda6/build/qtmcop/qiomanager_p.moc:55:18: error: ‘TQUParameter’ does
not name a type
/mnt/sda6/build/qtmcop/qiomanager_p.moc:58:18: error: ‘TQUMethod’ does not
name a type
/mnt/sda6/build/qtmcop/qiomanager_p.moc:60:20: error: ‘slot_0’ was not
declared in this scope
/mnt/sda6/build/qtmcop/qiomanager_p.moc: In static member function ‘static
QMetaObject* Arts::QTimeWatch::staticMetaObject()’:
/mnt/sda6/build/qtmcop/qiomanager_p.moc:140:18: error: ‘TQUMethod’ does not
name a type
/mnt/sda6/build/qtmcop/qiomanager_p.moc:142:17: error: ‘slot_0’ was not
declared in this scope
make[2]: *** [qtmcop/CMakeFiles/qtmcop-shared.dir/qiomanager.cc.o] Error 1
make[2]: Leaving directory `/mnt/sda6/build'
make[1]: *** [qtmcop/CMakeFiles/qtmcop-shared.dir/all] Error 2
make[1]: Leaving directory `/mnt/sda6/build'
make: *** [all] Error 2
# find /opt/ -name "moc" -type f
/opt/trinity/lib/qt3-3.3.8.d/bin/moc
# find /usr/ -name "*moc*" -type f
/usr/local/bin/moc-tqt
/usr/local/bin/tmoc
/usr/bin/moc-tqt
/usr/bin/tmoc
# echo $PATH
/opt/trinity/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:/opt/trinity/lib/qt3-3.3.8.d/bin:/opt/trinity/lib/qt3-3.3.8.d/bin
26 Jan
26 Jan
3:11 a.m.
New subject: [trinity-devel] qiomanager_p.moc vars not declared
After building tqt3, to /opt/trinity and
tqtinterface to /usr i am attempting to build arts (git). It
fails just after reaching 100%. Any ideas?
Yes. The errors looks similar to those we have been discussing with tdelibs failing to
build with tqt3. I think the primary problem is the cmake checks are stuck to looking in
/usr before deciding whether to set the cmake TQT_REAL_TQT internal variable. You'll
find that variable in the tqtinterface CMakeCache.txt file when building tqtinterface and
should be set to 1. Look in your tqtinterface CMakeCache.txt file to verify that variable
is being set. If not then you are experiencing a similar problem with tqt3.
Until Tim decides on a long-term fix, I am using a simple patch:
http://trinity-devel.pearsoncomputing.net/?0::5126
I was able to build arts before this patch, so perhaps your build failure is different.
Basically, by removing if( QT_PREFIX_DIR STREQUAL "/usr" ) I can build tdelibs
with tqt3.
There was a recent patch merged with GIT that affected building arts with
-DWITH_GCC_VISIBILITY=ON. I believe the patch was merged with GIT on Jan. 21. If you are
using a GIT snapshot earlier than that date, try building with -DWITH_GCC_VISIBILITY=OFF
before updating your local GIT repository.
You also could try building tqt3 to install to /usr and see what happens.
Another option is to build qt3 rather than tqt3. I think there remain a few kinks with
tqt3. When Tim finds the time I'm sure we'll rapidly quash those bugs.
Darrell
1:12 p.m.
New subject: [trinity-devel] qiomanager_p.moc vars not declared
Thanks Darrell.
I decided to go for installing everything to /usr as this will be for a
custom stripped slackware distro with only lxde and Trinity. I also went
with qt3. Everything compiled nicely for me. Arts seems to be happy in this
setup now ... at least i will take the final output from building arts to
be an indication of success:
cd /mnt/sda6/build/qtmcop && /usr/bin/cmake -E cmake_symlink_library
libqtmcop.so.1.0.0 libqtmcop.so.1 libqtmcop.so
make[2]: Leaving directory `/mnt/sda6/build'
/usr/bin/cmake -E cmake_progress_report /mnt/sda6/build/CMakeFiles 98
[100%] Built target qtmcop-shared
make[1]: Leaving directory `/mnt/sda6/build'
/usr/bin/cmake -E cmake_progress_start /mnt/sda6/build/CMakeFiles 0
Jay
On Thu, Jan 26, 2012 at 3:11 AM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;wrote:
After building
tqt3, to /opt/trinity and
tqtinterface to /usr i am attempting to build arts (git). It
fails just after reaching 100%. Any ideas?
Yes. The errors looks similar to those we have been discussing with
tdelibs failing to build with tqt3. I think the primary problem is the
cmake checks are stuck to looking in /usr before deciding whether to set
the cmake TQT_REAL_TQT internal variable. You'll find that variable in the
tqtinterface CMakeCache.txt file when building tqtinterface and should be
set to 1. Look in your tqtinterface CMakeCache.txt file to verify that
variable is being set. If not then you are experiencing a similar problem
with tqt3.
Until Tim decides on a long-term fix, I am using a simple patch:
http://trinity-devel.pearsoncomputing.net/?0::5126
I was able to build arts before this patch, so perhaps your build failure
is different.
Basically, by removing if( QT_PREFIX_DIR STREQUAL "/usr" ) I can build
tdelibs with tqt3.
There was a recent patch merged with GIT that affected building arts with
-DWITH_GCC_VISIBILITY=ON. I believe the patch was merged with GIT on Jan.
21. If you are using a GIT snapshot earlier than that date, try building
with -DWITH_GCC_VISIBILITY=OFF before updating your local GIT repository.
You also could try building tqt3 to install to /usr and see what happens.
Another option is to build qt3 rather than tqt3. I think there remain a
few kinks with tqt3. When Tim finds the time I'm sure we'll rapidly quash
those bugs.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
6:11 p.m.
New subject: [trinity-devel] qiomanager_p.moc vars not declared
I decided to go for installing everything to /usr as
this
will be for a custom stripped slackware distro with only
lxde and Trinity. I also went with qt3. Everything
compiled nicely for me. Arts seems to be happy in this setup
now ... at least i will take the final output from building
arts to be an indication of success:
Yes, just for those who watch the list, installing to /usr is fine as long as KDE4 is not
installed to /usr.
There are a few Slackers here. Welcome!
For myself, although I don't use KDE4, I limit my Slackware builds to /opt/trinity
because my packages are used by other people. As the stock Slackware comes with KDE4, I
have to accommodate that. I also test and watch for potential conflicts with KDE4. When
R14 is released, I likely will build a special set of packages for myself to install to
/usr.
As you are a Slackware user, I welcome any help you can offer the Trinity project. We need
more exhaustive testing. Install to /usr for yourself, but if you have the time and spare
CPU cycles, please help to build GIT in various scenarios to find any breakage. Finding
that breakage now will mean no breakage when R14 is released.
In addition to testing various build scenarios, we need better testing to ensure no
conflicts with KDE4.
tqt3 will be the future and eventually will replace qt3. I build with both right now for
testing purposes.
As you mention Trinity and LXDE in the same sentence, I presume you are interested in
light weight desktop environments. I am interested in any information you might have that
will help create a "Trinity Light" for older hardware. The idea of Trinity Light
is not so much a separate or unique build of Trinity, although that could happen, but
includes any ideas to customize Trinity for older hardware. Once upon a time I addressed
the topic with KDE 3 (http://humanreadable.nfshost.com/howtos/optimizing_kde.htm), but
I'd like to see a wiki article with various tips and ideas to get Trinity to run on
old hardware, which should include build options. People running old hardware are unlikely
to need every option built into Trinity and any related information we accumulate about
these topics will help.
Darrell
9:32 p.m.
New subject: [trinity-devel] qiomanager_p.moc vars not declared
Thanks.
I found today that using only qt3 is not going to cut it when wanting to
build other packages such as tdebindings. I got the base Trinity packages
compiled, but building tdebindings failed. Time to go back and build tqt3
and try with that. At the moment when compiling tqt3 to /usr it fails
during make trying to find libtqt-mt.so.3
I am one of the maintainers of Porteus, a lightweight slack based distro
born from the inactivity of slax. My current Trinity base package weighs in
at 55Mb (compressed). kdep-apps and koffice are separated to afford users
the choice. Stripped back to just the Trinity package and base requirements
the final iso would be around 170Mb.
Jay
On Thu, Jan 26, 2012 at 6:11 PM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;wrote:
I decided to
go for installing everything to /usr as this
will be for a custom stripped slackware distro with only
lxde and Trinity. I also went with qt3. Everything
compiled nicely for me. Arts seems to be happy in this setup
now ... at least i will take the final output from building
arts to be an indication of success:
Yes, just for those who watch the list, installing to /usr is fine as long
as KDE4 is not installed to /usr.
There are a few Slackers here. Welcome!
For myself, although I don't use KDE4, I limit my Slackware builds to
/opt/trinity because my packages are used by other people. As the stock
Slackware comes with KDE4, I have to accommodate that. I also test and
watch for potential conflicts with KDE4. When R14 is released, I likely
will build a special set of packages for myself to install to /usr.
As you are a Slackware user, I welcome any help you can offer the Trinity
project. We need more exhaustive testing. Install to /usr for yourself, but
if you have the time and spare CPU cycles, please help to build GIT in
various scenarios to find any breakage. Finding that breakage now will mean
no breakage when R14 is released.
In addition to testing various build scenarios, we need better testing to
ensure no conflicts with KDE4.
tqt3 will be the future and eventually will replace qt3. I build with both
right now for testing purposes.
As you mention Trinity and LXDE in the same sentence, I presume you are
interested in light weight desktop environments. I am interested in any
information you might have that will help create a "Trinity Light" for
older hardware. The idea of Trinity Light is not so much a separate or
unique build of Trinity, although that could happen, but includes any ideas
to customize Trinity for older hardware. Once upon a time I addressed the
topic with KDE 3 (
http://humanreadable.nfshost.com/howtos/optimizing_kde.htm), but I'd like
to see a wiki article with various tips and ideas to get Trinity to run on
old hardware, which should include build options. People running old
hardware are unlikely to need every option built into Trinity and any
related information we accumulate about these topics will help.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
11:29 p.m.
New subject: [trinity-devel] qiomanager_p.moc vars not declared
I found today that using only qt3 is not going to cut
it
when wanting to build other packages such as tdebindings. I
got the base Trinity packages compiled, but building
tdebindings failed. Time to go back and build tqt3 and try
with that. At the moment when compiling tqt3 to /usr it
fails during make trying to find libtqt-mt.so.3
Yes, if you review the list discussions from several days ago you'll notice that much
of the recent discussions started when I posted I could not build tdebindings with qt3.
:)
tdebindings, nee kdebindings, built fine in 3.5.13. The build problems started some time
after that. Tim is aware of the problems.
If you skip tdebindings you should find that everything else builds, although some patches
are required. I get all core and main suite packages to build with qt3.
Darrell
4684
days inactive
4684
days old
5 comments
2 participants
participants (2)
-
Darrell Anderson -
Jay