OpenTTD

Assuming that code was added for a reason, your patch will break building at whatever system uses those settings.
That is not acceptable.

Rather than causing havoc at other systems by deleting crucial settings, your patch should add checks that prevents adding bad settings for systems like yours.

The part of config.lib looks like it is meant for GCC. The link to github shows a log with clang.
Likely config.lib should check for GCC here.

The build fails with GCC as well as with Clang.

This may not help, but posting for the record. I have been able to build trunk OpenTTD on multiple versions of Mavericks and Yosemite, using default clang as provided by Apple, as per https://wiki.openttd.org/Compiling_on_Mac_OS_X#Configuring_on_Mavericks_.28and_Yosemite.29

For Yosemite, I didn't need to update any ports or other packages (although my system does have a macports trees that was installed under Mavericks, which may still be supplying some packages).

Just for the record, the issue here is that clang++ will use libc++ as standard library by default if you do not compile with a deployment target (the -mmacosx-version-min flag in config.lib) older than when Apple switched the default to libc++. You get the linker error about missing std::string symbols when you try to link a piece of code compiled against libc++ with libstdc++ or vice versa. The linker error occurs, because symbol mangling for std::string differs (on purpose) between these standard library implementations. If you didn't get the linker error, you'd instead see crashes at runtime.

The patch posted here was originally written by me (https://github.com/macports/macports-ports/commit/196a1cff4caa62f3f3773a10ceb9a1b4d9051f31) and later tagged with "Upstream-Status: Inappropriate [configuration]". MacPorts has a policy of always building against the host system, not against one of the OS X SDKs like the binaries built by OpenTTD are. It is probably not appropriate to be merged here.

I did not investigate what the issue with the 10.5 minimum version is, since the code was inappropriate for MacPorts' guidelines anyway. My best guess would be that the compiler uses libstdc++ (due to -mmacosx-version-min 10.5) but the linker uses libc++ (because LDFLAGS doesn't contain a deployment target). Note that forcing a deployment target that makes the compiler use libstdc++ also requires you to build any C++ dependencies with the same setting (which is also why I removed it for MacPorts).

Feel free to reach out to cal@macports.org if you need help figuring out this C++ standard library mess on OS X.

Clemens thanks this isn't being ignored :) I don't have an El Capitan or Sierra system to hand right now to test compiles (I'm also not the right person to figure out compile issues - way out of my depth).