Re: Clang warnings on OS X ML
On Jan 30, 2013, at 6:44 PM, C.W. Betts wrote: When compiling Wine using Clang, there are a bunch of warnings that pop up, such as: ld: warning: could not create compact unwind for .L__wine_spec_call16_p_pw: dwarf uses DW_CFA_same_value ld: warning: could not create compact unwind for ___wine_stub_VARBSTRFROMR8: stack subq instruction is too different from dwarf stack size On win16 DLLs. And these warnings are with general DLL: ld: warning: could not create compact unwind for ___wine_stub__aullshr: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for .L__wine_spec_relay_entry_point_52: stack subq instruction is too different from dwarf stack size These are all related to compact unwind support--slated for inclusion in DWARF 5. Don't worry: they're harmless. The linker will just create normal unwind info instead... I think. They also all happen in winebuild-generated code--normal C code is (largely) unaffected. I'm not sure if we want to fix this or not: we don't use DWARF unwind info at all in 32-bit code, and even if we did, we certainly don't know how to parse the compact unwind data. 64-bit code is another matter, but we're a long way from supporting Wine64 on Mac--mostly due to the fact that Wine wants to use the GS segment for itself, but Mac OS is already using it. (tl;dr: Don't worry about it for now, even if all that went over your head. :) Another worrying warning is that __force_align_arg_pointer__ being an unknown attribute. Now that's not right. I specifically implemented this attribute in Clang myself just so I could build Wine with it. There were some *errors* about this attribute being used in a function pointer type, but as of Monday on Clang trunk, they're just warnings--really annoying warnings that I'm sure AJ won't want to have to turn off. (I know. I tried.) I also recall once that Clang didn't always accept the __-bracketed versions of some GNU attributes, which should also be fixed (and has been for several LLVM releases now!). I'd be surprised if Apple clang doesn't have this latter fix yet, though Xcode 4.5 still had some pre-LLVM 3.1 version of Clang. Seriously, if you're not running the latest Xcode--which as of yesterday is 4.6--you should be. Apple often branches their own releases from LLVM/Clang trunk. (I always use Clang trunk directly myself, but that's partly because I'm also a part-time Clang developer.) There's also a lot of enum conversion warnings. They're harmless. Most of them are in Direct3D code, because the client DLLs and the WineD3D backend DLL use different (but compatible) enumeration types. A few are in tests that try to pass nonsense values like 0xdeadbeef that are outside the range of known enumerators. It's just Clang being pedantic about the enum rules in C. Don't know if AJ or Henri are willing to take patches to silence these warnings. There was also a linker warning about register usage, but I can't seem to find it again. I'll bet it's another compact unwind-related warning. I recall seeing something to that effect myself--something along the lines of: ld: warning: could not create compact unwind for some winebuild-generated symbol: %ebp not used for stack frame or something. Chip
Re: fusion: Allow null to be the value of the public key
On 1/31/2013 12:35, Alistair Leslie-Hughes wrote:
Hi,
Changelog:
fusion: Allow null to be the value of the public key
+static const WCHAR nullpublickey[] = {
+
'm','s','c','o','r','l','i','n',',','v','e','r','s','i','o','n','=','0',
+
'p','u','b','l','i','c','K','e','y','T','o','k','e','n','=','n','u','l',
+'c','u','l','t','u','r','e','=','n','e','u','t','r','a','l',0};
You have 'nul' here, not 'null'.
Re: fusion: Allow null to be the value of the public key
On Thu, 2013-01-31 at 19:35 +1100, Alistair Leslie-Hughes wrote:
diff --git a/dlls/fusion/asmname.c b/dlls/fusion/asmname.c
index 162a76b..2c4b379 100644
--- a/dlls/fusion/asmname.c
+++ b/dlls/fusion/asmname.c
@@ -561,6 +561,10 @@ static HRESULT parse_pubkey(IAssemblyNameImpl *name,
LPCWSTR pubkey)
{
int i;
BYTE val;
+static WCHAR nullstr[] = {'n','u','l','l',0};
This should be const.
+if(lstrcmpiW(pubkey, nullstr) == 0)
+return S_OK;
Please add a test to show that it's case insensitive.
if (lstrlenW(pubkey) CHARS_PER_PUBKEY)
return FUSION_E_INVALID_NAME;
diff --git a/dlls/fusion/tests/asmcache.c b/dlls/fusion/tests/asmcache.c
index e97cfbe..79f8709 100644
--- a/dlls/fusion/tests/asmcache.c
+++ b/dlls/fusion/tests/asmcache.c
@@ -1016,6 +1016,10 @@ static void test_QueryAssemblyInfo(void)
'p','u','b','l','i','c','K','e','y','T','o','k','e','n','=',
'2','d','0','3','6','1','7','b','1','c','3','1','e','2','f','5',',',
'c','u','l','t','u','r','e','=','n','e','u','t','r','a','l',0};
+static const WCHAR nullpublickey[] = {
+
'm','s','c','o','r','l','i','n',',','v','e','r','s','i','o','n','=','0',
+
'p','u','b','l','i','c','K','e','y','T','o','k','e','n','=','n','u','l',
+'c','u','l','t','u','r','e','=','n','e','u','t','r','a','l',0};
size = MAX_PATH;
hr = pGetCachePath(ASM_CACHE_GAC, asmpath, size);
@@ -1386,6 +1390,17 @@ static void test_QueryAssemblyInfo(void)
Assembly path was changed\n);
ok(info.cchBuf == MAX_PATH, Expected MAX_PATH, got %d\n, info.cchBuf);
+/* display name is
mscorlib.dll,version=0.0.0.0,publicKeyToken=null,culture=neutral */
This comment doesn't agree with the string initialized above.
+INIT_ASM_INFO();
+lstrcpyW(name, nullpublickey);
+hr = IAssemblyCache_QueryAssemblyInfo(cache, 0, name, info);
+ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO),
+ Expected sizeof(ASSEMBLY_INFO), got %d\n, info.cbAssemblyInfo);
You should check the return value of QueryAssemblyInfo but
CreateAssemblyNameObject
is actually a better way to test this.
Re: Makedll.rules.in: Explicitly specify DLL name when building importlib
On 01/30/13 20:09, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: --- dlls/Makedll.rules.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Why do you need this? My use case is not really valid as is for Wine. I was experimenting with running parts of Wine on Windows, but I needed to change some DLL names. With this patch it's as easy as changing MODULE in Makefile.in files and copying .spec file. This way I get renamed DLLs built correctly and other DLLs depending on the new name without touching anything else. The above is not really a reason to put it in Wine. However, I thought that this behaviour is logical consequence of having MODULE and IMPORTLIB separately in Makefiles (as opposed to, say, IMPORTLIB=1 and using MODULE for its name), so I sent the patch. Jacek
Re: Makedll.rules.in: Explicitly specify DLL name when building importlib
Jacek Caban ja...@codeweavers.com writes: The above is not really a reason to put it in Wine. However, I thought that this behaviour is logical consequence of having MODULE and IMPORTLIB separately in Makefiles (as opposed to, say, IMPORTLIB=1 and using MODULE for its name), so I sent the patch. IMPORTLIB can be different, but it has no effect, the library name is taken from the spec file name which has to match MODULE. -- Alexandre Julliard julli...@winehq.org
Re: [3/3] msi: Improve parsing of the supported platforms string.
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=24227
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:6051: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
Re: kernel32/tests : added tests for copyfileex try5
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=24228 Your paranoid android. === WNT4WSSP6 (32 bit path) === Timeout === W2KPROSP4 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === WXPPROSP3 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W2K3R2SESP2 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === WVISTAADM (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W2K8SE (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W7PRO (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W7PROX64 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === TEST64_W7SP1 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W7PROX64 (64 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === TEST64_W7SP1 (64 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1
Re: [website] Added Simplified Chinese translation
Nice work. I did end up moving a few things around, and had to patch my language detection function, but it worked when I switched my browser over to zn-ch. I fixed the image as well. Also, please set your text editor to output 4 spaces instead of tabs. Thanks! -N On 01/30/2013 09:34 PM, Jactry Zeng wrote: Hi folks, this is Simplified Chinese translation for Wine's website, it's my first patch, thanks Qian Hong, Aron Xu, Jeremy and Hin-Tak for review. I appreciate for any comment. :-)
Re: [website] Added Simplified Chinese translation
Thanks for your work and remind. I will notice it next time. :-) 2013/2/1 Jeremy Newman jnew...@codeweavers.com Nice work. I did end up moving a few things around, and had to patch my language detection function, but it worked when I switched my browser over to zn-ch. I fixed the image as well. Also, please set your text editor to output 4 spaces instead of tabs. Thanks! -N On 01/30/2013 09:34 PM, Jactry Zeng wrote: Hi folks, this is Simplified Chinese translation for Wine's website, it's my first patch, thanks Qian Hong, Aron Xu, Jeremy and Hin-Tak for review. I appreciate for any comment. :-)
Re: kernel32/tests : added tests for copyfileex try6
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=24237 Your paranoid android. === WNT4WSSP6 (32 bit path) === Timeout
Re: [website] Added simplified chinese
--- On Wed, 30/1/13, Jactry jactr...@gmail.com wrote: From: Jactry jactr...@gmail.com Subject: Re: [website] Added simplified chinese To: Jeremy Newman jnew...@codeweavers.com Cc: wine-devel wine-devel@winehq.org Date: Wednesday, 30 January, 2013, 16:28 Hi Jeremy, 2013/1/30 Jeremy Newman jnew...@codeweavers.com:Patch looks good to me. Since I cannot read it, I need someone else here on wine devel to vouch for the translation. Just to make sure it is legit and not a very tricky spam or just a pass through google translate. So happy to hear that. But please ignore this patch first and I will send a newer soon. There was some wrong in the first patch... You will also need to add a string to the $this-languages array in the data class (include/data.php) Thanks for your remind. And I found that was anthor problem: the folder of Simplified Chinese in templates named zh_CN, but the picture in images/lang/ named zh.png. I think zh.png should be renamed as zh_CN.png. ( In general, something about Simplified Chinese was signed as zh_CN and zh_TW was left for Traditional Chinese)In glibc 2.16, the following locales are defined: zh zh-CN zh_HK zh_TW.Big5 zh_CN zh_CN.GB2312 zh_TW Not to forget zh_HK... I also seem to have come across zh_SG (for Singapore) although I cannot remember what context. 2013/1/30 Jeremy Newman jnew...@codeweavers.com Patch looks good to me. Since I cannot read it, I need someone else here on wine devel to vouch for the translation. Just to make sure it is legit and not a very tricky spam or just a pass through google translate. You will also need to add a string to the $this-languages array in the data class (include/data.php) I also noticed we are still using .cvsignore files, oops. Those should get moved to .gitignore, but I can do that later. -N On Tue 29 Jan 2013 08:34:28 AM CST, Jactry wrote: -Inline Attachment Follows-
