Re: winebuild: Add configure option to use llvm-mc as assembler.
On Jan 1, 2013, at 9:35 AM, Per Johansson wrote:
Needed to build with clang on OS X, the normal as program can't parse clang output. It's a configure option since llvm-mc takes different options than the normal assembler, and on OS X is most often installed by a different name (llvm-mc-mp-3.1 in my case). But llvm-mc isn't a tool intended to be used by the end user. It's an LLVM developer's tool intended to be used to test and play with LLVM's MC library (which Clang uses to implement its integrated assembler). The help output even says "llvm machine code playground". That's why Apple doesn't distribute it with Xcode.
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. Chip
--- configure.ac | 8 ++++++++ tools/winebuild/build.h | 6 +++++- tools/winebuild/import.c | 4 ++-- tools/winebuild/res32.c | 2 +- tools/winebuild/utils.c | 22 +++++++++++++++++----- 5 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac index 620ad07..84232e0 100644 --- a/configure.ac +++ b/configure.ac @@ -59,6 +59,7 @@ AC_ARG_WITH(jpeg, AS_HELP_STRING([--without-jpeg],[do not use JPEG]), [if test "x$withval" = "xno"; then ac_cv_header_jpeglib_h=no; fi]) AC_ARG_WITH(ldap, AS_HELP_STRING([--without-ldap],[do not use LDAP]), [if test "x$withval" = "xno"; then ac_cv_header_ldap_h=no; ac_cv_header_lber_h=no; fi]) +AC_ARG_WITH(llvm-mc, AS_HELP_STRING([--with-llvm-mc=NAME],[Use llvm-mc as assembler])) AC_ARG_WITH(mpg123, AS_HELP_STRING([--without-mpg123],[do not use the mpg123 library]), [if test "x$withval" = "xno"; then ac_cv_header_mpg123_h=no; fi]) AC_ARG_WITH(openal, AS_HELP_STRING([--without-openal],[do not use OpenAL]), @@ -294,6 +295,13 @@ AC_CHECK_PROGS(CONVERT, convert, false) AC_CHECK_PROGS(ICOTOOL, icotool, false) AC_CHECK_PROGS(MSGFMT, msgfmt, false)
+dnl Check if user wants llvm-mc +if test "x${with_llvm_mc:-no}" != "xno" +then + if test "${with_llvm_mc}" = "yes"; then with_llvm_mc=llvm-mc; fi + AC_DEFINE_UNQUOTED(LLVM_MC, ["${with_llvm_mc}"], [Define to name of llvm-mc program, if preferred.]) +fi + if test "x$enable_maintainer_mode" != "xyes" then AC_SUBST([MAINTAINER_MODE],[\#]) diff --git a/tools/winebuild/build.h b/tools/winebuild/build.h index 05adf31..71e87f6 100644 --- a/tools/winebuild/build.h +++ b/tools/winebuild/build.h @@ -209,6 +209,10 @@ struct strarray #define IMAGE_SUBSYSTEM_WINDOWS_CUI 3 #define IMAGE_SUBSYSTEM_WINDOWS_CE_GUI 9
+/* find_tool flags */ + +#define FT_SKIP_TARGET_ALIAS 1 + /* global functions */
#ifndef __GNUC__ @@ -246,7 +250,7 @@ extern int output( const char *format, ... ) extern void output_cfi( const char *format, ... ) __attribute__ ((__format__ (__printf__, 1, 2))); extern void spawn( struct strarray *array ); -extern char *find_tool( const char *name, const char * const *names ); +extern char *find_tool( const char *name, const char * const *names, int flags ); extern struct strarray *get_as_command(void); extern struct strarray *get_ld_command(void); extern const char *get_nm_command(void); diff --git a/tools/winebuild/import.c b/tools/winebuild/import.c index c73b86c..821b5b8 100644 --- a/tools/winebuild/import.c +++ b/tools/winebuild/import.c @@ -1325,14 +1325,14 @@ void output_import_lib( DLLSPEC *spec, char **argv ) fclose( output_file ); output_file = NULL;
- strarray_add( args, find_tool( "dlltool", NULL ), "-k", "-l", output_file_name, "-d", def_file, NULL ); + strarray_add( args, find_tool( "dlltool", NULL, 0 ), "-k", "-l", output_file_name, "-d", def_file, NULL ); spawn( args ); strarray_free( args );
if (argv[0]) { args = strarray_init(); - strarray_add( args, find_tool( "ar", NULL ), "rs", output_file_name, NULL ); + strarray_add( args, find_tool( "ar", NULL, 0 ), "rs", output_file_name, NULL ); strarray_addv( args, argv ); spawn( args ); strarray_free( args ); diff --git a/tools/winebuild/res32.c b/tools/winebuild/res32.c index 729aa2f..bddca83 100644 --- a/tools/winebuild/res32.c +++ b/tools/winebuild/res32.c @@ -682,7 +682,7 @@ void output_res_o_file( DLLSPEC *spec ) free( output_buffer );
args = strarray_init(); - strarray_add( args, find_tool( "windres", NULL ), "-i", res_file, "-o", output_file_name, NULL ); + strarray_add( args, find_tool( "windres", NULL, 0 ), "-i", res_file, "-o", output_file_name, NULL ); spawn( args ); strarray_free( args );
diff --git a/tools/winebuild/utils.c b/tools/winebuild/utils.c index 09f9b73..0fe24a9 100644 --- a/tools/winebuild/utils.c +++ b/tools/winebuild/utils.c @@ -276,7 +276,7 @@ void spawn( struct strarray *args ) }
/* find a build tool in the path, trying the various names */ -char *find_tool( const char *name, const char * const *names ) +char *find_tool( const char *name, const char * const *names, int flags ) { static char **dirs; static unsigned int count, maxlen; @@ -286,7 +286,7 @@ char *find_tool( const char *name, const char * const *names ) unsigned int i, len; struct stat st;
- if (target_alias) return strmake( "%s-%s", target_alias, name ); + if (target_alias && !(flags & FT_SKIP_TARGET_ALIAS)) return strmake( "%s-%s", target_alias, name );
if (!dirs) { @@ -345,11 +345,22 @@ struct strarray *get_as_command(void)
if (!as_command) { +#ifdef LLVM_MC + as_command = find_tool( LLVM_MC, NULL, FT_SKIP_TARGET_ALIAS ); +#else static const char * const commands[] = { "gas", "as", NULL }; - as_command = find_tool( "as", commands ); + as_command = find_tool( "as", commands, 0 ); +#endif } strarray_add_one( args, as_command );
+#ifdef LLVM_MC + strarray_add( args, "-filetype", "obj", NULL); + if (target_alias) + strarray_add( args, "-triple", target_alias, NULL); + else if (force_pointer_size) + strarray_add( args, "-arch", (force_pointer_size == 8) ? "x86_64" : "x86", NULL ); +#else if (force_pointer_size) { switch (target_platform) @@ -370,6 +381,7 @@ struct strarray *get_as_command(void) break; } } +#endif
if (cpu_option) strarray_add_one( args, strmake("-mcpu=%s", cpu_option) ); return args; @@ -382,7 +394,7 @@ struct strarray *get_ld_command(void) if (!ld_command) { static const char * const commands[] = { "ld", "gld", NULL }; - ld_command = find_tool( "ld", commands ); + ld_command = find_tool( "ld", commands, 0 ); } strarray_add_one( args, ld_command );
@@ -417,7 +429,7 @@ const char *get_nm_command(void) if (!nm_command) { static const char * const commands[] = { "nm", "gnm", NULL }; - nm_command = find_tool( "nm", commands ); + nm_command = find_tool( "nm", commands, 0 ); } return nm_command; } -- 1.8.0
On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis <cdavis5x(a)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. I tried briefly to use clang, but there were a lot of undefined symbol errors I wasn't sure how to fix. Tell me if you want some help with the patch. Regards, -- Per Johansson
On Tue, Jan 1, 2013 at 7:11 PM, Per Johansson <per(a)morth.org> wrote:
On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis <cdavis5x(a)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. I tried briefly to use clang, but there were a lot of undefined symbol errors I wasn't sure how to fix. 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 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. Regards, -- Per Johansson
On Jan 1, 2013, at 4:36 PM, Per Johansson wrote:
On Tue, Jan 1, 2013 at 7:11 PM, Per Johansson <per(a)morth.org> wrote:
On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis <cdavis5x(a)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
On Wed, Jan 2, 2013 at 3:12 AM, Charles Davis <cdavis5x(a)gmail.com> wrote:
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...)
I think I simply forgot to add the -c flag, silly me. Patch seems to work, I'm getting some compile errors but I suppose it's a different problem: avifile.DPJO1m.s:443:2: error: invalid operand for instruction lretw ^ avifile.DPJO1m.s:580:2: error: invalid operand for instruction lretw ^
Do you actually not have the Wine vs. Mach cpu_type_t issue with Clang? I'd find that interesting.
Yes, it doesn't appear with clang, and also not with gcc-mp-4.x from macports. I could open a radar myself (only have free membership), but I don't mind it too much since the default gcc compiler doesn't work anyway (wine bug 28030), so it might just as well get an error compiling if we get clang working. Regards, -- Per Johansson
On Jan 2, 2013, at 5:35 AM, Per Johansson wrote:
On Wed, Jan 2, 2013 at 3:12 AM, Charles Davis <cdavis5x(a)gmail.com> wrote:
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...)
I think I simply forgot to add the -c flag, silly me. Patch seems to work, I'm getting some compile errors but I suppose it's a different problem:
avifile.DPJO1m.s:443:2: error: invalid operand for instruction lretw ^ avifile.DPJO1m.s:580:2: error: invalid operand for instruction lretw ^ That's fixed in LLVM/Clang trunk. (I know, because I fixed it myself. A while ago, actually; I'm surprised Xcode doesn't have it yet.) Maybe the next version of Xcode will pick up the fix. Someone should really prod Apple about this :).
Do you actually not have the Wine vs. Mach cpu_type_t issue with Clang? I'd find that interesting.
Yes, it doesn't appear with clang, and also not with gcc-mp-4.x from macports. I suspect that's because Clang and newer GCC are smarter about identical typedefs. The ObjC BOOL vs. Wine BOOL issue wasn't about identical typedefs, because an ObjC BOOL is a "signed char" while a Wine BOOL is an "int". But a Mach cpu_type_t is an "integer_t"... which, ultimately, is a plain "int", the same as Wine's cpu_type_t. I could open a radar myself (only have free membership), but I don't mind it too much since the default gcc compiler doesn't work anyway (wine bug 28030), so it might just as well get an error compiling if we get clang working. Yeah, I'm not sure anyone really cares about the dead Apple GCC branch anymore... except AJ, but that's because his old Mac mini is stuck on 10.5, where we don't even have that problem. So long as Wine compiles with Apple GCC 4.x on Leopard, he'll be happy :).
Chip
Regards, -- Per Johansson
participants (2)
-
Charles Davis -
Per Johansson