Can't install kdevplatform

[ryandesign (Ryan Carsten Schmidt)]

This was not a clean attempt. Please "sudo port clean kdevplatform" and try again, then attach the new main.log.

[dave@…]

clean build log

[dragan.glumac@…]

There's definitely an issue with CXX compiler for this if you're using OS X Lion and Xcode 4.3 (latest and "greatest" version 4.3.2 :-S).

If I use clang to build kdevplatform I can get past this problem, but then I get tripped up further down the line by a #include of unordered_map which for some reason clang cannot see since it's an early-style STL header (on my system it lives in /usr/include/c++/v1/).

If I use llvm-g++-4.2 then I get the same problem that is listed in this ticket (and a few earlier ones).

This is what I did to build with clang:

1) sudo port clean kdevplatform 2) sudo port fetch kdevplatform 3) sudo port extract kdevplatform 4) cd /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/kde/kdevplatform/work/build 5) sudo cmake ../kdevplatform-1.3.1/ --> this at least on my system forces clang to be the CXX compiler. I guess you can explicitly set it to clang by passing -D CMAKE_CXX_COMPILER=clang as an argument to cmake 6) sudo make

And then I get tripped up by the #include <unordered_map>.

''[  7%] Building CXX object language/CMakeFiles/kdevplatformlanguage.dir/editor/modificationrevision.o
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_kdevplatform/kdevplatform/work/kdevplatform-1.3.1/language/editor/modificationrevision.cpp:36:10: fatal error: 
      'unordered_map' file not found
#include <unordered_map>
         ^
1 error generated.
''

Clang doesn't seem to see it by default and I haven't got round to figuring out how to add a library import to CMakeCXXCompiler.cmake file.

I hope this helps.

[dragan.glumac@…]

Sorry about the formatting above, here are the steps laid out in a more readable fashion

1) sudo port clean kdevplatform
2) sudo port fetch kdevplatform
3) sudo port extract kdevplatform
4) cd /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/kde/kdevplatform/work/build
5) sudo cmake ../kdevplatform-1.3.1/ --> this at least on my system forces clang to be the CXX compiler. I guess you can explicitly set it to clang by passing -D CMAKE_CXX_COMPILER=clang as an argument to cmake
6) sudo make

[dave@…]

Yeah, I got as far as dragan did with clang, and stopped there. Actually, <unordered_map> is available in C++11, so probably you just need to enable the C++11 option to Clang.

[dave@…]

With the following cmake command you can get all the way to link errors:

sudo port install clang-3.1
sudo cmake "-DCMAKE_CXX_COMPILER=$(which clang-mp-3.1)" "-DCMAKE_CXX_FLAGS=-std=c++11 -Wno-reserved-user-defined-literal" ../kdevplatform-1.3.1

It seems to be missing the runtime libraries for something (see my attachment). It's my wild guess that kdelibs4 and any other parts on which kdevelop depends need to be built with clang, too. Maybe someone else can get further than I.

[dave@…]

Link errors

[dave@…]

BTW, if someone with the privileges to do so could edit out the body of the bug report (which is superseded by my attached log) I would be grateful.

[mf2k (Frank Schima)]

Done.

[NicosPavlov]

Concerning forcing the compiler to be clang, an easier (and probably cleaner) way of using clang would be to edit the Portfile, by suppressing the lines:

if {${configure.compiler} == "clang"} {
    configure.compiler llvm-gcc-4.2
}

Clang is indeed disabled at this point in the Portfile, as my tests were showing multiple problems (both at configuration and build). I however do not have the possibility of testing on Lion system. I will try to look into the linking problems, but as this issue is not reproducible on Snow Leopard, it may be difficult to track. It would be great if someone could test compilation with clang by changing the Portfile, to confirm the issue.

[dragan.glumac@…]

Hi dave and nicos

Well I've done it, yay! I've had to do two things to get it to go:

1) I commented out the snippet that forces llvm-gcc-4.2 in Portfile
2) I've added an entry for COMPILER_CXX_FLAGS to include -std=c++11 -stdlib=libc++ , so dave you were half-way there. It wouldn't link because unordered_map object code wasn't in libstdc++ which is used by default.

I am attaching the Portfile and CMakeCXXCompiler.cmake file with my modification.

But before I launch into steps that got this working I have to say that this is probably a dirty hack and I am not sure that all will hang together. I am assuming that the port is intended to be built using GCC since that's what you had in earlier versions nicos. From running make manually with default configuration I noticed that libsublime.dylib does not actually get built into the lib folder when running with GCC, and I suspect consequently the examples can't be linked since there are no object files to link them against and the build fails. If you use Clang however, the dylib gets built and placed in the lib folder, so the examples build correctly.

Nicos, perhaps you can look into why the dylib doesn't get built - perhaps some dependencies in the generated Makefiles are off (i.e. maybe example1 and example2 don't depend on libsublime)?

Now the steps to install kdevplatform manually on Lion with Xcode 4.3.x

1) sudo port clean kdevplatform

2) sudo port fetch kdevplatform

3) sudo port extract kdevplatform

4) Modify /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/kde/kdevplatform/Portfile by commenting out (precede with #) the lines

if {${configure.compiler} == "clang"} {
    configure.compiler llvm-gcc-4.2
}

See attached file for details.

5) sudo port configure kdevplatform

6) Modify /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/kde/kdevplatform/work/build/CMakeFiles/CMakeCXXCompiler.cmake by adding the following line

SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")

I had it at line 11, after setting CMAKE_COMPILER_IS_GNUCXX to empty string (see attached file).

7) sudo port build kdevplatform

8) sudo port install kdevplatform
This will fail because one of the ports already has a certain file (built earlier possibly by GCC?) installed, so port tool will suggest you force the activation. And that's the last step.

9) sudo port -f activate kdevplatform

[dragan.glumac@…]

Modified Portfile.

[dragan.glumac@…]

CMakeCXXCompiler.cmake with additional Clang flags.

[NicosPavlov]

Thanks a lot for the different information. For what I tested, the flag "-std=c++11" should be optional, as the configure step of kdevplatform adds automatically "-std=c++0x" for clang compiler, which is equivalent.

I arranged the Portfile, so that with the attached file, it should be possible to install kdevplatform directly through

sudo port install kdevplatform

without any further processing by replacing the original Portfile with this one. If someone can confirm that it indeed works on Lion, I could then commit it. I also tested kdevelop, which seems to have exactly the same issues.

For all the tests I could do, I did however not see any file conflicting during activation.

[dragan.glumac@…]

Hi nicos

I've tested building and installing kdevplatform with the new Portfile (the one you attached) and it works with no problems. So this issue seems to be resolved.

I've also tested building and installing kdevelop with the relevant changes for Clang (the if block which sets additional flags for Clang), and there is definitely an issue with a particular source file. I got the same problem when I was trying to build develop with Clang a few days ago.

It seems that for some reason Clang can't find a constructor for std::list that matches the constructor called from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_kdevelop/kdevelop/work/kdevelop-4.3.1/languages/cpp/cppduchain/declarationbuilder.cpp

This is a perfectly legal constructor since it contains two iterator references, and the third argument if omitted means that std::list will use the default allocator. But it confuses Clang for some reason - it doesn't seem to recognise the decls.begin() and decls.end() as iterators.

I have attached the log file that is produced as a result.

I don't know how you want to deal with this. Since it's a related issue you could leave this ticket open until kdevelop problem is resolved, or if you like I can open another ticket for it. Let me know please.

[dragan.glumac@…]

This is main.log when trying to build and install kdevelop with the amended Portfile.

[dave@…]

Here's the place where it tries to match the desired constructor:

/usr/bin/../lib/c++/v1/list:813:9: note: candidate template ignored: substitution failure [with _InpIter = QList<KDevelop::Declaration *>::iterator]
        list(_InpIter __f, _InpIter __l,
        ^

Having looked through the relevant files I agree that there's no obvious reason for substitution failure here. It does indeed look like a Clang bug.

[dragan.glumac@…]

Well if anyone's interested I've managed to get kdevelop installed as well, but I've had to modify the source code for two files:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_kdevelop/kdevelop/work/kdevelop-4.3.1/languages/cpp/cppduchain/declarationbuilder.cp
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_kdevelop/kdevelop/work/kdevelop-4.3.1/languages/cpp/codecompletion/context.cpp

I've had to remove the attempt to construct std::list worklist from QList iterators because Clang didn't like it at all. Instead I changed it to use QList decls itself and QList iterators that come with it.

I've attached the two amended source files so hopefully if you're in a hurry to get kdevelop going, you can use these in place of the ones provided in the MacPorts kdevelop tarball.

[NicosPavlov]

Thanks for the confirmation for kdevplatform. It was committed in r94069.

Thanks also for the detailed information about kdevelop. I will look into it, specially since it is possible to patch files within macports to enable compilation despite upstream problems. It is however surprising, as the tests I did with macports-clang-3.1 on Snow Leopard did not show these issues.

[NicosPavlov]

The Portfile for KDevelop taking into account the issues mentioned above has been committed in r94145.