akonadi build fails

[jwhowse4]

On an Intel Mac Pro running Mac OS 10.8.5 and XCode 5.1.1 the package akonadi build fails with the attached error log.

[jwhowse4]

akonadi build log

[eborisch (Eric A. Borisch)]

Cc Me!

[StanSanderson]

Cc Me!

fyi- I'm running OS 10.6.8 on a 32-bit iMac.

[NicosPavlov]

Has duplicate #45307.

[NicosPavlov]

The issue is that the newest akonadi requires full C++11 support, which is not available in the libraries and headers standardly used on 10.8 and lower. I am looking into a fix for that presently.

[RJVB (René Bertin)]

#45307 is not so much a duplicate of this ticket, as this ticket is a direct result of the issue exposed in #45307.

clang-mp-3.4 *should* be able to handle C++11 code because the headers to come with llvm-3.4 . I'm less sure about the runtime library because I've never managed to get to the linking stage of a C++11 port using this compiler ... As explained in #45307, the current workaround is to use a recent gcc compiler from MacPorts ... and the true fix would be to address the issue with clang-3.4 .

[jeremyhu (Jeremy Huddleston Sequoia)]

If it requires C++11, you have 2 options:

1) Error out if C++ is not available (see the webkig-gtk port for an example)

or

2) Error out if Leopard or earlier and use libc++ on Snow Leopard or later. Only do this if it's a leaf application that other ports link against and it does not link against other C++ ports:

compiler.blacklist *gcc* {clang < 421}

platform darwin {
    configure.cxx_stdlib libc++
    depends_lib-append port:libcxx

    pre-fetch {
        if {![file exists /usr/lib/libc++.dylib]} {
            ui_error "$name requires a C++11 runtime, which your configuration does not allow"
            error "unsupported configuration"
        }
    }
}

[RJVB (René Bertin)]

or

3) modify the Portfile to depend on and use a MacPorts gcc version. Surely that must be possible?

Only do this if it's a leaf application that other ports link against and it does not link against other C++ ports

That's not feasible with KDE components ... I'd find it enraging to drop support for 10.6.8 just because of a compiler/runtime issue, esp. knowing that it's perfectly possible to build things with a perfectly good and recent compiler.

[cooljeanius (Eric Gallager)]

Cc Me!

[NicosPavlov]

Replying to rjvbertin@…:

3) modify the Portfile to depend on and use a MacPorts gcc version. Surely that must be possible?

Even if changing the compiler manages to compile the port, the underlying issue is that C++11 support is only provided in libc++ headers, and a binary built this way will lead to linking/runtime issues for other ports depending on it, hence the comment about being able to use this solution only for a leaf port which does not link against other C++ ports.

[NicosPavlov]

On another note, I noticed that the compilation errors are coming from a unit test function, and the culprit functions are exclusively used in that file. It is not ideal, but would it be possible that dropping these tests could enable compilation? (see attached patches) I am unfortunately unable to test them, as I have only a 10.9 machine available.

[RJVB (René Bertin)]

Replying to nicos@…:

Even if changing the compiler manages to compile the port, the underlying issue is that C++11 support is only provided in libc++ headers, and a binary built this way will lead to linking/runtime issues for other ports depending on it, hence the comment about being able to use this solution only for a leaf port which does not link against other C++ ports.

AFAIK not when using gcc-4.8, at least as long as the library doesn't link to an incompatible C++ runtime, which appears to be the case.

OTOH, I just noticed this:

> akonadictl start
akonadictl(36871,0x7fff70affcc0) malloc: *** error for object 0x7fff70a65500: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
"[
0: 0   akonadictl                          0x000000010000659d _Z11akBacktracev + 54
]
"
Exit 255

(gdb) r stop
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Volumes/Debian/MP6/bin/akonadictl stop
akonadictl(44711,0x7fff70affcc0) malloc: *** error for object 0x7fff70a65500: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Breakpoint 1, 0x00007fff85fd5499 in malloc_error_break ()
(gdb) bt
#0  0x00007fff85fd5499 in malloc_error_break ()
#1  0x00007fff85eff183 in free ()
#2  0x00000001000057c1 in std::vector<boost::program_options::basic_option<char>, std::allocator<boost::program_options::basic_option<char> > >::~vector ()
#3  0x000000010093b8f8 in ?? ()

Now I can't remember what compiler I built boost with, but my boost dylibs do not appear to depend on a MacPorts libstdc++ .

Bummer.

And curious that I can build kdevplatform and kdevelop with gcc-4.8 and run it without issues ...

[RJVB (René Bertin)]

patch for the Portfile that deactivates the building of the unittests.

[RJVB (René Bertin)]

deactivates the building of tests in CMake files

[RJVB (René Bertin)]

Replying to nicos@…:

On another note, I noticed that the compilation errors are coming from a unit test function, and the culprit functions are exclusively used in that file. It is not ideal, but would it be possible that dropping these tests could enable compilation? (see attached patches) I am unfortunately unable to test them, as I have only a 10.9 machine available.

I can confirm that this allows the build to go through and the port to function. I did have to do some extra work though: see my portfile diff and the new version of patch-tests.diff (patch-tests.2.diff, should be renamed to patch-tests.diff!!).

[NicosPavlov]

These types of erratic errors have been the reason of the rather strict policy about compilers.

It is great that the port can build like that, it makes things a lot easier. I committed it in r126425, with a slightly modified patch. My part of it was not needed anymore if tests are deactivated altogether.

[macports_org@…]

Cc Me!

[macports_org@…]

It is great that the port can build like that, it makes things a lot easier. I committed it in r126425, with a slightly modified patch. My part of it was not needed anymore if tests are deactivated altogether.

This error reappears on OSX 10.10.

After Disabling the tests by enabling the patch in the Portfile (increase version number which originally was <13), compilation is successful.

[macports_org@…]

Build error without test-disabling patch.

[NicosPavlov]

I see, thanks for the information. In that case, it seems pointless to try to build tests specifically on 10.9, which seems to be the only case where the tests can be built.

I activated the patch for all versions in r127727, which should solve the issue.