Date: Sat, 27 Oct 2012 11:05:21 GMT From: Dimitry Andric <dim@FreeBSD.org> To: freebsd-gnats-submit@FreeBSD.org Subject: ports/173138: Fix building x11/kdelibs3 with clang Message-ID: <201210271105.q9RB5LJn081906@red.freebsd.org> Resent-Message-ID: <201210271110.q9RBA1B9034061@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 173138 >Category: ports >Synopsis: Fix building x11/kdelibs3 with clang >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Oct 27 11:10:00 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Dimitry Andric >Release: FreeBSD 10.0-CURRENT i386 >Organization: The FreeBSD Project >Environment: FreeBSD vm-dvs-dimtest1.home.andric.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r241516: Sun Oct 14 18:53:08 CEST 2012 dim@vm-dvs-dimtest1.home.andric.com:/usr/obj/usr/src/sys/GENERIC i386 >Description: Regular port exp-runs with clang are done, and as described on <http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121020001711.pointyhat-west/index-reason.html>, kdelibs3 is currently one of the ports that fails with clang, and it has a high number of affected ports. The actual failure is found here: <http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121020001711.pointyhat-west/kdelibs-3.5.10_10.log> It seems to build successfully to the end, but when a package is created, the following error results: [...] ===> Building package for kdelibs-3.5.10_10 tar: lib/kde3/kimg_exr.a: Cannot stat: No such file or directory tar: lib/kde3/kimg_exr.la: Cannot stat: No such file or directory tar: lib/kde3/kimg_exr.so: Cannot stat: No such file or directory tar: share/services/exr.kimgio: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 E.g., for some reason the kimg_exr libraries have not been built, while they are expected to be there. Looking at the beginning of the log, during the configure phase, the reason becomes clear: [...] checking for OpenEXR libraries... no When I reproduced this locally, I could view the config.log file, and I found the following: [...] configure:49023: checking for OpenEXR libraries configure:49087: rm -rf SunWS_cache; clang++ -o conftest -Wno-long-long -Wundef -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -pipe -fno-strict-aliasing -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I${prefix}/include -I/usr In file included from conftest.cpp:216: In file included from /usr/local/include/OpenEXR/ImfRgbaFile.h:50: In file included from /usr/local/include/OpenEXR/ImfHeader.h:51: /usr/local/include/OpenEXR/ImathVec.h:1216:2: error: cannot use 'throw' with exceptions disabled throw NullVecExc ("Cannot normalize null vector."); ^ /usr/local/include/OpenEXR/ImathVec.h:1253:2: error: cannot use 'throw' with exceptions disabled throw NullVecExc ("Cannot normalize null vector."); ^ /usr/local/include/OpenEXR/ImathVec.h:1364:13: error: cannot use 'throw' with exceptions disabled throw InfPointExc ("Cannot normalize point at infinity."); ^ and a whole bunch of similar errors. The problem is that configure attempts to build a sample OpenEXR program with -fno-exceptions, and while gcc silently ignores the throw statements, clang complains about them. Basically, you cannot build OpenEXR without exceptions. Indeed, during the actual build of the kimgio/ subdir, you can see that it actually adds an -fexceptions flag after the previous CXXFLAGS, with a USE_EXCEPTIONS macro. So, to fix the configure misdetection, we need to add the USE_EXCEPTIONS macro to the OpenEXR test. >How-To-Repeat: CC=clang CXX=clang++ CPP=clang-cpp make -C /usr/ports/x11/kdelibs3 >Fix: Here is a proposed patch for the port, which adds files/patch-configure. Patch attached with submission follows: Index: x11/kdelibs3/files/patch-configure =================================================================== --- x11/kdelibs3/files/patch-configure (revision 0) +++ x11/kdelibs3/files/patch-configure (working copy) @@ -0,0 +1,17 @@ +--- configure.orig 2008-08-20 18:06:05.000000000 +0200 ++++ configure 2012-10-26 21:15:38.000000000 +0200 +@@ -49046,11 +49046,11 @@ echo "${ECHO_T}no" >&6; } + + ac_ext=cpp + ac_cpp='$CXXCPP $CPPFLAGS' +-ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5' +-ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' ++ac_compile='$CXX -c $CXXFLAGS $USE_EXCEPTIONS $CPPFLAGS conftest.$ac_ext >&5' ++ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $USE_EXCEPTIONS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' + ac_compiler_gnu=$ac_cv_cxx_compiler_gnu + +-ac_link='rm -rf SunWS_cache; ${CXX-g++} -o conftest${ac_exeext} $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5' ++ac_link='rm -rf SunWS_cache; ${CXX-g++} -o conftest${ac_exeext} $CXXFLAGS $USE_EXCEPTIONS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5' + + + kde_save_CXXFLAGS="$CXXFLAGS" >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210271105.q9RB5LJn081906>