tde-devels

devels@trinitydesktop.org

4 participants
3805 discussions

Re: [trinity-devel] [SOLVED]Re: [trinity-devel] tdelibs-tdecore FTBFS /usr/bin/ld: cannot find -ldbus-1-tqt
by Darrell Anderson 21 Jan '14

21 Jan '14

> Family: Phenom X4 > Version: AMD Phenom(tm) 9850 Quad-Core Processor > Max Speed: 2500 MHz I have a dual core. Darrell

2 1

Re: [trinity-devel] [SOLVED]Re: [trinity-devel] tdelibs-tdecore FTBFS /usr/bin/ld: cannot find -ldbus-1-tqt
by Darrell Anderson 21 Jan '14

21 Jan '14

>HOLY CRAP!! > > tdelibs built fine with the patch -- and in 7 minutes flat with >'make -j4'!!! > >Script Execution Time: 7 minutes - that is down from 27 min with - >j1 and this is on a 5 year old box. 7 minutes? Skeptical --- do you have a full package? Takes 33 minutes on my 5 year old 2.3 GHz dual core. Darrell

2 1

Re: [trinity-devel] Can TDE now build in parallel jobs (i.e. -j2 or -j4)?
by Darrell Anderson 21 Jan '14

21 Jan '14

>I saw that. Thanks. Glad to know you have a list. After >experiencing sever >spurious failures a year or so ago, I have been gunshy about using >it. The >difference between -j1 and -j4 is phenomenal (haven't tried >anything above >actual cores) I had forgotten about the three exceptions. Next build run I'm going to test them again. Darrell

2 1

tdelibs-tdecore FTBFS /usr/bin/ld: cannot find -ldbus-1-tqt
by David C. Rankin 21 Jan '14

21 Jan '14

Slavek, All After fixing the option that strips static-libs from the final package in arch, I went to rebuild tdelibs. Doing so, I enabled the following: cmake ${srcdir}/tdelibs \ -DCMAKE_INSTALL_PREFIX=${TDEDIR} \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DWITH_ARTS=ON \ -DWITH_ALSA=ON \ -DWITH_LIBART=ON \ -DWITH_LIBIDN=ON \ -DWITH_SSL=ON \ -DWITH_CUPS=ON \ -DWITH_LUA=OFF \ -DWITH_TIFF=ON \ -DWITH_JASPER=ON \ -DWITH_OPENEXR=ON \ -DWITH_UTEMPTER=ON \ -DWITH_AVAHI=ON \ -DWITH_PAM=ON \ -DWITH_PCRE=ON \ -DWITH_TDEHWLIB_DAEMONS=ON \ -DWITH_UPOWER=ON \ -DWITH_UDISKS2=ON \ -DWITH_LZMA=ON \ -DWITH_XRANDR=ON \ -DWITH_XCOMPOSITE=ON \ -DWITH_ASPELL=ON \ -DWITH_HSPELL=ON The build failed with the now-familiar error: /usr/bin/ld: cannot find -ldbus-1-tqt collect2: error: ld returned 1 exit status tdecore/CMakeFiles/tdecore-shared.dir/build.make:3063: recipe for target 'tdecore/libtdecore.so.14.0.0' failed make[2]: *** [tdecore/libtdecore.so.14.0.0] Error 1 make[2]: Leaving directory '/build/tde-tdelibs/src/build' CMakeFiles/Makefile2:1087: recipe for target 'tdecore/CMakeFiles/tdecore-shared.dir/all' failed However, note: This is now with '-ldbus-1-tqt' instead of '-ldbus-tqt-1'. Basically, this is "same-song-second-verse". pkgconfig info is fine, but unless the CMakeLists.txt files are patched to include either ${DBUS_TQT_LIBRARY_DIRS} or somehow get ${TDEHW_CUSTOM_LIBRARY_DIRS} into the CMakeLists.txt, the build fails. The current tdecore CMakeLists.txt includes only the following: link_directories( ${TQT_LIBRARY_DIRS} ${LIBIDN_LIBRARY_DIRS} ${GAMIN_LIBDIR} ${LIBART_LIBRARY_DIRS} ) This is insufficient if( WITH_TDEHWLIB_DAEMONS OR WITH_HAL OR WITH_DEVKITPOWER OR WITH_UPOWER OR WITH_UDISKS OR WITH_UDISKS2 OR WITH_NETWORK_MANAGER_BACKEND OR WITH_CONSOLEKIT ) are chosen as options. See: tdecore/tdehw/CMakeLists.txt There are probably other fixes needed, but my first thought was just to include ${DBUS_TQT_LIBRARY_DIRS}: link_directories( ${TQT_LIBRARY_DIRS} ${LIBIDN_LIBRARY_DIRS} ${GAMIN_LIBDIR} ${LIBART_LIBRARY_DIRS} ${DBUS_TQT_LIBRARY_DIRS} ) But if ${TDEHW_CUSTOM_LIBRARY_DIRS} is visible in this scope, then : link_directories( ${TQT_LIBRARY_DIRS} ${LIBIDN_LIBRARY_DIRS} ${GAMIN_LIBDIR} ${LIBART_LIBRARY_DIRS} ${TDEHW_CUSTOM_LIBRARY_DIRS} ) is probably better. You do NOT see this problem if you are including -L/opt/trinity/libs in CXXFLAGS, but you should not have to put library search paths in CXXFLAGS to avoid the FTBFS. -- David C. Rankin, J.D.,P.E.

2 4

Re: [trinity-devel] Can TDE now build in parallel jobs (i.e. -j2 or -j4)?
by Darrell Anderson 21 Jan '14

21 Jan '14

> 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? The only build scripts where I limit NUMJOBS=-j1: dependencies/avahi-tqt/avahi-tqt.SlackBuild libraries/pytdeextensions/pytdeextensions.SlackBuild tdebindings/tdebindings.SlackBuild For everything else: if [ "$NUMJOBS" = "" ]; then NUMJOBS="`grep -c '^processor' /proc/cpuinfo`" NUMJOBS=$(($NUMJOBS + 2)) export NUMJOBS="-j${NUMJOBS}" fi Darrell

3 2

Re: [trinity-devel] Note on autotools & obsolete macros
by Darrell Anderson 21 Jan '14

21 Jan '14

> In your autotools builds for applications, etc., pay close >attention to the >obsolete macro warning/errors and the option-subdirs warnings. >From >http://www.gnu.org/software/automake/manual/automake.html : > >Although using some of the following macros was required in past >releases, you >should not use any of them in new code. All these macros will be >removed in the >next major Automake version; if you are still using them, running >autoupdate >should adjust your configure.ac automatically (see Using >autoupdate to Modernize >configure.ac in The Autoconf Manual). Do it NOW! > >I have had several pieces of code hal/dcraw, etc. where I have had >to tweak >these issues with autotools 1.14. So when 2.0 is released. There >may be >significant work to do. Please file a bug report. This kind of information ALWAYS gets lost in this list. Darrell

2 1

tdebase FTBFS - No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a'
by David C. Rankin 21 Jan '14

21 Jan '14

All, I do not know what in the heck this error is: [ 95%] Built target ksysguardd-static Scanning dependencies of target ksysguardd [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/Command.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/conf.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/ksysguardd.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/PWUIDCache.c.o make[2]: *** No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a', needed by 'ksysguard/ksysguardd/ksysguardd'. Stop. CMakeFiles/Makefile2:24311: recipe for target 'ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/all' failed make[1]: *** [ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/all] Error 2 Makefile:116: recipe for target 'all' failed make: *** [all] Error 2 The base error is: *** No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a', needed by 'ksysguard/ksysguardd/ksysguardd'. Stop. Is this a CMake error or some other type of error? Where to start? -- David C. Rankin, J.D.,P.E.

3 15

Warning: Changing WITH_HAL and WITH_TDEHWLIB configuration defaults
by Darrell Anderson 21 Jan '14

21 Jan '14

Per bug report 1838, we are changing the defaults in tdebase CMakeLists.txt. Please remember to verify your tdebase build scripts. :) If building for mixed distro releases, consider something like the following in the build script: if [ -x /usr/sbin/hald ]; then BUILD_HAL=${BUILD_HAL:-ON} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-OFF} else BUILD_HAL=${BUILD_HAL:-OFF} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-ON} fi ... cmake $SOURCES_ROOT \ ... -DWITH_HAL=${BUILD_HAL} \ -DWITH_TDEHWLIB=${BUILD_TDEHWLIB} \ ... Darrell

2 1

Missing packages in nightly-builds, renaming one git submodule
by Slávek Banko 20 Jan '14

20 Jan '14

Tim, during my random monitoring FTBFS in nightly builds, I noticed a few missing packages. At the beginning - one unnecessary - knetworkmanager8. This being replaced by tdenetworkmanager, no longer being updated and may be removed from nightly-builds. The second package was renamed, but the git repository has not been renamed - compizconfig-backend-kconfig. I believe that we should rename the git repository. I suppose then the package will be again properly updated in nightly-builds. The following packages are ready for builds, but it seems not to have been included into the automation script: + casper-trinity + trinity-keyring + trinity-livecd + ubiquity-trinity Slavek

2 6

Note on autotools & obsolete macros
by David C. Rankin 20 Jan '14

20 Jan '14

All, In your autotools builds for applications, etc., pay close attention to the obsolete macro warning/errors and the option-subdirs warnings. From http://www.gnu.org/software/automake/manual/automake.html : Although using some of the following macros was required in past releases, you should not use any of them in new code. All these macros will be removed in the next major Automake version; if you are still using them, running autoupdate should adjust your configure.ac automatically (see Using autoupdate to Modernize configure.ac in The Autoconf Manual). Do it NOW! I have had several pieces of code hal/dcraw, etc. where I have had to tweak these issues with autotools 1.14. So when 2.0 is released. There may be significant work to do. -- David C. Rankin, J.D.,P.E.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels