On Jan 1, 2013, at 4:36 PM, Per Johansson wrote:
On Tue, Jan 1, 2013 at 7:11 PM, Per Johansson per@morth.org wrote:
On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis cdavis5x@gmail.com wrote:
The right thing IMO is to test if we're compiling with Clang. If we are, then we should test if Clang is using its integrated assembler; if it is, then we should invoke Clang instead of the system assembler to assemble. This way, the user doesn't have to pass yet another option to configure in case he's using Clang.
I have a patch to hack-fix winebuild to invoke Clang if we're being compiled by Clang; I can fix it to test for Clang and Clang's integrated assembler in configure and send it to the list--something I really should've done a while ago.
Sure, sounds like a better plan.
Patch is sent.
I tried briefly to use clang, but there were a lot of undefined symbol errors I wasn't sure how to fix.
What kind of undefined symbol errors? Other than the ones I got because as(1) from cctools can't grok CFI pseudo-ops (and probably never will because of Clang), I don't know of any symbol problems building Wine with Clang on Mac OS. Might have something to do with my system version (I'm still on 10.6, and I probably won't move until I find some way to run -arch ppc apps since Apple gutted Rosetta from 10.7...)
Tell me if you want some help with the patch.
Btw, I should probably add that there's currently no way to build unpatched wine on 10.8 (and probably 10.7), as gcc-apple-4.2 get a conflict about cpu_type_t
That probably means some system header is including--directly or indirectly--<mach/machine.h> (the system header that defines Mach's cpu_type_t) somewhere inside the server (which defines Wine's cpu_type_t), where it wasn't before. Want me to file a radar? (The last time something like this happened, I was told to file a radar with Apple. Amazingly, it worked! It probably helped that I pointed out which header pulled in a header that it didn't need; this time might be more difficult.)
and pure gcc is not up to date with the latest Objective-C syntax in the system headers. Being able to build with clang would help a lot.
Do you actually not have the Wine vs. Mach cpu_type_t issue with Clang? I'd find that interesting.
Chip
Regards,
Per Johansson