Compiling with Clang/libc++

[Lord-Kamina]

The reason there is still no 1.0 mac build is that I haven't been able to produce a new build on yosemite; using libstdc++ is harder each day, gcc just won't compile many dependencies and clang cannot use libstdc++ anyway.

I've been trying, these past few days, to set up my environment using libc++ and to compile performous with clang.

In so doing, I've found the following error:

/Users/Ryoma/performous/game/instrumentgraph.cc:93:13: error: calling a private constructor of class 'std::__1::__wrap_iter<const MenuOption *>'
        auto cur = static_cast<MenuOptions::const_iterator>(&m_menu.current());
                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:1220:31: note: declared private here
    _LIBCPP_INLINE_VISIBILITY __wrap_iter(iterator_type __x) _NOEXCEPT : __i(__x) {}

As I understand, this is because libstdc++ makes some constructors public and libc++ does not. I don't really know enough to fix this on my own. However, I have found an old thread on Inkscape, where a patch to fix the (exact same) issue was posted. I was hoping somebody could review the file and it'll probably be a very simple change to get it fixed.

Here's the patch: https://launchpadlibrarian.net/155265758/patch-clang.diff

[Lord-Kamina]

Here, I'm pasting a wall-of-rant I just did on IRC, further clarifying why this is actually a thing that needs to happen.

So… Good news: Managed to produce a 1.0 OSX build; still kinking out a few last things with dependencies but it builds and it runs. Tools enabled (gh_xen_decrypt and itg_pack crash though). OpenCV enabled also.

Bad news: Seriously, I need somebody to help me fix the performous code so it will compile with clang and libc++… although I managed to produce a build now, the steps were utterly ridiculous.

The problem, in short is this: Up to Xcode4 (osx 10.7), Apple used a modified GCC 4.2 and an old libstdc++, not fully c++11 compliant.

From then on, they switched to a modded Clang and libc++, keeping the old libstdc++ exclusively for compatibility, never updating it.

Via macports, obviously, it is possible to get an updated libstdc++ and gcc and make it work. But, as time goes on, GCC is becoming less and less common and people using osx are beginning to abandon it. This means a lot of libraries will not build with GCC. Further, Libc++ adheres to somewhat more secure and stricter practices than libstdc++, which means some code that will compile on libstdc++ won't in libc++

As things currently stands, the options for somebody using macports are: Either use GCC, along with GNU libstdc++ (what I've been doing so far for performous)

Use Clang with either macports' libc++, Apple's libc++ or Apple's old libstdc++ (Clang will NOT use GNU libstdc++)

Or use Dragonegg with anything and set your computer on fire because dragonegg is shit.

The problem is, as I said, not everything compiles with GCC.

So, even though I can compile the rest of things with clang, I'm using an older libstdc++, without c++11 support and located elsewhere.

The end result is being able to build all dependencies and performous (WITH A LOT OF TINKERING!!), but since I'm using two different libstdc++, they conflict with each other and performous crashes.

What I did to get around this was track each and every port and library I'd installed and manually change all linkages to apple's libstdc++ to gnu's library, crossing fingers and hoping it'd be backwards compatible.

Thankfully, it seems it indeed is.

But… doing this is not really feasible in the long run.

Support for GCC and libstdc++ are certainly not gonna improve, and on the flipside, support for libc++ is increasing. Currently FreeBSD has also adopted it, and I woudln't be surprised if other OSs followed suit.

I posted, in the issue tracker, a patch employed by the inkscape developers to fix their code when they were faced with the exact same issue as I'm having with performous now.

I don't really know enough c++ to understand what I'm seeing other than grasping the basic concept. But, somebody who knows the code should be easily able to spot what needs to be changed and it would most likely be a very small change. -- Me, Ranting.

[nieknooijens]

I van understand you rant, same thing with libav changing all the function names for no good reason....