Add setdyld_lib_path.c + a list of known OSX SDK bugs and caveats

Author: devernay

README.md

@@ -98,6 +98,37 @@ ld: unknown option: -no_deduplicate
 ```
 The reason is that the newer versions of the linker introduced the option `-no_deduplicate`, which Xcode adds by default. To disable this, add a User-Defined build setting in Xcode named `LD_DONT_RUN_DEDUPLICATION` and set its value to `NO`.
 
+Known bugs (and fixes) in OS X SDKs
+-----------------------------------
+
+### Recent GCC versions cannot build universal binaries
+
+The GCC in Apple SDK is actually a small binary that lauches several compilers and merges the results (see [driverdriver.c](http://opensource.apple.com/source/gcc/gcc-5666.3/driverdriver.c)). The same executable can be compiled for recent GCC versions too, see [devernay/macportsGCCfixup](https://github.com/devernay/macportsGCCfixup) on github.
+
+### bad_typeid dyld Error on Leopard (10.5)
+
+This is a bug in the 10.6 (and later) SDKs, which can be easily fixed:
+
+- http://lists.apple.com/archives/xcode-users/2010/May/msg00183.html
+- http://stackoverflow.com/questions/12980931/how-to-ignore-out-of-line-definition-error-in-xcode-with-llvm-4-1
+
+### code compiled with g++ > 4.2.1 crashes with "pointer being freed not allocated"
+
+The problem comes from the fact that some system frameworks load the system libstdc++, which results in incompatible data structures.
+
+After exploring various options (install_name_tool, rpath, etc.), the only solution is to set the environment variable `DYLD_LIBRARY_PATH` to the path of a directory where you *only* put a symbolic link to the newest libstdc++ from GCC (libstdc++ is guaranteed to be backward-compatible, not other libraries).
+
+If you are building an application bundle, you should replace your executable by a small executable that sets the environment variable `DYLD_LIBRARY_PATH`. It can be a script (see below), or a binary (better, because it handles spaces in arguments correctly).
+
+The [`setdyld_lib_path.c`](setdyld_lib_path.c) source code can be compiled to act as a "launcher" for your binary that correctly sets the `DYLD_LIBRARY_PATH` variable. See the full instructions at the top of the source file.
+
+An alternate solution, using a shell-script (doesn't handle spaces in arguments): http://devblog.rarebyte.com/?p=157
+
+Other references:
+
+- http://stackoverflow.com/questions/6365772/unable-to-run-an-application-compiled-on-os-x-snow-leopard-10-6-7-on-another-m
+- http://stackoverflow.com/questions/4697859/mac-os-x-and-static-boost-libs-stdstring-fail
+
 License
 -------
 This script is distributed under the [Creative Commons BY-NC-SA 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/).

setdyld_lib_path.c

@@ -0,0 +1,68 @@
+/*
+  setdyld_lib_path.c
+
+  Author: Frederic Devernay <[email protected]>
+
+  Licence:
+  Creative Commons BY-NC-SA 3.0 license
+  http://creativecommons.org/licenses/by-nc-sa/3.0/
+
+  This small sample program sets the environment variable
+  DYLD_LIBRARY_PATH and executes another binary with the same
+  arguments.
+
+  This can be used when a given program was compiled using GCC
+  libraries that are different from the system-provided ones,
+  e.g. when compiling with a recent version of GCC. In this case, put
+  the GCC libraries (and only these) in a directory, and modify
+  DYLD_LIBRARY_PATH in the code below to point to the correct
+  lcation. These libraries are mad to be backward-compatible. Never
+  set DYLD_LIBRARY_PATH to a directory containing all your shared
+  libraries, because the system frameworks sometimes load shared
+  libraries which have very common names (eg the ImageIO framework
+  loads a libJPEG.dylib), and may not work anymore.
+
+  In the following example, the binary name is the name of this
+  executable with the suffix "-driver", and the DYLD_LIBRARY_PATH is
+  %s/../Frameworks/libgcc where %s is the dirname of this
+  executable. These should probably be adated to your needs.
+
+  This sample is part of the xcodelegacy source code.
+  https://github.com/devernay/xcodelegacy
+ */
+#if __APPLE__
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <libgen.h>
+#include <sys/errno.h>
+#include <mach-o/dyld.h> /* for _NSGetExecutablePath(char* buf, uint32_t* bufsize); */
+#include <limits.h> /* PATH_MAX */
+
+int main(int argc, char *argv[])
+{
+  char programPath[PATH_MAX];
+  uint32_t buflen = PATH_MAX;
+  _NSGetExecutablePath(programPath, &buflen);
+
+  /* append "-driver" to the program name to get the executable binary path */
+  strncat(programPath, "-driver", PATH_MAX - strlen(programPath) - 1);
+
+  /*
+   * set the DYLD_LIBRARY_PATH environment variable to the directory containing only a link to libstdc++.6.dylib
+   * and re-exec the binart. The re-exec is necessary as the DYLD_LIBRARY_PATH is only read at exec.
+   */
+  char *dyldLibraryPathDef;
+  char *programDir = dirname(programPath);
+  if (asprintf(&dyldLibraryPathDef, "DYLD_LIBRARY_PATH=%s/../Frameworks/libgcc", programDir) == -1) {
+    fprintf(stderr, "Could not allocate space for defining DYLD_LIBRARY_PATH environment variable\n");
+    exit(1);
+  }
+  putenv(dyldLibraryPathDef);
+  execv(programPath, argv); // note that argv is always NULL-terminated
+
+  fprintf(stderr, "execv(%s(%d), %s(%d), ...) failed: %s\n", programPath, (int)strlen(programPath), argv[0], (int)strlen(argv[0]), strerror(errno));
+  exit(1);
+}
+#endif