Hi, I wanted to track down several issues with kde-4 and as such, started with this: cat -n /etc/make.conf 12 .if !empty(.CURDIR:M*/usr/ports/*) 13 .if !defined(USE_STANDARD_CFLAGS) 14 DEBUG_FLAGS=-ggdb 15 WITH_DEBUG=yes 20 .endif # more port specific stuff here, unrelated. This presented me with a problem for the devel/kdebindings4-python-pykde4 module. I've let the compilation of one object file (see below for details) run for >30 minutes wall clock /and/ CPU time and then pressed CTRL-C. Adding the following: 16 .if !empty(.CURDIR:M/usr/ports/devel/kdebindings4-python-pykde4) 17 CMAKE_BUILD_TYPE=DEBUGFULL 18 .else 19 CMAKE_BUILD_TYPE=DEBUG Fixed the problem and the entire port compiles and installs in under 10 minutes. This is on: 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r192130: Fri May 15 11:19:04 CEST 2009 Things tried and tested: - DISABLE_MAKE_JOBS: no effect - CMAKE_BUILD_TYPE unset: no effect - CMAKE_BUILD_TYPE=DEBUG: no effect - 14 DEBUG_FLAGS=-ggdb -fno-strict-aliasing 15 WITH_DEBUG=yes 16 #.if !empty(.CURDIR:M/usr/ports/devel/kdebindings4-python-pykde4) 17 #CMAKE_BUILD_TYPE=DEBUGFULL 18 #.else 19 CMAKE_BUILD_TYPE=DEBUG No effect. At present: last pid: 89647; load averages: 3.03, 2.60, 1.95 up 1+04:13:57 16:55:42 195 processes: 4 running, 190 sleeping, 1 zombie CPU: 74.0% user, 0.0% nice, 23.2% system, 2.2% interrupt, 0.6% idle Mem: 868M Active, 285M Inact, 207M Wired, 28M Cache, 112M Buf, 103M Free Swap: 3072M Total, 75M Used, 2997M Free, 2% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 89623 mel 1 115 0 241M 232M CPU1 1 9:09 87.79% cc1plus cd /stable/usr/obj/usr/ports/devel/kdebindings4-python- pykde4/work/kdebindings-4.2.3/python/pykde4 && /usr/local/libexec/ccache/world-c++ -D_GNU_SOURCE -DQT_NO_STL - DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT - D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB - Dpython_module_PyKDE4_kdeui_EXPORTS -pipe -ggdb -fno-strict-aliasing - Woverloaded-virtual -fvisibility=hidden -fvisibility-inlines-hidden -g -O2 - fno-reorder-blocks -fno-schedule-insns -fno-inline -fPIC - I/stable/usr/obj/usr/ports/devel/kdebindings4-python- pykde4/work/kdebindings-4.2.3/python/pykde4 - I/stable/usr/obj/usr/ports/devel/kdebindings4-python- pykde4/work/kdebindings-4.2.3 -I/usr/local/kde4/include - I/usr/local/kde4/include/KDE -I/usr/local/include/qt4/QtWebKit - I/usr/local/include/qt4/QtHelp -I/usr/local/include/qt4/QtDBus - I/usr/local/include/qt4/QtTest -I/usr/local/include/qt4/QtUiTools - I/usr/local/include/qt4/QtScript -I/usr/local/include/qt4/QtSvg - I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4/QtSql - I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4/QtNetwork - I/usr/local/include/qt4/QtDesigner -I/usr/local/include/qt4/Qt3Support - I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtCore - I/usr/local/include/qt4/Qt -I/usr/local/share/qt4/mkspecs/default - I/usr/local/include/qt4 -I/usr/local/include -I/usr/local/include/python2.6 - I/usr/local/kde4/include/solid -I/usr/local/kde4/include/kio - I/usr/local/kde4/include/kdeprint -I/usr/local/kde4/include/kdeprint/lpr - I/usr/local/kde4/include/dom -I/usr/local/kde4/include/ksettings - I/usr/local/kde4/include/knewstuff2 -I/usr/local/kde4/include/dnssd -o CMakeFiles/python_module_PyKDE4_kdeui.dir/sip/kdeui/sipkdeuipart0.o -c /stable/usr/obj/usr/ports/devel/kdebindings4-python- pykde4/work/kdebindings-4.2.3/python/pykde4/sip/kdeui/sipkdeuipart0.cpp load: 3.03 cmd: cc1plus 89623 [runnable] 413.90u 120.55s 87% 264348k gdb yields nothing useful. A ktrace and subsequent: kdump|egrep -v '(mmap|madvise|munmap)' >kdump.out yields assembly code and writes in 4096 blocks. Have not tried to reproduce this issue on -stable. I can make the kdump available for those interested. Is this a compiler bug or will this code eventually finish (30 minutes CPU time still seems like a bug to me, especially when without -O2 it compiles in 2 or 3 seconds). As a sidenote, if anyone from kde_at_ is reading current: The following assumption in bsd.cmake.mk is not true for kde4 builds: # CMAKE_BUILD_TYPE - Type of build (cmake predefined build types), # affects on CFALGS and thus should not be set. # Default: none (which respects CFLAGS) As per kde4/share/apps/cmake/modules/FindKDE4Internals.cmake: set(CMAKE_C_FLAGS_RELEASE "-O2 -DNDEBUG -DQT_NO_DEBUG") Default CMAKE_BUILD_TYPE if unset is RELEASE, which then *adds* CMAKE_C(XX)?_FLAGS_RELEASE to ${CFLAGS}, negating the stripping of -O2 by WITH_DEBUG in bsd.ports.mk: .if defined(WITH_DEBUG) && !defined(WITHOUT_DEBUG) STRIP= #none STRIP_CMD= ${TRUE} DEBUG_FLAGS?= -g CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} .endif So, it would be nice if bsd.cmake.mk would pick up on WITH_DEBUG and set CMAKE_BUILD_TYPE to DEBUGFULL, which has the expected effect from the end-user perspective. -- MelReceived on Sat May 16 2009 - 13:24:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:47 UTC