building darwin toolchain

[inolen]

Hey guys,

I'm trying to build a darwin toolchain to cross-compile from Linux for Mac.

I've got a .config which is a slightly modified version of the i686 darwin11 config:

CT_EXPERIMENTAL=y
CT_STATIC_TOOLCHAIN=n
CT_LOCAL_TARBALLS_DIR="${HOME}/src"
CT_SAVE_TARBALLS=y
CT_LOG_EXTRA=y
CT_MULTILIB=y
CT_LLVM_V_3_4=y
# llvmgcc needs an older version of LLVM (2.7)
# such as the one that comes in Apples tarball
# Disabled until - maybe never! - we get round
# to allowing two different LLVM builds.
CT_CC_llvmgcc=n
CT_CC_LLVMGCC_V_2336_11=y
CT_LLVM_COMPILER_RT=n
CT_ARCH_64=y
CT_ARCH_x86=y
CT_TARGET_VENDOR="apple"
CT_KERNEL_darwin=y
CT_DARWIN_MAC_OSX_V_10_9=y
CT_DARWIN_VERSION="13"
CT_DARWIN_SDK_PATH="${HOME}/MacOSX10.9.sdk"
CT_SHARED_LIBS=y
CT_BINUTILS_cctools=y
CT_CCTOOLS_V_809=y
CT_CC_GCC_V_apple_5666_3=y
CT_CC_clang=y
CT_CC_LANG_CXX=y
CT_CC_LANG_OBJC=y
CT_CC_LANG_OBJCXX=y
CT_LIBC_none=y
CT_EXPORT_BUILD_TOOLS=y
# Clang is currently broken without this!
# It doesn't look in -isysroot folder ...
CT_DARWIN_COPY_SDK_TO_SYSROOT=n
# For repeatable builds, must be the -t format
# because touch on Mac doesn't support --date=
CT_SRC_REFERENCE_DATETIME="199912312359.59"

However, I'm hitting two issues. If CT_DARWIN_COPY_SDK_TO_SYSROOT is set to n, gcc fails to build as various headers that are in the SDK aren't placed inside of the generated sysroot directory (which I guess it depends on). I don't have an exact error, I forgot to save a log and it'll be another hour to generate it.

If I set it to y however, clang then subsequently fails to build. I'm not sure why, my VM ran out of disk space, and I noticed the clang executable that was built was 500+mb, with the entire bin directory for the clang build being > 10gb in size.

Anyways, I just wanted to see if anything was obviously wrong here before I kept testing (iteration is very slow due to https://github.com/diorcety/crosstool-ng/issues/4).

[class101]

You need to copy sdk to sysroot

I have seen this size problem too while building a windows cross compiler targeting mac with clang 3.4, I think it comes from a debug set being built by default, after adding --disable-debug --disable-assertions to the configure the size was much decent

diff -durN ct-ng-dw.a/scripts/build/companion_libs/150-llvm.sh ct-ng-dw.b/scripts/build/companion_libs/150-llvm.sh
--- ct-ng-dw.a/scripts/build/companion_libs/150-llvm.sh 2014-02-26 20:01:40.185569300 +0100
+++ ct-ng-dw.b/scripts/build/companion_libs/150-llvm.sh 2014-02-26 20:02:15.165640900 +0100
@@ -158,6 +158,8 @@
         --host=${host}                \
         --prefix="${prefix}"          \
         --target=${CT_TARGET}         \
+        --disable-debug               \
+        --disable-assertions          \
         ${OPTIM_CONFIG_FLAG}          \

There is a new switch for clang to look correctly in the sysroot (ray is aware and will add it later)

--with-default-sysroot=

Here for example I'm doing

diff -durN ct-ng-dw.a/scripts/build/cc/200-clang.sh ct-ng-dw.b/scripts/build/cc/200-clang.sh
--- ct-ng-dw.a/scripts/build/cc/200-clang.sh    2014-02-26 21:55:07.428137700 +0100
+++ ct-ng-dw.b/scripts/build/cc/200-clang.sh    2014-02-26 21:58:21.060461600 +0100
@@ -125,18 +127,28 @@
     local ldflags
     local arg
     local -a final_CFLAGS
+    local wsysroot
+    wsysroot="$( cd "${CT_SYSROOT_DIR}"; pwd -W)"
@@ -163,6 +175,7 @@
         --build=${CT_BUILD}           \
         --host=${host}                \
         --prefix="${prefix}"          \
+        --with-default-sysroot="${wsysroot}" \
         --target=${CT_TARGET}         \
         ${OPTIM_CONFIG_FLAG}          \

[inolen]

Trying this out now, thanks!

[mingwandroid]

You do not need to pass CT_DARWIN_COPY_SDK_TO_SYSROOT ..

I never use CT_DARWIN_COPY_SDK_TO_SYSROOT. Sure, after it, you can compile hello-world.c and even hello-world.cpp with the compilers (and maybe even some big packages that depend on nothing more than libc and libstdc++) but a really useful Darwin SDK includes Frameworks too (which COPY_SDK_TO_SYSROOT doesn't copy) and at that stage, well, you may as well just pass the sysroot flags on the commandline. Also, you couldn't distribute a toolchain with embedded SDK legally.

Likely your problem is that many of the Darwin SDKs floating around are dodgy, and even ones you make yourself can be dodgy. By this I mean that they contain symlinks to targets that do not exist, usually because they contain absolute symlinks. To turn a bad one into a usable one, you can untar it to where it expects to be then re-tar it with dereferenced symlinks, or replace them with relative symlinks using a script - though you may want to do this in a chroot environment so you don't stomp all over your Linux sysroot!

Arnaud is right about --with-default-sysroot; I mean to add it but I am a bit busy with work for the next few weeks (at least, and then after that I've got a backlog of work to do for other projects). For Linux you'd not use wsysroot, as that's a hack for MSYS2, instead just pass:

--with-default-sysroot="${CT_SYSROOT_DIR}"

Finally, I would strongly encourage you to use the companion project here to do your builds (ignore the firefox part, it started off as a tool to build cross compilers then build firefox, but that bit has rotted):

https://github.com/mingwandroid/ctng-firefox-builds

.. there's a few minor caveats, e.g. you must create a "/c" folder and chown it to $USER - I do this to make it easier to compare logs and artefacts from Linux with those from Windows, but it simplifies the process dramatically and more importantly, standardises options so that if (when!) things go wrong, we can compare notes (or build.log files). It automatically installs needed packages on Arch Linux, Ubuntu, Mac OS X and MSYS2 using pacman, apt, homebrew and pacman again respectively, if it needs to.

To use it:

git clone https://github.com/mingwandroid/ctng-firefox-builds
cd ctng-firefox-builds
./build.sh --target-os=osx

It is definitely an 'engineers tool' if you catch my drift. :-)

You can catch me sometimes on #crosstool-ng on freenode IRC.

[class101]

@inolen Btw if you want to get ride of the issue of llvm generated with an absurd size like 500MB+ for only LTO.dll making the final compiler ~1.5GB size, edit crosstool-NG.sh.in and remove the forced debug flag change OPTIM_FLAGS="-O2 -g" to OPTIM_FLAGS="-O2"

I'm always fixing this here in a patch but somehow this morning I managed to revert this change back and indeed it has created huge binary size, once this change made your LTO.dll will be down to a better size ~22MB and static libs too