I'm curious, why is the 4.25 (libstdc++) version included with 10.4? Is it for compatibility with certain MathLink programs which run as a separate process (but perhaps not for use with LibraryLink which runs in the kernel process)?

It is both for compatability with standalone MathLink programs and to allow you to build libstdc++-based LibraryLink libraries. A standalone executable linked against the framework will remember the "major version" (in this case, 4.25) it was linked against and find it here, allowing it to continue to run.

Given that it is included, is it still expected that the LibraryLink binary I compile with 10.3 does load in 10.4, but then crashes sporadically (so far I only see a crash when calling MLNextPacket())?

Yes. The advantage and drawback of LibraryLink is that it loads functions directly into the kernel process. The kernel is linked against the libc++ version of MathLink. The 10.3-built LibraryLink is linked against the libstdc++ version. When you load it, it will load its MathLink along with it. You now have two sets of the same function loaded in the kernel process, with differeing C++ runtimes, and chaos ensues.

Incidentally, the reason the 10.4 built library won't load in earlier versions is that it knows it needs at least version 4.36 of MathLink, which doesn't exist in a 10.3 layout and so the load operation fails. If there were some way to prevent a second copy of a framework from being loaded into the same process, we could prevent 10.3-built libraries from loading into 10.4 instead of crashing the kernel. But Apple's linker doesn't provide a mechanism to do that (at least as far as we know).

OK, here's the test case for the reverse problem:

https://dl.dropboxusercontent.com/u/38623/Backward-compat-testcase.zip

If I compile a LibraryLink library with 10.3.1, then certain things don't work correctly in 10.4.0. Specifically, MLNextPacket() crashes when used as shown here.

Reported as CASE:3544766.

I think it is absolutely essential for Wolfram Research to have a prerelease programme if they want to support a healthy add-on ecosystem. Add-on authors must be able to test their packages before a new version of Mathematica is released.

Reported one of the two problems (libraries compiled with 10.4 don't load in 10.3) as CASE:3544676.

The test case I sent: https://dl.dropboxusercontent.com/u/38623/Forward-compat.zip

Still working on a test case for the other problem (which is much more involved).

If I only have M10.4 installed, can I compile a binary that will work with M10.3? To make the question more concrete, suppose I use the following command line (slightly modified from what CreateLibrary uses):

I don't think so. We provide runtime compatibility with the older libstdc++-based MathLink framework, but OS X doesn't provide a great way to select versioned interfaces at link-time. For the Wolfram RTL, we don't provide a libstdc++-based library with this build. If the versioning issue ever becomes prohibitive, I think we could see about providing tech support with a package containing only the link-time dependencies from 10.3, then it would be as simple as switching C compiler flags.

Really, I recommend keeping 10.3 for as long as you plan to support it with your LibraryLink code. That's the simplest solution. (or at least keeping its mathlink framework, SystemFiles/Includes directory, and WolframRTL libraries from SystemFiles/Libraries-- that's all you need!).

With Mathematica 10.3, I compiled some libraries (where I used C++11) using -mmacosx-version-min=10.9. Without this I couldn't use C++11 features ... The result did work so far. But could this, in principle, cause problem with 10.3 (which uses -mmacosx-version-min=10.6 by default)? Does -mmacosx-version-min=10.9 imply anything about libc++ vs libstdc++?

The Mac OS X compatibility flag means exactly what it sounds like it means. If you're targeting only 10.9 and above, it shouldn't be dangerous for you to use whatever flag in principle. It does imply -stdlib=libc++, so make certain that the library your produced didn't link against libc++:

$ otool -L /path/to/libmylibrary.dylib

There are some C++11 features in libstdc++, but it's version 4.2.x and it's definitely not feature complete (the compiler should complain if you try to use something that isn't present-- I think -std=C++11 or -std=C++0x may also be necessary in that case). Both libstdc++ and libc++ have backward compatibility, so linking against different versions of those libraries and headers should be safe (using the Mac OS X compatibility flags) provided you don't use the wrong one.

Really, Mac OS X 10.9 with libc++ is where Apple got their act together on C++11, so I highly recommend targeting that platform and beyond with your C++11 code.

Hello Alex,

Thank you for your very quick answer!

You answered most of my questions from above. Only two remain:

Question 1:

If I only have M10.4 installed, can I compile a binary that will work with M10.3? To make the question more concrete, suppose I use the following command line (slightly modified from what CreateLibrary uses):

-mmacosx-version-min=10.6 -framework Foundation -I"/Applications/Mathematica 10.4.app/Contents/SystemFiles/IncludeFiles/C" -I"/Applications/Mathematica 10.4.app/Contents/SystemFiles/Links/MathLink/DeveloperKit/MacOSX-x86-64/CompilerAdditions" -F"/Applications/Mathematica 10.4.app/Contents/SystemFiles/Links/MathLink/DeveloperKit/MacOSX-x86-64/CompilerAdditions" -framework "mathlink" -lstdc++

I changed -lc++ to -lstdc++ and used -mmacosx-version-min=10.6 as before. But it's "using" (whatever that means here) the MathLink "framework" from 10.4, not 10.3. Will the result work with 10.3?

I don't plan on deleting 10.3 anytime soon, but I won't be keeping it forever ...

Question 2:

With Mathematica 10.3, I compiled some libraries (where I used C++11) using -mmacosx-version-min=10.9. Without this I couldn't use C++11 features ... The result did work so far. But could this, in principle, cause problem with 10.3 (which uses -mmacosx-version-min=10.6 by default)? Does -mmacosx-version-min=10.9 imply anything about libc++ vs libstdc++?

@Szabolcs I am afraid maintaining two separate versions of the library on OS X may be unavoidable, this is caused by the libc++ vs libstdc++ ABI incompatibility.