Compiler bug or bad combo: WITH_DEBUG, FindKDE4Internals.cmake,
devel/kdebindings4-python-pykde4 and bsd.cmake.mk
Mel Flynn
mel.flynn+fbsd.current at mailing.thruhere.net
Sat May 16 15:24:57 UTC 2009
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@ 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.
--
Mel
More information about the freebsd-current
mailing list