#45300: akonadi build fails -------------------------+--------------------- Reporter: jwhowse4@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: akonadi | -------------------------+--------------------- Changes (by mf2k@…): * cc: nicos@… (removed) * owner: macports-tickets@… => nicos@… -- Ticket URL: <https://trac.macports.org/ticket/45300#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#45300: akonadi build fails -------------------------+--------------------- Reporter: jwhowse4@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: akonadi | -------------------------+--------------------- Comment (by nicos@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/45300#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X

#45300: akonadi build fails -------------------------+--------------------- Reporter: jwhowse4@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: akonadi | -------------------------+--------------------- Comment (by jeremyhu@…): 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" } } } }}} -- Ticket URL: <https://trac.macports.org/ticket/45300#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X

#45300: akonadi build fails -------------------------+--------------------- Reporter: jwhowse4@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: akonadi | -------------------------+--------------------- Comment (by nicos@…): Replying to [comment:8 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. -- Ticket URL: <https://trac.macports.org/ticket/45300#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X

#45300: akonadi build fails -------------------------+--------------------- Reporter: jwhowse4@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: akonadi | -------------------------+--------------------- Comment (by rjvbertin@…): Replying to [comment:10 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 ... -- Ticket URL: <https://trac.macports.org/ticket/45300#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X

#45300: akonadi build fails -------------------------+--------------------- Reporter: jwhowse4@… | Owner: nicos@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: fixed | Keywords: Port: akonadi | -------------------------+--------------------- Changes (by nicos@…): * status: new => closed * resolution: => fixed Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/45300#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X