All,
A year or so ago, building with make -j >1 was advised against due to the
potential to produce spurious build failures, etc. Has that changed? The build
time savings is attractive, but if there hasn't been any testing, best to stick
to -j1 for now?
--
David C. Rankin, J.D.,P.E.
>This sounds like a problem that has been experienced before and
>was fixed by
>patching the end of a cmake file, but I do not recall the
>specifics. Any one
>recall where/what cmake file is responsible for including libdbus-
>tqt-1?
I'm no compiler expert, not even close, sunny or rainy day. Unless
Arch is REALLY different from other distros, I would pause to
consider what else might be causing the errors. That is, the rest
of the team is building full package sets without the same errors.
That said, yes, you could have stumbled across a corner case that
Arch exposes. We've seen that before around here. :)
Darrell
All,
After getting through the CMake issues with tdebase and cmake 2.8.12.1, I have
run into another scope error. The error is with gcc 4.8.2:
[ 57%] Building CXX object
kicker/applets/lockout/CMakeFiles/lockout_panelapplet-module.dir/lockout.cpp.o
/build/tde-tdebase/src/tdebase/kicker/applets/lockout/lockout.cpp: In member
function 'void Lockout::slotButtonOrder()':
/build/tde-tdebase/src/tdebase/kicker/applets/lockout/lockout.cpp:297:4: error:
'KConfig' was not declared in this scope
KConfig* conf = config();
^
/build/tde-tdebase/src/tdebase/kicker/applets/lockout/lockout.cpp:297:13: error:
'conf' was not declared in this scope
KConfig* conf = config();
^
kicker/applets/lockout/CMakeFiles/lockout_panelapplet-module.dir/build.make:63:
recipe for target
'kicker/applets/lockout/CMakeFiles/lockout_panelapplet-module.dir/lockout.cpp.o'
failed
I recall a number of these from prior builds. However, this time I decided to
build without -DCMAKE_CXX_FLAGS="-fpermissive". There appear to be several more
of these scope issues in the code. I can't recall how we were fixing these, but
I recall most being simple. I'll look back through the list and bugzilla. If you
know off-hand how to correct this -- let me know.
Also, do we want to open bug reports on the scope failures if we cannot
correct them with a patch here on the list? (do we want to file ALL of these so
they are being actively tracked?
--
David C. Rankin, J.D.,P.E.
>It failed again:
>
>Any thoughts?
My memory is slow most days and other days is not fast. I now
remember a similar bug hitting me a while back when trying to build
3.5.13.2:
http://bugs.trinitydesktop.org/show_bug.cgi?id=1727
The problem turned out to be the way I had my build scripts
configured. I hadn't paid attention for months and discovered I was
installing dbus-1-tqt to /usr. Yet the remainder of my build
scripts were built to install to /opt/trinity. Therefore the other
build scripts were looking for the dbus-1-tqt files in /opt/trinity
(${PREFIX}). After I commented out those hard-coded lines I no
longer had any problems. You can still see them commented out in
the coppies you got from me.
Now that specific failure was with 3.5.13.2, not R14. Yet who
knows, could be something similar. Check into where your dbus-1-tqt
files are actually being installed.
BTW, make sure you are not concurrently using WITH_HAL and
WITH_TDEHWLIB. One or the other.
Darrell
All,
Linking CXX shared library libtdeinit_kicker.so
/usr/bin/ld: cannot find -ldbus-tqt-1
This looks like a pkgconfig issue. The dbus-tqt-1 library is installed at:
/opt/trinity/lib/libdbus-tqt-1.so
/opt/trinity/lib/libdbus-tqt-1.la # libtool file also there
The package config file file for dbus-tqt is here:
/opt/trinity/lib/pkgconfig/dbus-tqt.pc
prefix=/opt/trinity
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: dbus-tqt-1
Description: D-BUS TQt bindings
Version: R14.0.0
Requires: dbus-1
Libs: -L${libdir} -ldbus-tqt-1 -ldbus-1
Cflags: -I${includedir} -I${includedir}/dbus-1.0
So something in cmake is not getting the correct information to where it needs
to go. The error message is this:
[ 55%] Building CXX object
kicker/kicker/CMakeFiles/tdeinit_kicker-shared.dir/dummy.cpp.o
Linking CXX shared library libtdeinit_kicker.so
/usr/bin/ld: cannot find -ldbus-tqt-1
collect2: error: ld returned 1 exit status
kicker/kicker/CMakeFiles/tdeinit_kicker-shared.dir/build.make:108: recipe for
target 'kicker/kicker/libtdeinit_kicker.so' failed
make[2]: *** [kicker/kicker/libtdeinit_kicker.so] Error 1
CMakeFiles/Makefile2:16442: recipe for target
'kicker/kicker/CMakeFiles/tdeinit_kicker-shared.dir/all' failed
make[1]: *** [kicker/kicker/CMakeFiles/tdeinit_kicker-shared.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2
checking the /kicker/kicker/CMakeFiles/tdeinit_kicker-shared.dir/link.txt:
/usr/bin/c++ -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include
tqt.h -I/opt/tqt3/include -I/usr/include/tqt -DQT_NO_ASCII_CAST
-DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -g -Wl,--no-undefined -shared
-Wl,-soname,libtdeinit_kicker.so -o libtdeinit_kicker.so
CMakeFiles/tdeinit_kicker-shared.dir/dummy.cpp.o -L/opt/tqt3/lib
-Wl,-whole-archive core/libkicker_core.a -Wl,-no-whole-archive
buttons/libkicker_buttons.a ui/libkicker_ui.a
../libkicker/libkickermain.so.1.0.0 /opt/trinity/lib/libtdeabc.so.1.2.0
/opt/trinity/lib/libtdeutils.so.1.2.0 ../../libkonq/libkonq.so.4.2.0
../../tdmlib/libdmctl.a -lXau interfaces/libkickoffsearch_interfaces.so.0.0.0
-ldbus-tqt-1 -ldbus-1 /opt/trinity/lib/libvcard.so.0.0.0
/opt/trinity/lib/libtderesources.so.1.2.0 /opt/trinity/lib/libtdeparts.so.2.1.0
/opt/trinity/lib/libtdeio.so.14.0.0 /opt/trinity/lib/libtdeui.so.14.0.0
-lfreetype -lfontconfig /opt/trinity/lib/libtdesu.so.14.0.0 -lutil
/opt/trinity/lib/libtdewalletclient.so.1.0.1
/opt/trinity/lib/libtdecore.so.14.0.0 /opt/trinity/lib/libDCOP.so.14.0.0
/opt/trinity/lib/libtdefx.so.14.0.0 -ltqt -ltqt-mt -lXrender -lX11 -lc -lz -lidn
-lXcomposite -lICE -lSM -lacl
-Wl,-rpath,/opt/tqt3/lib:/build/tde-tdebase/src/build/kicker/libkicker:/opt/trinity/lib:/build/tde-tdebase/src/build/libkonq:/build/tde-tdebase/src/build/kicker/kicker/interfaces:
Interestingly it has -L/opt/tqt3/lib but NOT -L/opt/trinity/lib. Down further it
lists: -ldbus-tqt-1 -ldbus-1, so if it could find -ldbus-tqt-1 the problem
should be solved.
What can I add to CMakeLists.txt to force it to include -L/opt/trinity/lib as
the lib dir? /etc/ld.so.conf.d/trinity.conf already contains:
/opt/trinity/lib
/opt/trinity/lib/trinity
So from what I'm seeing, it should automatically include it.
--
David C. Rankin, J.D.,P.E.
>Do any Trinity users use scrollkeeper? Trinity maintains legacy
>KDE3 code to support scrollkeeper, but scrollkeeper hasn't been
>supported in a decade. The successor is something called rarian,
>which Trinity does not support and seems to be a GNOME app.
>
>Do we want to continue scrollkeeper support?
>
>Further, do we want to support metasearch engines at all? We
>maintain kerry, which is a beagle front-end. Beagle has not been
>supported in a number of years.
So nobody uses scrollkeeper or beagle?
Should I delete the sources and see who screams?
Darrell
>> I don't know what needs to be fixed, but obviously if Darrel is
>building
>> with GCC_VISIBILITY=ON and with gcc 4.8.2-7 that is causing
>failure, then
>> we need to figure out what the root of the problem is and then
>fix it with
>> preprocessor conditional or fix the code. I don't understand the
>> GCC_VISIBILITY implications entirely, but depending on the
>setting build
>> failures are occurring.
>
>On Debian Jessie is gcc 4.8.2, tdebase is built
>with -DWITH_GCC_VISIBILITY="ON" and the problem does not occur.
Slackware 14.1 uses 4.8.2 and the last I tried a few weeks ago
everything built.
I have no idea whether glib main loop makes a difference, but I
always build TQt3 with -glibmainloop.
The only packages I enable gcc visibility are arts, tdelibs,
tdebase. If I recall correctly, visibility support never was
finished on non-core packages.
Darrell
>That is what I'm talking about - needed patches that fix basic
>flaws in the code
>that were traditionally applied to the kde3 codebase that have
>never been
>incorporated into the tde git tree.
Needed by whom?
Darrell