Hi Jonas, >> I think I took care of this in 10.4-EOL but the change may not have made >> it to 10.5-EOL (but it should have). I see in the current state that >> 10.4-EOL's llvm33.patch has the corrected context-related patch. I don't >> have powerpc-darwin9 to test on, but someone else had tested it for me >> before. I'm going to blindly sync 10.5-EOL to 10.4-EOL's copy right... >> now. Please sync 10.5-EOL and try again, and let me know how that works. > > Thanks, but it still doesn't work: > > [ 14%] Building CXX object > projects/compiler-rt/lib/asan/CMakeFiles/clang_rt.asan_osx_dynamic.dir/asan_mac.cc.o > /sw/src/fink.build/llvm33-3.3-1/llvm-3.3.src/projects/compiler-rt/lib/asan/asan_mac.cc: > > In function 'void __asan::GetPcSpBp(void*, __sanitizer::uptr*, > __sanitizer::uptr*, __sanitizer::uptr*)': > /sw/src/fink.build/llvm33-3.3-1/llvm-3.3.src/projects/compiler-rt/lib/asan/asan_mac.cc:75: > > error: 'struct __darwin_mcontext' has no member named 'ss' > /sw/src/fink.build/llvm33-3.3-1/llvm-3.3.src/projects/compiler-rt/lib/asan/asan_mac.cc:76: > > error: 'struct __darwin_mcontext' has no member named 'ss' > /sw/src/fink.build/llvm33-3.3-1/llvm-3.3.src/projects/compiler-rt/lib/asan/asan_mac.cc:78: > > error: 'struct __darwin_mcontext' has no member named 'ss' > > Etc. Looking at the preprocessed output, I've discovered the error only > happens while building the ppc64 version of that file. The cause: > * the compiler's -dD output showed that __DARWIN_UNIX03 is 0 for the ppc > build (# 282 "/usr/include/sys/cdefs.h") and 1 for the ppc64 build (# 277 > "/usr/include/sys/cdefs.h"). As a result, the ppc version uses "ss" and the > ppc64 uses "__ss" as the mem state name in the system headers. > * __DARWIN_VERSION__ is defined as "((MAC_OS_X_VERSION_MIN_REQUIRED - > MAC_OS_X_VERSION_10_0)/10 +4)", and MAC_OS_X_VERSION_MIN_REQUIRED is defined > as __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__. > __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ in both cases comes from the > compiler's built-in defines, and is set to 1040 *in both cases*.
Thanks for the diagnosis. That's because CMakeLists.txt (post-patching) hard-codes: set(SANITIZER_MIN_OSX_VERSION 10.4) Apparently, more 10.4 users test this package than 10.5 users :) If you change that one line in the patch, does the build work for you? (That should be a much smaller change.) If that works, we could either change the 10.5-EOL patch, or just make the PatchScript conditional so macosx-min-version always corresponds to the native version. (I like to keep the Info files unified as much as possible, even if it gets hideous like it already is.) Also, the powerpc-* builds of the package only do 1-stage of bootstrap, not the full 3, because stage-2 has issues, and darwin8,9 codegen has a known libunwind incompatibilities. By the way, if you'd like to track current development of llvm/clang porting: http://www.csl.cornell.edu/~fang/sw/llvm/ -- links to my public github branches -- test logs -- list of known issues as you found, there are a few places that hardcode 10.4, since that's the only machine I have available for testing. > A possible way could be to check for _PPC_UCONTEXT_H_ or _I386_UCONTEXT_H_. > That macro is defined when compiling against the 10.4 SDK but not when > compiling against the 10.5 SDK, because 10.4 uses {ppc,i386}/ucontext.h, > while 10.5 instead has {ppc,i386}/_structs.h. I've attached a modified > version of llvm33.patch that uses this technique. Additionally, I also had to > apply the X86_THREAD_MEM() macro on ppc64 (so I renamed it to THREAD_MEM()). Oh, so you're testing powerpc64-darwin9, I'm definitely missing that data point. I'll integrate part of your patch into my branch. Despite my cmakefile hacking, I'm not cmake-literate enough to write such tests. (Give me autoconf any day!) > My build using this patch isn't finished yet and I can't check the outcome > until Monday, but it seems to work fine (at least asan has built successfully > already). I hope it also still works on 10.4 (and on x86/x86_64). > > Jonas > > PS: the ccache detection in llvm33.info seems to be broken. I have ccache > installed via fink (/sw/bin/ccache exists), but the build process doesn't use > it (I understand you normally have to install the ccache-default package for > fink to use it, but the llvm build script seems to have special detection for > it that should work even when ccache-default isn't installed) > PS2: since 10.5 is no longer supported by the Fink project, should I take > fink-users out of CC? cmake's detection/usage of ccache is broken. If cmake detects 'ccache' and tries to use it, it pukes when prepending ccache in front of the compiler name; it chokes on CCC='ccache anything', because somewhere they fail to handle spaces between the command names. Hence, the silly dance to create a space-free-compiler-wrapper-name like 'ccgcc' that invokes ccache if-it-was-found. Unless there's objection, I'm happy to keep the thread going on the list. It's good if there's a searchable trail of progress, even on EOL. Fang -- David Fang http://www.csl.cornell.edu/~fang/ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Fink-users mailing list [email protected] List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
