#42675: akonadi: build fails with Boost linking errors -------------------------+--------------------- Reporter: me@… | Owner: nicos@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: worksforme | Keywords: Port: akonadi | -------------------------+--------------------- Changes (by nicos@…): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:4 me@…]:
If it is required to use the same compiler, shouldn't akonadi's dependance on boost specify one of boost's 24 compiler-specifying variants? Requiring a specific variant of a port is not supported: #126.
If akonadi compiles without error on other compilers, it could also have compiler-specifying variants; is the best practice to define variants or to have the user specify configure.compiler? I reinstalled boost with clang, +clang35 and +clang34 failed with different incompatible type errors, +clang33 worked; with boost +clang33 installed, akonadi built & installed successfully.
Variants are usually used when specific configuration flags are required, while configure.compiler is the basic option to select a compiler. But first, the usually simplest solution is to use the default behaviour, which is to not manually specify variants, unless specifically needed. In the case you describe, building boost with +clang33 is close to default, as apple clang on Mavericks is also version 3.3. In principle, building boost without specifying compiler variants should lead to a similar result. I'll consider this as a worksforme for now, as the build worked, and the underlying issue is related to tickets in Macports which won't be fixed in the near future. -- Ticket URL: <https://trac.macports.org/ticket/42675#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X