January 2013 - Wine-Devel - list.winehq.org

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

by 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

Jan. 2, 2013

Re: [7/7] wmiutils: Add tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23686 Your paranoid android. === WNT4WSSP6 (32 bit path) === path.c:102: Test failed: got 80040154 path: unhandled exception c0000005 at 00401303 === W2KPROSP4 (32 bit path) === path.c:102: Test failed: got 80040154 path: unhandled exception c0000005 at 00401303

Jan. 2, 2013

Re: [PATCH] ddraw: Don't discard buffers that haven't been used in draws

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-01-02 12:42, schrieb Henri Verbeet: > On 2 January 2013 12:26, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> Fixes bug 32485. > I'm sure we've had this discussion wrt. commit messages before, > but this tells me just about nothing about what problem this patch > is supposed to fix, or why this is the correct solution. Also, do > you have tests for this? - From the bug report: > The game apparently wants the buffer contents to remain intact > when it locks a buffer with DDLOCK_DISCARDCONTENTS - or at least in > some cases. I noticed that the game maps and unmaps a buffer > repeatedly with this flag, without ever drawing from it. In theory > DISCARDCONTENTS is redundant in all but the first lock after a > draw, but the driver still discards the buffer contents. Ignoring > the flag and memsetting the buffer to some random value has the > same effect as setting the flag. One thing is unclear in the text: The game does eventually draw from the buffer, so it's not just using it as a sysmem storage. But there are about 20 DISCARD maps/unmaps between the draws. A test sounds like a good idea though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ5B/BAAoJEN0/YqbEcdMw3q4P/1uxrHM9lohIHNjI1CAisTOu hN6+mRTnulBwSmk8g3DbvuvgKUk+YZQAvSCjXB3zzm589C0bOBOlbWf2ndqG93wh uby1Pkt4sluB/p9eLWE0OprAnakclgpUPyEyvLipqROW7U/8ktlrIlMzX3eJOOum MokiDtN1QRsGFQMkesEsJbwNRV8yReyID/xwydL6iMhwzusLsu6OscOVq5sVQqHn E2hTTIei6kd6gzHdgUbFZ3KD4ohfkNPYejh9rPtVTLRijR/LTE5rot2/LNVI8DLo LtRO7Sk/f6im+uNznpxjQuk0oseHemehaX8UcqYFKp4muIdwaWlFQxz63E6cEm5/ JfhVvLDVCQqYkR8ISLQEjhg1k8Hbnd+CoULL0bC2QrSxXK0fGcnVnuxy6QgYCJ2p XGZ4+pNHPSL5bsa1pYaAwbKnwt9OiCXk0hlMcSLuVtOVe38kXoK3oMDuqszu5Uz7 p0CxuDDiAGxH1MpiNzDMRvviZUbkdnITWtoBr3pXf1usOT0qt3WIsv76zLDQLy6y vwGe8QcD5sM3DjrhIdr6VCIdy317iy4LQ3m2P9LR4TpX9hklis3zQl5t8/4ZQVHa 4iPNkLSKKNXMoaqthpCYZmCt02xvlmeIWNPk6zqEYsqMX2HJjutYvVsAbku378Wz zONK3uDplHDyXKnIJZYD =0YYv -----END PGP SIGNATURE-----

Jan. 2, 2013

Re: [PATCH] ddraw: Don't discard buffers that haven't been used in draws

by Henri Verbeet

On 2 January 2013 12:26, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Fixes bug 32485. I'm sure we've had this discussion wrt. commit messages before, but this tells me just about nothing about what problem this patch is supposed to fix, or why this is the correct solution. Also, do you have tests for this?

Jan. 2, 2013

Re: [11/12] kernel32: Add support for {Get|Set}NamedPipeHandleState().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23681 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Jan. 2, 2013

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

by 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(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

Jan. 2, 2013

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

by 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

Jan. 1, 2013

Re: xbox 360 emulation with logitech cordless and dinput joy disable

by Giovanni Ongaro

Thanks for the comments i could put the hardcoded values into registry keys if you are really interested in the patch, i know hardcoding is not an good practice but i made the patch to suit my needs and published it later for the community, not pretending it was ok, but i tested it with many game and it works pretty well

Jan. 1, 2013

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

by Per Johansson

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

Jan. 1, 2013

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

by Charles Davis

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 > > >

Jan. 1, 2013