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)

akonadi_main.log (1.7 MB) - added by jwhowse4 10 years ago.
akonadi build log
patch-Portfile.diff (842 bytes) - added by NicosPavlov 10 years ago.
patch-tests.diff (511 bytes) - added by NicosPavlov 10 years ago.
patch-akonadi.diff (903 bytes) - added by RJVB (René Bertin) 10 years ago.
patch for the Portfile that deactivates the building of the unittests.
patch-tests.2.diff (1.5 KB) - added by RJVB (René Bertin) 10 years ago.
deactivates the building of tests in CMake files
main.log (1.5 MB) - added by macports_org@… 10 years ago.
Build error without test-disabling patch.

Change History (24)

Changed 10 years ago by jwhowse4

Attachment: akonadi_main.log added

akonadi build log

comment:1 Changed 10 years ago by mf2k (Frank Schima)

Cc: nicos@… removed
Owner: changed from macports-tickets@… to nicos@…

comment:2 Changed 10 years ago by eborisch (Eric A. Borisch)

Cc: eborisch@… added

Cc Me!

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.

Last edited 10 years ago by StanSanderson (previous) (diff)

comment:4 Changed 10 years ago by NicosPavlov

Cc: rjvbertin@… added

Has duplicate #45307.

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 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:9 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:10 in reply to:  8 ; 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 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 in reply to:  10 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 in reply to:  11 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 Changed 10 years ago by NicosPavlov

Resolution: fixed
Status: newclosed

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:15 Changed 10 years ago by macports_org@…

Cc: macports_org@… added

Cc Me!

comment:16 in reply to:  14 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.

Last edited 10 years ago by macports_org@… (previous) (diff)

comment:17 Changed 10 years ago by macports_org@…

Resolution: fixed
Status: closedreopened

Changed 10 years ago by macports_org@…

Attachment: main.log added

Build error without test-disabling patch.

comment:18 Changed 10 years ago by NicosPavlov

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.