winebuild: Add configure option to use llvm-mc as assembler.

[Charles Davis]

On Jan 1, 2013, at 4:36 PM, Per Johansson wrote:

> On Tue, Jan 1, 2013 at 7:11 PM, Per Johansson <per at morth.org> wrote:
>> On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis <cdavis5x at 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