Re: winegcc: Link with msvcrt on windows because of __wargv
GOUJON Alexandre wrote: > Le 03/19/10 03:42, James McKenzie a écrit : >> Please use [try 2] for any second send. Keeps things in order and lets >> others know that you have responded to errors. Also, put comments in >> the same message as the patch they apply to at the top of the message. >> >> Thank you. >> >> James McKenzi > > Ok so the next time, I will use [try n]. Thank you. > > But I don't really understand what you mean by "put comments in the > same message as the patch they apply to at the top of the message". > I mean, I did "git send-email > out/0002-winegcc-Link-with-msvcrt-on-windows-because-of-__war.patch > --compose" what sends two mails, the first with my comments only > (--compose) and the second one with the pacth only. > I don't you understand what I said. You had one message with what the patch should do and then another with the patch. When you do a git commit -a, you could add the comments to the file created by git. > And a last question : when I send for the first time a patch, should I > set "In reply-to" to "wine-patc...@winehq.org" or leave it blank ? > No. Set the In reply-to to wine-de...@winehq.org. This way replies will be sent to the Wine Development mailing list. Wine-patches should only have patch information. James
Re: Verbose explanation about the cygwin issue
GOUJON Alexandre writes: > Le 03/20/10 15:57, Alexandre Julliard a écrit : >> You can't add include or lib options, that will break the Mingw >> build. >> > > And what about #ifdef __CYGWIN__ ? > It sounds ugly but ... why not ? You can't use #ifdefs in winegcc. I suppose you could try to resolve __wargv dynamically at run-time. -- Alexandre Julliard julli...@winehq.org
Re: Verbose explanation about the cygwin issue
Le 03/20/10 15:57, Alexandre Julliard a écrit : You can't add include or lib options, that will break the Mingw build. And what about #ifdef __CYGWIN__ ? It sounds ugly but ... why not ? Thanks
Re: Wanted: Summer of Code Mentors
On Sat, Mar 20, 2010 at 9:48 AM, Maarten Lankhorst wrote: > Hi all, > > Any contributing wine members wishing to mentor for summer of code, or > help out with ranking proposals, please sign up as mentor for wine at > http://socghop.appspot.com/gsoc Of course if you want to apply as > student, you can't be a mentor. More feedback on the proposals is > appreciated as well. :) That link is broken, it's actually http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010 -- -Austin
Re: Verbose explanation about the cygwin issue
GOUJON Alexandre writes: > To fix it, we need to add msvcrt include (not to link with msvcrt : > it's a .o) > > ccache gcc-4 -D__WINE__ -c -o cmd.exe-iqnSoR-q4unrB.o cmd.exe-iqnSoR.c > -I../../include -I../../include/msvcrt/ > succeeds. > > At this point, we return from mingw_unicode_hack to line 722. > > And winegcc goes on: > > 779 _if (!opts->shared && (opts->use_msvcrt || > opts->unicode_app)) strarray_add(link_args, "-lmsvcrt"); > ...your patch > 781 _if (res_o_name) compile_resources_to_object( opts, resources, > res_o_name ); > ...the previous line works, no errors but > 783 _spawn(opts->prefix, link_args, 0); > ..fails > > Indeed, the linker [2] wants to link with msvcrt but don't know where > the library is : > > /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: > cannot find -lmsvcrt > collect2: ld returned 1 exit status > winegcc: ccache failed > make: *** [cmd.exe] Error 2 > > Finally, adding -L option [3], all's right. You can't add include or lib options, that will break the Mingw build. -- Alexandre Julliard julli...@winehq.org
Wanted: Summer of Code Mentors
Hi all, Any contributing wine members wishing to mentor for summer of code, or help out with ranking proposals, please sign up as mentor for wine at http://socghop.appspot.com/gsoc Of course if you want to apply as student, you can't be a mentor. More feedback on the proposals is appreciated as well. :) Cheers, Maarten
Re: FIXME: shader trailing '\n's.
On 20 March 2010 15:27, Francois Gouget wrote: > On Sat, 20 Mar 2010, Francois Gouget wrote: > >> --- >> dlls/wined3d/shader.c | 132 >> >> 1 files changed, 66 insertions(+), 66 deletions(-) > > Argh! > > Ignore this one. I need to check it out and did not mean to send it > (hence the FIXME). > I didn't check all of them, but the majority of those are intentional. There are probably nicer ways to trace the D3D shader assembly though.
Verbose explanation about the cygwin issue
Alexandre, (I hope I'm not being direspectful) your patch (561a3e643ea8b35adfc032d3afa979c622fcec23) did not work. I know that there is no Cygwin VM in WineTestBot yet to test such a patch. I think I was not very clear about the issue on cygwin so this time I'll be more .. verbose. Here is the relevant call stack of winegcc on cygwin : 1093 _int main(int argc, char **argv) 1373 _else if (linking) build(&opts); 559 _static void build(struct options* opts) 722 _strarray_add(link_args, mingw_unicode_hack(opts)); 547 _static const char *mingw_unicode_hack( struct options *opts ) 556 _return compile_to_object( opts, main_stub, NULL ); 457 _static const char* compile_to_object(struct options* opts, const char* file, const char* lang) 470 _compile(&copts, lang); 309 _static void compile(struct options* opts, const char* lang) ...here your patch didn't change anything because it hasn't been read 453 _spawn(opts->prefix, comp_args, 0); so winegcc [1] calls ccache gcc-4 -D__WINE__ -c -o cmd.exe-2VhiZq-6BngcL.o cmd.exe-2VhiZq.c -I../../include that leads to cmd.exe-2VhiZq.c: In function ‘main’: cmd.exe-2VhiZq.c:5: error: ‘__wargv’ undeclared (first use in this function) cmd.exe-2VhiZq.c:5: error: (Each undeclared identifier is reported only once cmd.exe-2VhiZq.c:5: error: for each function it appears in.) winegcc: ccache failed make: *** [cmd.exe] Error 2 To fix it, we need to add msvcrt include (not to link with msvcrt : it's a .o) ccache gcc-4 -D__WINE__ -c -o cmd.exe-iqnSoR-q4unrB.o cmd.exe-iqnSoR.c -I../../include -I../../include/msvcrt/ succeeds. At this point, we return from mingw_unicode_hack to line 722. And winegcc goes on: 779 _if (!opts->shared && (opts->use_msvcrt || opts->unicode_app)) strarray_add(link_args, "-lmsvcrt"); ...your patch 781 _if (res_o_name) compile_resources_to_object( opts, resources, res_o_name ); ...the previous line works, no errors but 783 _spawn(opts->prefix, link_args, 0); ..fails Indeed, the linker [2] wants to link with msvcrt but don't know where the library is : /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmsvcrt collect2: ld returned 1 exit status winegcc: ccache failed make: *** [cmd.exe] Error 2 Finally, adding -L option [3], all's right. Sorry for this looong mail. I think I won't send a patch but if you ask me. So thanks again and have a nice week end. --- [1] ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -mconsole -municode batch.o builtins.o directory.o wcmdmain.oCs.res Da.res De.res En.res Es.res Fr.res It.res Ja.res Ko.res Lt.res Nl.res No.res Pl.res Pt.res Ru.res Si.res Tr.res wcmdrc.res -o cmd.exe -lshell32 -luser32 -ladvapi32 -lkernel32 -lwine ../../libs/port/libwine_port.a [2] ccache gcc-4 -mconsole -o cmd.exe cmd.exe-iqnSoR-q4unrB.o -L../../dlls -L../../libs/wine batch.o builtins.o directory.o wcmdmain.o cmd.exe-XiDu0i.res.o -L../../dlls/shell32 -lshell32 -L../../dlls/user32 -luser32 -L../../dlls/advapi32 -ladvapi32 -L../../dlls/kernel32 -lkernel32 -L../../libs/wine -lwine -L../../libs/port -lwine_port -L../../dlls/winecrt0 -lwinecrt0 -lmsvcrt [3] ccache gcc-4 -mconsole -o cmd.exe cmd.exe-mfRWfQ-uwdRsu.o -L../../dlls -L../../libs/wine batch.o builtins.o directory.o wcmdmain.o cmd.exe-1DumDa.res.o -L../../dlls/shell32 -lshell32 -L../../dlls/user32 -luser32 -L../../dlls/advapi32 -ladvapi32 -L../../dlls/kernel32 -lkernel32 -L../../libs/wine -lwine -L../../libs/port -lwine_port -L../../dlls/winecrt0 -lwinecrt0 -lmsvcrt -L../../dlls/msvcr
Re: shell32: Add IPersistFile::GetCurFile implementation for IShellLink
On 03/18/2010 10:55 PM, Nikolay Sivov wrote:
Fixes http://bugs.winehq.org/show_bug.cgi?id=19627 from 1.2 list.
Hi Nikolay,
This introduces some test failures on Win9x (not WinMe) and NT4 in the
shlexec tests.
Could you agree with the attached patch?
--
Cheers,
Paul.
diff --git a/dlls/shell32/tests/shelllink.c b/dlls/shell32/tests/shelllink.c
index 52a21f1..6b1f218 100644
--- a/dlls/shell32/tests/shelllink.c
+++ b/dlls/shell32/tests/shelllink.c
@@ -421,8 +421,6 @@ void create_lnk_(int line, const WCHAR* path, lnk_desc_t*
desc, int save_fails)
lok(SUCCEEDED(r), "no IID_IPersistFile (0x%08x)\n", r);
if (SUCCEEDED(r))
{
-CHAR buff[MAX_PATH], buff2[MAX_PATH];
-IMalloc *pmalloc;
LPOLESTR str;
if (0)
@@ -434,8 +432,10 @@ void create_lnk_(int line, const WCHAR* path, lnk_desc_t*
desc, int save_fails)
/* test GetCurFile before ::Save */
str = (LPWSTR)0xdeadbeef;
r = IPersistFile_GetCurFile(pf, &str);
-lok(r == S_FALSE, "got 0x%08x\n", r);
-ok(str == NULL, "got %p\n", str);
+lok(r == S_FALSE ||
+broken(r == S_OK), /* Win9x/NT4 */
+"got 0x%08x\n", r);
+lok(str == NULL, "got %p\n", str);
r = IPersistFile_Save(pf, path, TRUE);
if (save_fails)
@@ -452,14 +452,19 @@ void create_lnk_(int line, const WCHAR* path, lnk_desc_t*
desc, int save_fails)
/* test GetCurFile after ::Save */
r = IPersistFile_GetCurFile(pf, &str);
lok(r == S_OK, "got 0x%08x\n", r);
+lok(str != NULL ||
+broken(str == NULL), /* Win9x/NT4 */
+"Didn't expect NULL\n");
+if (str != NULL)
+{
+IMalloc *pmalloc;
-WideCharToMultiByte( CP_ACP, 0, str, -1, buff, sizeof(buff), NULL,
NULL );
-WideCharToMultiByte( CP_ACP, 0, path, -1, buff2, sizeof(buff2), NULL,
NULL );
-
-lok(!strcmp(buff, buff2), "Expected %s, got %s\n", buff2, buff);
+lok(!winetest_strcmpW(path, str), "Expected %s, got %s\n",
+wine_dbgstr_w(path), wine_dbgstr_w(str));
-SHGetMalloc(&pmalloc);
-IMalloc_Free(pmalloc, str);
+SHGetMalloc(&pmalloc);
+IMalloc_Free(pmalloc, str);
+}
IPersistFile_Release(pf);
}
Re: inconsistencies in MCI headers w.r.t. to 64bit
wrote: > On 1/1/2004 you changed include/digitalv.h: > DWORD dwReturn to DWORD_PTR > However mmsystem.h uses DWORD. > > This is indeed what MSDN documents > http://msdn.microsoft.com/en-us/library/dd798406%28VS.85%29.aspx > http://msdn.microsoft.com/en-us/library/dd743409%28VS.85%29.aspx > > yet I refuse to believe it. I believe that all the MCI_XYZ_PARMS > structures are consistent, so that a generic MCI string command parser > is possible. That requires regular types. You should check the PSDK headers, not MSDN online. -- Dmitry.
Re: [PATCH] [WineDbg]: allow to specify which format to be used for integers in backtraces
Eric Pouech wrote: > hmm sounds like most of the code we have in not in sync > > [eric:~/work/wine-git debug64|(none)]$ grep TRACE dlls/*/*.c | grep > "%[0-9]*d" | wc -l > 8767 > [eric:~/work/wine-git debug64|(none)]$ grep TRACE dlls/*/*.c | grep > "%[0-9]*x" | wc -l > 4136 I specifiacally mentioned relay traces, not every TRACE statement in every module. -- Dmitry.
Re: oleaut32: Use FADF_HAVEVARTYPE before FADF_RECORD for safearrays
A test case would be a good idea. After spending a consider amount of time trying to writing a test case, It always failed on an XP box. This patch would just hide the issue instead of truly fixing it. Best Regards Alistair Leslie-Hughes
Re: [PATCH] msvcr90/tests: Add tests for _initterm_e [try 2]
On Sa, 2010-03-20 at 01:08 +0100, Piotr Caban wrote: > > You forgot to attach changes to configure.ac. Nope. That part is auto-generated, when Makefile.in is in the git tree: tools/make_makefiles Never add auto-generated changes to a patch -- By by ... Detlef
