Bug 173138

Summary: Fix building x11/kdelibs3 with clang
Product: Ports & Packages Reporter: Dimitry Andric <dim>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Dimitry Andric freebsd_committer freebsd_triage 2012-10-27 12:10:00 UTC
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.

Fix: Here is a proposed patch for the port, which adds files/patch-configure.


Patch attached with submission follows:
How-To-Repeat: CC=clang CXX=clang++ CPP=clang-cpp make -C /usr/ports/x11/kdelibs3
Comment 1 Pawel Pekala freebsd_committer freebsd_triage 2012-11-24 17:42:52 UTC
State Changed
From-To: open->closed

Committed. Thanks!