search for: profile_ios

...ropping arch 'x86_64' from lib 'cc_kext' warning: clang_darwin.mk: dropping arch 'i386' from lib 'profile_osx' warning: clang_darwin.mk: dropping arch 'x86_64' from lib 'profile_osx' warning: clang_darwin.mk: dropping arch 'i386' from lib 'profile_ios' warning: clang_darwin.mk: dropping arch 'x86_64' from lib 'profile_ios' warning: clang_darwin.mk: dropping arch 'armv6' from lib 'profile_ios' warning: clang_darwin.mk: dropping arch 'armv7' from lib 'profile_ios' warning: clang_darwin.mk: droppi...

...clang/3.1/lib lib/clang/3.1/lib/darwin lib/clang/3.1/lib/darwin/libclang_rt.10.4.a lib/clang/3.1/lib/darwin/libclang_rt.cc_kext.a lib/clang/3.1/lib/darwin/libclang_rt.eprintf.a lib/clang/3.1/lib/darwin/libclang_rt.ios.a lib/clang/3.1/lib/darwin/libclang_rt.osx.a lib/clang/3.1/lib/darwin/libclang_rt.profile_ios.a lib/clang/3.1/lib/darwin/libclang_rt.profile_osx.a -- It's entirely custom based on what the driver needs, and I find this to be very workable. In general, I view this as very much an "implementation detail" and see no need to over engineer here w.r.t. defining some formal schema u...

...cc_kext.a -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.eprintf.a -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.ios.a -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.osx.a -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.profile_ios.a +./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.i386.a ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.profile_osx.a ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.ubsan_osx.a +./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang...

...t/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.eprintf.a > -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.ios.a > -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.osx.a > -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.profile_ios.a > +./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.i386.a > ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.profile_osx.a > ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.ubsan_osx.a > +./opt/local/libexec/llvm-3.4/lib/clang/3.4/l...

It has come up when reviewing Kostya's patch to add the necessary support fort linking in the Address Sanitizer runtime library that we need a proper scheme and plan for deploying runtime libraries along with Clang. I've CC'ed llvmdev on this for compiler-rt developers' input. The key issues I see when locating runtime libraries are the following: - These libraries should be

...b/darwin > lib/clang/3.1/lib/darwin/libclang_rt.10.4.a > lib/clang/3.1/lib/darwin/libclang_rt.cc_kext.a > lib/clang/3.1/lib/darwin/libclang_rt.eprintf.a > lib/clang/3.1/lib/darwin/libclang_rt.ios.a > lib/clang/3.1/lib/darwin/libclang_rt.osx.a > lib/clang/3.1/lib/darwin/libclang_rt.profile_ios.a > lib/clang/3.1/lib/darwin/libclang_rt.profile_osx.a > -- > It's entirely custom based on what the driver needs, and I find this > to be very workable. > > In general, I view this as very much an "implementation detail" and > see no need to over engineer here w....

...er-rt/Makefile b/runtime/compiler-rt/Makefile index ccd83a3..eb73ffd 100644 --- a/runtime/compiler-rt/Makefile +++ b/runtime/compiler-rt/Makefile @@ -83,7 +83,7 @@ RuntimeLibrary.darwin.Configs := \ eprintf.a 10.4.a osx.a ios.a cc_kext.a cc_kext_ios5.a \ asan_osx_dynamic.dylib \ profile_osx.a profile_ios.a \ - ubsan_osx.a + ubsan_osx.a safestack_osx.a RuntimeLibrary.macho_embedded.Configs := \ hard_static.a hard_pic.a @@ -127,7 +127,7 @@ TryCompile = \ # We try to build 32-bit runtimes both on 32-bit hosts and 64-bit hosts. Runtime32BitConfigs = \ builtins-i386.a profile-i386.a san-i386.a...