[compiler-rt] Add iOS simulator link flag

Hello all!

Just got a small patch I’d like to put up for review.

llvm with clang and compiler-rt have been consistently failing for me during
the linking step for either the address or ub sanitizer for iOS simulator.

As far as I could tell, passing -isysroot to clang++ when linking does not
also set the search root for ld. This patch addresses that issue.

Unfortunately, the build fails later on, so I can't say for sure whether
this won't break anything else, or if it is required elsewhere. I'm also
not sure if this is specific to my computer, but it persisted between a
wipe + reinstall, so I'm hoping it isn't just me getting this.

Thanks,
Alex

iossim-link-flag.patch (545 Bytes)

Could you describe the build failures you see after applying this patch? I’ll let Chris judge if adding -Wl,-syslibroot makes sense for iossim, or that problem should be solved differently.

+llvm-commits (correct list)

This does not sound right. -isysroot specified during linking should be passing through the sys root to the linker.

What is the error you’re seeing? It would also help if you can provide the clang++ invocation and the output of it when run with -v.

Also which version of OS X are you on and which version of Xcode are you using?

Thanks,
-Chris

No? It should just be dropped.

Joerg

Summary is linker fails with unknown symbol in iossim asan/ubsan (was _wordexp
in the past, now is _sigaltstack$UNIX2003"i), or ranlib getting bad input while
working on native tablegen (archive extends past end of file, no such file are
the ones I remember)

Full commands + partial logs here:
https://gist.github.com/aw1621107/86fec1e1fa9cc66bbf4d

This was built on OS X 10.11, Xcode 7.1 using the following homebrew command
and formula:

brew install llvm --with-clang --with-sanitizers --HEAD --debug --verbose
https://github.com/aw1621107/homebrew/blob/llvm-updates/Library/Formula/llvm.rb

Summary is linker fails with unknown symbol in iossim asan/ubsan (was _wordexp
in the past, now is _sigaltstack$UNIX2003"i), or ranlib getting bad input while
working on native tablegen (archive extends past end of file, no such file are
the ones I remember)

Full commands + partial logs here:
https://gist.github.com/aw1621107/86fec1e1fa9cc66bbf4d

This was built on OS X 10.11, Xcode 7.1 using the following homebrew command
and formula:

brew install llvm --with-clang --with-sanitizers --HEAD --debug --verbose
https://github.com/aw1621107/homebrew/blob/llvm-updates/Library/Formula/llvm.rb

In the failing command (iossim-log) the syslibroot flag is being specified to the linker and the link command still fails, so your patch shouldn’t fix the problem. You can see that listed in iossim-link.txt.

The other error is (if anything) more disturbing. You’re generating a malformed libLLVMSupport. Not sure how that’s happening.

It looks to me like there is something wrong with your host toolchain. I don’t really know what else to say, but your patch shouldn’t have any impact on this problem since that flag is already being specified in the failing commands you’ve shown.

-Chris

Whoops. Forgot to include what happened before the patch.

Without it, my build fails earlier with something along the lines of “Building for
iOS simulator, but linking against file (libc++.dylib) built for OS X (x86_64)”.
The linker wasn’t touching the iPhone SDK at all, instead going straight for
/usr/lib/libc++.dylib. This also happened with libSystem.dylib, but I don’t know
what causes one library to fail vs the other.

Can you please provide the full error and information about the failure you saw without your patch?

Since you couldn’t build before the patch, and you can’t build with the patch. I suspect there is an underlying issue which isn’t being addressed.

-Chris

Logs + commands added to the earlier gist.

Only thing different from a plain trunk build is adding -Wl,-v and -Wl,-t to the
iossim link flags.

The behavior here is consistent with setting SDKROOT in the environment to an OS X SDK.

-Chris

Doesn’t look like it’s set when that command runs.

The env during the build looks something like the first one here:
https://gist.github.com/aw1621107/3e0b5a36d028f648d7a0

Sadly I really can’t help you debug the home-brew build, it is a good ways outside my expertise.

If you want to try building from source using the guide here: http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary

I’d be more helpful. As it is, the patch you proposed doesn’t seem to make it build via home-brew, and I don’t think we should be taking an effectively untested patch that doesn’t actually enable you to build.

You may want to take up this issue with whomever maintains the home-brew package you’re trying to build.

-Chris

Alright, tried a manual build with clang and compiler-rt.

Config command I used was:

cmake -G “Unix Makefiles” …/llvm -DCMAKE_VERBOSE_MAKEFILE=ON -DLLVM_OPTIMIZED_TABLEGEN=On -DLLVM_ENABLE_ASSERTIONS=On

Ran builds with 1, 2, 4, 8, 9 threads. Only got a failure on two of the four 9-threaded
builds; tried the other ones once each.

For what it’s worth, fully multi-threaded builds with one or none of the tablegen/assertion
flags succeeded. The main difference I noticed from the failing config is that these builds
didn’t produce a NATIVE folder.

gist here: https://gist.github.com/aw1621107/b01fc73821895847a454

It does look like the SDK/linker issues are something with homebrew, so I’ll go
bother the homebrew maintainers instead. My apologies for the trouble.

There are known parallelization issues in the CMake-generated makefiles. They seem more common with LLVM_OPTIMIZED_TABLEGEN=On. The issue doesn’t exist when using ninja instead of make, and I haven’t had the time to track it down. I don’t know if it is a CMake bug, or a bug in our configuration.

Patches welcome.

-Chris