Opened 10 years ago
Closed 10 years ago
#45300 closed defect (fixed)
akonadi build fails
Reported by: | jwhowse4 | Owned by: | NicosPavlov |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.1 |
Keywords: | Cc: | eborisch (Eric A. Borisch), StanSanderson, RJVB (René Bertin), cooljeanius (Eric Gallager), macports_org@… | |
Port: | akonadi |
Description
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.
Attachments (6)
Change History (24)
Changed 10 years ago by jwhowse4
Attachment: | akonadi_main.log added |
---|
comment:1 Changed 10 years ago by mf2k (Frank Schima)
Cc: | nicos@… removed |
---|---|
Owner: | changed from macports-tickets@… to nicos@… |
comment:3 Changed 10 years ago by StanSanderson
Cc: | stansand@… added |
---|
Cc Me!
fyi- I'm running OS 10.6.8 on a 32-bit iMac.
comment:5 Changed 10 years ago by 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.
comment:6 Changed 10 years ago by 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 .
comment:7 Changed 10 years ago by 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" } } }
comment:8 follow-up: 10 Changed 10 years ago by 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.
comment:10 follow-up: 12 Changed 10 years ago by 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.
comment:11 follow-up: 13 Changed 10 years ago by 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.
Changed 10 years ago by NicosPavlov
Attachment: | patch-Portfile.diff added |
---|
Changed 10 years ago by NicosPavlov
Attachment: | patch-tests.diff added |
---|
comment:12 Changed 10 years ago by 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 ...
Changed 10 years ago by RJVB (René Bertin)
Attachment: | patch-akonadi.diff added |
---|
patch for the Portfile that deactivates the building of the unittests.
Changed 10 years ago by RJVB (René Bertin)
Attachment: | patch-tests.2.diff added |
---|
deactivates the building of tests in CMake files
comment:13 Changed 10 years ago by 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!!).
comment:14 follow-up: 16 Changed 10 years ago by NicosPavlov
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:16 Changed 10 years ago by 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.
comment:17 Changed 10 years ago by macports_org@…
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Changed 10 years ago by macports_org@…
Build error without test-disabling patch.
comment:18 Changed 10 years ago by NicosPavlov
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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.
akonadi build log