clang + compiler-rt aren't buildable on OS X since r157062; how to proceed?

Clang Frontend
1

Hi,

r157062 broke bootstrap builds of clang if compiler-rt is built too.
See Regression(r157062 ): compiler-rt build on mac is broken due to armv6 changes · Issue #13290 · llvm/llvm-project · GitHub for details, in short: r157062 lets clang
output a load command for iOS targets that the ar binary in all
released Xcode versions doesn't understand. compiler-rt is built for
mac and ios when compiling on OS X by default.

As a result, I haven't been able to push a new clang to the chromium
repo in a while. What's the way forward here?

1.) Make a prerelease ar a requirement for doing bootstrap builds for
building clang and compiler-rt

2.) Augment r157062 to only use new load commands if target platforms
are new enough

3.) Remove ios from the default compiler-rt build

4.) Something else

I'm not able to push new clang binaries to chromium until this is resolved.

Thanks,
Nico

2

#3.

3

Cool. Could you work with someone who understands the compiler-rt
build to make that happen and unbreak the build?

(I gave it a shot myself, but I'm not sure what the best way to go
about things is. Maybe add a "platform = Darwin and $2 = ios then
return" to compiler-rt/make/platform/clang_darwin.mk's CheckArches?)

Nico

4

Daniel is the right person for that. We'll see what we can do.

A bit more context, FWIW. #1 is an option, but feels kinda rude to make that a hard requirement. It's available for anyone who wants to re-enable it locally, but we need something better for default use-cases. #2 doesn't quite work out, as it's not the deployment target that's the limiting factor in this scenario, but rather the version of the host-side tools. There's not a solid way to check those versions. #3 is viable as it isolates the public builds of supported open source targets from any weirdness of Apple side stuff.

-Jim

5

Daniel is the right person for that. We'll see what we can do.

A bit more context, FWIW. #1 is an option, but feels kinda rude to make that a hard requirement. It's available for anyone who wants to re-enable it locally, but we need something better for default use-cases. #2 doesn't quite work out, as it's not the deployment target that's the limiting factor in this scenario, but rather the version of the host-side tools. There's not a solid way to check those versions. #3 is viable as it isolates the public builds of supported open source targets from any weirdness of Apple side stuff.

This is still broken.

The attached patches are a hack to drop arm completely. I am not sure
what is the best way to optionally add them back, but this lets anyone
that doesn't need ios support build compiler-rt again.

We should finish llvm-ar one day :slight_smile:

-Jim

Cheers,
Rafael

clang-no-ios.patch (491 Bytes)

compiler-rt-no-ios.patch (1.17 KB)

6

Ping, Daniel.

What's the right way to disable the iOS clang runtime in public builds without also disabling ARM entirely?

-Jim

7

How are you building clang on you machine ?
I'm on 10.7, and work with clang ToT.
I'm building it first with llvm-gcc-4.2 with the X86 backend only and then I rebuild it with itself and with ARM + X86 backend and I don't have any trouble.

-- Jean-Daniel

8

Daniel is the right person for that. We’ll see what we can do.

A bit more context, FWIW. #1 is an option, but feels kinda rude to make that a hard requirement. It’s available for anyone who wants to re-enable it locally, but we need something better for default use-cases. #2 doesn’t quite work out, as it’s not the deployment target that’s the limiting factor in this scenario, but rather the version of the host-side tools. There’s not a solid way to check those versions. #3 is viable as it isolates the public builds of supported open source targets from any weirdness of Apple side stuff.

This is still broken.

The attached patches are a hack to drop arm completely. I am not sure
what is the best way to optionally add them back, but this lets anyone
that doesn’t need ios support build compiler-rt again.

We should finish llvm-ar one day :slight_smile:

How are you building clang on you machine ?

http://llvm.org/bugs/show_bug.cgi?id=12950 has a build log with the steps I run.

llvm contains llvm, clang, compiler-rt

mkdir llvm-bootstrap
cd llvm-bootstrap

…/llvm/configure --enable-optimized --enable-targets=host-only --disable-threads --disable-pthreads --without-llvmgcc --without-llvmgxx

MACOSX_DEPLOYMENT_TARGET=10.5 make -j16
make check-all
cd …
mkdir llvm-build
cd llvm-build
export CC=$PWD/…/llvm-bootstrap/Release+Asserts/bin/clang
export CXX=$PWD/…/llvm-bootstrap/Release+Asserts/bin/clang++
…/llvm/configure --enable-optimized --disable-threads --disable-pthreads --without-llvmgcc --without-llvmgxx

MACOSX_DEPLOYMENT_TARGET=10.5 make -j16

make check-all

9

Hi Daniel,

Cool. Could you work with someone who understands the compiler-rt
build to make that happen and unbreak the build?

(I gave it a shot myself, but I'm not sure what the best way to go
about things is. Maybe add a "platform = Darwin and $2 = ios then
return" to compiler-rt/make/platform/clang_darwin.mk's CheckArches?)

^ does this sound like the right way to go?

Nico

10

Hi Daniel,

Cool. Could you work with someone who understands the compiler-rt
build to make that happen and unbreak the build?

(I gave it a shot myself, but I'm not sure what the best way to go
about things is. Maybe add a "platform = Darwin and $2 = ios then
return" to compiler-rt/make/platform/clang_darwin.mk's CheckArches?)

^ does this sound like the right way to go?

I checked in a patch that implements this in r158466.