- Wine-Devel - list.winehq.org

Re: Patch to add glut32.dll.
by Lionel Ulmer Nov. 21, 2003

Nov. 21, 2003

Jacek, It seems your patch was line-wrapped (which is not a good thing). Moreover, it's not necessary to add the patch against 'configure', you just need to tell Alexandre in the patch mail that he needs to re-generate it himself when comitting. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Compiler problems
by Marcelo Duarte Nov. 21, 2003

Nov. 21, 2003

Updating wine to current cvs, I get an error, can someone help me: I run ./configure; make depend && make make[2]: Entering directory `/home/mduarte/wine-cvs/dlls/winmm/winearts' gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine -L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid -L../../../libs/port -lwine_port -lm -lc /usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a collect2: ld returned 1 exit status make[2]: ** [winearts.drv.so] Erro 1 make[2]: Leaving directory `/home/mduarte/wine-cvs/dlls/winmm/winearts' make[1]: ** [winmm/winearts] Erro 2 make[1]: Leaving directory `/home/mduarte/wine-cvs/dlls' make: ** [dlls] Erro 2 Entering in directory loader and make: [mduarte(a)mduarte loader]$ make clean rm -f *.o *.a *.so *.ln *.so \#*\# *~ *% .\#* *.bak *.orig *.rej *.flc *.spec.c *.spec.def *.dbg.c y.tab.c y.tab.h lex.yy.c core rm -f wine-glibc wine-kthread wine-pthread wine [mduarte(a)mduarte loader]$ make gcc -c -I. -I. -I../include -I../include -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o glibc.o glibc.c gcc -o wine-glibc -Wl,--section-start,.interp=0x3c000100 -Wl,--export-dynamic glibc.o -L../libs/wine -lwine -L../libs/port -lwine_port glibc.o(.text+0x84): In function `get_threading': /home/mduarte/wine-cvs/loader/glibc.c:61: undefined reference to `pthread_create' glibc.o(.text+0x90):/home/mduarte/wine-cvs/loader/glibc.c:62: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: ** [wine-glibc] Erro 1 -- Marcelo Duarte

1 1

Compiling winearts - please replay!
by Marcelo Duarte Nov. 21, 2003

Nov. 21, 2003

I updated to new wine version and had errors, cvs update, and errors persists: make[2]: Entering directory `/home/mduarte/wine-20031118/dlls/winmm/winearts' gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine -L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid -L../../../libs/port -lwine_port -lm -lc /usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a collect2: ld returned 1 exit status make[2]: ** [winearts.drv.so] Erro 1 make[2]: Leaving directory `/home/mduarte/wine-20031118/dlls/winmm/winearts' make[1]: ** [winmm/winearts] Erro 2 make[1]: Leaving directory `/home/mduarte/wine-20031118/dlls' make: ** [dlls] Erro 2 Someone knows what is happen? -- Marcelo Duarte

1 0

help with linking needed
by Ralf Juengling Nov. 21, 2003

Nov. 21, 2003

I have successfully compiled sources of a Windows application, but when starting up, it tries to locate and link to a windows dll to access some C library functions: ... err:module:import_dll No implementation for cw3230.DLL._strlen imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._strncpy imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._strtok imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._tolower imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._toupper imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:LdrInitializeThunk Main exe initialization failed, status c0000135 First of all: Where does the name "cw3230.DLL" come from -- Wine didn't install such a dll on my system? Second, all these functions seem to be C library functions and I want to link against the library available on my linux system. So I added 'c' to LIBRARIES in the Makefile.in created by winemaker. But this didn't make any difference. I hope somebody can introduce me to secrets of simultaneously linking against Winelib & Unix dynamic libraries.. Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

1 0

Re: regedt: fix couple of HeapReAlloc()s
by Steven Edwards Nov. 21, 2003

Nov. 21, 2003

I think HeapReAlloc problem exists in the listbox control. We have a patch in ReactOS CVS for it but I dont have time to try and merge it. Thanks Steven --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > ChangeLog > HeapReAlloc() does not allocate memory. > > Index: programs/regedit/regproc.c __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 1

include files
by Ralf Juengling Nov. 21, 2003

Nov. 21, 2003

A Makefile created by winemake & configure adds /whereever/include/wine/windows to the include paths. Why doesn't it also add /whereever/include/wine/msvcrt ? What is the status of the include files in msvcrt? Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

3 5

Re: _end Symbol and Mac OS X
by Alexandre Julliard Nov. 21, 2003

Nov. 21, 2003

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > On Mac OS X There is no _end symbol. There is a convenience function > get_end() to replace it, mainly because of the Mach-O file format. So > we have to get the value of get_end at launch time and store it in the > nt_header. Does get_end really return the _end value of the current library? I suspect it returns the value for the main executable in all cases, which is not what we need here. -- Alexandre Julliard julliard(a)winehq.com

2 2

Windows programs no more running with the new wine-glibc
by Sylvain Petreolle Nov. 20, 2003

Nov. 20, 2003

With yesterday cvs update, whch adds a glibc-threading detection, wine doesnt load a _Windows_ program anymore. Using the RedHat rpm Yarrow kernel, I get : err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\\arakas.exe" as Win32 binary Funny thing : If I set up a symlink to the wine-glibc in another directory, it works without problems. [syl(a)wine c]$ ls -l /usr/local/bin/wine /home/wine/loader/wine-* -rwxr-xr-x 1 syl wine 97265 nov 13 20:08 /home/wine/loader/wine-glibc -rwxr-xr-x 1 syl wine 156037 nov 13 20:08 /home/wine/loader/wine-kthread -rwxr-xr-x 1 syl wine 109482 nov 13 20:08 /home/wine/loader/wine-pthread -rwxr-xr-x 1 root root 97265 nov 13 20:29 /usr/local/bin/wine With plain binary, not working : [syl(a)wine c]$ which wine /usr/local/bin/wine [syl(a)wine c]$ wine arakas.exe err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\\arakas.exe" as Win32 binary With the symlink : [syl(a)wine c]$ ls -l /c/wine lrwxrwxrwx 1 syl wine 28 nov 13 20:41 /c/wine -> /home/wine/loader/wine-glibc [syl(a)wine c]$ ./wine arakas.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in dlls/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. Any thoughts ? ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

5 13

removed problem with OpenGL extensions under X11
by Daniel Skorka Nov. 20, 2003

Nov. 20, 2003

This patch fixes a problem with bad OpenGL libraries wich uncorrectly report the Extensions they support. Those libs would incorrectly report not supporting glXGetProcAddresARB, on which wine relies for OpenGL extension support. The problem was noticed with libGL from XFree86 4.2 under Linux x86. ChangeLog: * dlls/opengl32/wgl.c: Daniel Skorka <skorka(a)gmx.net> Fixed a problem using glXGetProcAddresARB with bad OpenGL libs. ---snip--- ? patch.diff ? miscemu/Makefile Index: dlls/opengl32/wgl.c =================================================================== RCS file: /home/wine/wine/dlls/opengl32/wgl.c,v retrieving revision 1.39 diff -u -u -r1.39 wgl.c --- dlls/opengl32/wgl.c 17 Sep 2003 20:04:25 -0000 1.39 +++ dlls/opengl32/wgl.c 20 Nov 2003 22:33:51 -0000 @@ -671,12 +671,12 @@ XFree(vis); LEAVE_GL(); - if ((extensions != NULL) && (strstr(extensions, "GLX_ARB_get_proc_address"))) { - opengl_handle = wine_dlopen(SONAME_LIBGL, RTLD_NOW|RTLD_GLOBAL, NULL, 0); - if (opengl_handle != NULL) { - p_glXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0); - wine_dlclose(opengl_handle, NULL, 0); - } + opengl_handle = wine_dlopen(SONAME_LIBGL, RTLD_NOW|RTLD_GLOBAL, NULL, 0); + if (opengl_handle != NULL) { + p_glXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0); + wine_dlclose(opengl_handle, NULL, 0); + if (p_glXGetProcAddressARB == NULL) + TRACE("could not find glXGetProcAddressARB in libGL.\n"); } if (default_cx == NULL) { ---snip---

1 1

Re: wineps: fix a few HeapReAlloc()s
by Huw D M Davies Nov. 20, 2003

Nov. 20, 2003

On Thu, Nov 20, 2003 at 03:33:48PM -0500, Dimitrie O. Paun wrote: > Huw, > I didn't dig deep enough to see if glyphList/->glyph_sent > can't be NULL at that point, but it wasn't obvious to me > that they can't. You know this part a lot better than myself, > can you please check that I'm not adding extranous uglifying > bits to the code? Hi Dimi, All of these are unnecessary afaics. glyphList gets alloc'ed in GlyphListInit and the two glyph_sent's are alloc'ed in T{1|42}_download_header Huw.

2 1