This finally adds support for Xcode 7 / El Capitan.
With this commit I am also removing ld64-134.9 support.
I kept ld64-134.9 for users with an old C++ standard library.
A decent C++ standard library with C++11 support is now mandatory.
it's simple, but I went around the project for a while until i figure out what the packaged SDK was. Didn't naurally want to continue reading until I understood that point.
* Support for generating fat object files with gcc and '-foc-use-gcc-libstdc++'
has been removed.
This feature was not 100% correctly implemented; using multiple source files
did not work, i.e.: 'o32-g++ -m32 -m64 a.cpp b.cpp' would have failed;
And I refuse to implement that, instead I am removing all source file handling
from the wrapper with this commit for simplicity.
This feature should be implemented in the gcc driver instead.
This does NOT affect clang's fat object file support, which is implemented in
clang's darwin driver.
* '-oc-use-gcc-lib' has been renamed to '-foc-use-gcc-libstdc++'.
* Added support for '-stdc++' and '-gstdc++' compiler "shortcuts"
o32-clang++ --> uses libstdc++ for <= 10.8 and libc++ for >= 10.9
o32-clang++-libc++ --> uses the SDK's libc++
o32-clang++-stdc++ --> uses the SDK's libstdc++
o32-clang++-gstdc++ --> uses gcc's (build_gcc.sh) libstdc++
* Entirely rewrote the command line parser; the previous one wasn't very
readable.
* Minor Readme Updates
* Added unit tests
* Removed OSXCROSS_C_STANDARD / OSXCROSS_CXX_STANDARD support
I am no longer parsing -std=, so this feature has to be dropped.
Setting the language standard via an env variable isn't a good idea anyway.
* Removed unneeded stuff
Other Changes:
* Version bump to 0.11
* handle '-sdk' / 'SDKROOT' (env.) properly.
e.g. 'xcrun -sdk /[...]/MacOSX10.6.sdk clang' will use
the specified 10.6 SDK.
* never execute xcode tools outside target/bin even when
a full path is specified.
e.g. 'xcrun /usr/bin/gcc' will execute target/bin/<triple>-gcc.
other wrapper changes:
* implement 'OSXCROSS_SDKROOT' env. variable for 'xcrun -sdk'.
* error on '-arch x86_64h' + clang <= 3.4.
clang <= 3.4 misinterprets x86_64h as x86_64.
* only create x86_64h symlinks when the 10.8 (or later) SDK
is used.
other changes:
* misc fixes and cleanup
port changes:
- misc fixes
- add '-L/usr/pkg/lib' for NetBSD
- update libobjc2 to r37977
- silence / fix libobjc2 warnings
- remove freebsd ifdef in favor of '-isystem /usr/local'
- add installhdrs target (cctools-port/issues/2)
- prefer glibtoolize over libtoolize
- add support for OS X and iOS as host system (cctools-port/issues/1)
- add a workaround for a glibc 2.20 bug
- link with -rpath to ease finding libLTO
- check for __cxa_demangle in -lstdc++
- use std=c++0x instead of -std=gnu++0x
- fix ld64 to compile with libstdc++
- fix automake warnings
- ld64: enable all architectures
This also gets rid of the automake dependency.
add support for multiple -arch flags with gcc (and clang + -oc-use-gcc-libs)
fix an unwind issue with -oc-use-gcc-libs + -mmacosx-version-min <= 10.5
update changelog
to highlight some changes:
- this gets rid of the bash dependency (after installing)
- osxcross-env, osxcross-conf and (the fake) dsymutil are now implemented
in the wrapper
- added: 'sw_vers' tool, which is required by some projects (llvm, ...)
- added '-oc-use-gcc-libs' option (uses './build_gcc.sh' libstdc++)
This new wrapper is also more restrict and several times faster than the bash
implementation (~0.2ms vs. 10ms+).
Debug symbols work anyway as long you *don't* build the binary in a single step:
o32-clang++ test.cpp -g3 # causes dsymutil invocation
o32-clang++ test.cpp -g3 -c # causes *no* dsymutil invocation
o32-clang++ -g3 test.o -o test # causes *no* dsymutil invocation
same with gcc.
Getting line numbers may require you to copy the object files (*.o) onto the system you are debugging on.
update README with libc++ build instructions and samples
fix mavericks SDK download link (pointed to 10.8)
build xar only for <=10.5
add -g0 to the clang invocation command to avoid dsymutil from being run (debugging is not supported, but I guess you don't want to debug the resulting binaries anyway if you build them on a non OS X system)
attempt to make the toolchain less path dependent (gcc still breaks though, because of hardcoded paths), but clang and cctools can be moved now
update cctools to 845
add DISABLE_LTO_SUPPORT option (DISABLE_LTO_SUPPORT=1 ./build.sh) to disable linking against libLTO.so
add support for 32 bit systems
add FreeBSD support
update PACKAGE script
