--with-nptl and glibc-2.3.2
Hi all, After reading the comments on the list reguarding glibc-2.3.2, it appears all I need to do is ./configure --with-nptl. Today, gave this a try and am having the following error messages repeated many times when trying to link d3d8: shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function `IDirect3DDeviceImpl_CreateStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1402): In function `IDirect3DDeviceImpl_DeleteStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' stateblock.o(.text+0x14ed): In function `IDirect3DDeviceImpl_BeginStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined --snip-- I have had this problem for the last couple of releases... My setup is an up to date gentoo, todays wine-cvs, glibc-2.3.2 and gcc-3.2.2. on an AMD thunderbird. Any ideas? On the gentoo formums, they all say downgrade to glibc-2.3.1, and hear I read use --with-nptl, but it doesn't work... I would rather not downgrade my glibc... Thanks for your help. Sorry if this is becomming a FAQ, but it still didn't seem clear to me. James
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 4 Avril 2003 16:26, James Pellow a écrit :
Hi all,
Hi,
After reading the comments on the list reguarding glibc-2.3.2, it appears all I need to do is ./configure --with-nptl. Today, gave this a try and am having the following error messages repeated many times when trying to link d3d8:
snif, why d3d8 ;( can you build ddraw ? have you test to build without opengl ?
shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function <snip>
yakk, maybe i forget to add a needed link to Makefile. Anyone know how to fix it ?
--snip--
I have had this problem for the last couple of releases...
James
Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+jth3p7NA3AmQTU4RAvotAJ4ij0f6Gu5iBLCcpw82ZHwyCKMlWgCfWdX2 g/mhuOYFJdYmCCmGqxoVBpM= =kK21 -----END PGP SIGNATURE-----
On Saturday 05 April 2003 07:21 am, Raphaël Junqueira wrote:
Le Vendredi 4 Avril 2003 16:26, James Pellow a écrit :
Hi all,
Hi,
After reading the comments on the list reguarding glibc-2.3.2, it appears all I need to do is ./configure --with-nptl. Today, gave this a try and am having the following error messages repeated many times when trying to link d3d8:
snif, why d3d8 ;( can you build ddraw ? have you test to build without opengl ?
shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function
<snip>
yakk, maybe i forget to add a needed link to Makefile. Anyone know how to fix it ?
--snip--
I have had this problem for the last couple of releases...
James
Regards, Raphael
yep, seen this too. The only "solution" I could find was to export ACCEPT_KEYWORDS="" and revert to glibc 2.3.1, Of course, this takes some doing, as screwing with glibc on gentoo usually does. The behavior reminds me of name-mangling mismatches you might see in C++ land from time-to-time... it's as though the linker doesn't know what API's are supposed to match up. I have not looked into what's really happening. FWIW, I have had to kill or rebuild every "~x86" gentoo system I have built. The official line of gentoo is that nobody should do this. Instead, the line goes, you should keep ACCEPT_KEYWORDS="" and only throw in "~x86" when you want some particular masked ebuild. Needless to say, I've broken this rule myself several times "just to see what happens" -- but it has always been pretty ugly. I wonder what happens if only glibc is upgraded, and everything else is left at ACCEPT_KEYWORDS="" versions? I never debugged it because I just don't trust the "~x86" toolchain ... at the time I was more concerned about getting myself back to a working sytsem than fixing wine ... :( IIRC the only part that would compile (and link) was ntdll (or was that kernel32?), and of course the "normal" unix programs in tools/. -- -gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken
On Sunday 06 April 2003 01:08 am, Gregory M. Turner wrote:
On Saturday 05 April 2003 07:21 am, Raphaël Junqueira wrote:
Le Vendredi 4 Avril 2003 16:26, James Pellow a écrit :
Hi all,
Hi,
After reading the comments on the list reguarding glibc-2.3.2, it appears all I need to do is ./configure --with-nptl. Today, gave this a try and am having the following error messages repeated many times when trying to link d3d8:
snif, why d3d8 ;( can you build ddraw ? have you test to build without opengl ?
ddraw does not build. If I disable opengl, ddraw fails in the same way. This is definately a glibc problem.
shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function
<snip>
yakk, maybe i forget to add a needed link to Makefile. Anyone know how to fix it ?
--snip--
I have had this problem for the last couple of releases...
James
Regards, Raphael
yep, seen this too. The only "solution" I could find was to export ACCEPT_KEYWORDS="" and revert to glibc 2.3.1, Of course, this takes some doing, as screwing with glibc on gentoo usually does.
The behavior reminds me of name-mangling mismatches you might see in C++ land from time-to-time... it's as though the linker doesn't know what API's are supposed to match up. I have not looked into what's really happening.
FWIW, I have had to kill or rebuild every "~x86" gentoo system I have built. The official line of gentoo is that nobody should do this. Instead, the line goes, you should keep ACCEPT_KEYWORDS="" and only throw in "~x86" when you want some particular masked ebuild. Needless to say, I've broken this rule myself several times "just to see what happens" -- but it has always been pretty ugly.
I wonder what happens if only glibc is upgraded, and everything else is left at ACCEPT_KEYWORDS="" versions? I never debugged it because I just don't trust the "~x86" toolchain ... at the time I was more concerned about getting myself back to a working sytsem than fixing wine ... :(
IIRC the only part that would compile (and link) was ntdll (or was that kernel32?), and of course the "normal" unix programs in tools/.
Thanks Gregory and Raphael for your answers. So far, I have been using "~x86" for two months now, with only minor glitchs. This is the biggest hangup I have found. I would be happy to look into the problem myself and provide a fix, but it seems work and taxes are taking up most of my time right now :( so I am curious how far out a fix might be. Is this being worked on? Thank you all for an incredible tool! - James
On Saturday 05 April 2003 02:52 pm, James Pellow wrote:
Thanks Gregory and Raphael for your answers. So far, I have been using "~x86" for two months now, with only minor glitchs. This is the biggest hangup I have found.
yes, it tends to work just fine, although from time to time it goes south :) It all depends on what the developers are working on, I guess. Typically all goes well until glibc upgrades start looming, and then gcc breaks and it's time to re-read the gentoo install guide ;) If you are a developer, it's a meaningful excercise; it's truly a bleeding edge system and any dependencies likely to affect your users in the coming months may hit you first. It's also fun to see the very latest efforts from the OSS world and beyond... but personally, for desktop use, it's a bit too demanding, I need to save my mental energy ;) My only advice would be: habitually use the -b flag to emerge so that when and if you kill your system you can revive it by untarring old emerges.
I would be happy to look into the problem myself and provide a fix, but it seems work and taxes are taking up most of my time right now :( so I am curious how far out a fix might be. Is this being worked on? Thank you all for an incredible tool! - James
Tried Piotr Pawlow's recently posted fix?
Try this:
$ sed -e 's/-z,defs/-z=defs/g' <configure.ac >tmp && aclocal && autoconf tmp >configure
and then as usual:
$ ./configure && make depend && make
-- -gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken
On Sunday 06 April 2003 05:48 am, Gregory M. Turner wrote:
On Saturday 05 April 2003 02:52 pm, James Pellow wrote:
Thanks Gregory and Raphael for your answers. So far, I have been using "~x86" for two months now, with only minor glitchs. This is the biggest hangup I have found.
yes, it tends to work just fine, although from time to time it goes south :)
It all depends on what the developers are working on, I guess. Typically all goes well until glibc upgrades start looming, and then gcc breaks and it's time to re-read the gentoo install guide ;) If you are a developer, it's a meaningful excercise; it's truly a bleeding edge system and any dependencies likely to affect your users in the coming months may hit you first. It's also fun to see the very latest efforts from the OSS world and beyond... but personally, for desktop use, it's a bit too demanding, I need to save my mental energy ;) My only advice would be: habitually use the -b flag to emerge so that when and if you kill your system you can revive it by untarring old emerges.
I would be happy to look into the problem myself and provide a fix, but it seems work and taxes are taking up most of my time right now :( so I am curious how far out a fix might be. Is this being worked on? Thank you all for an incredible tool! - James
Tried Piotr Pawlow's recently posted fix?
Try this:
$ sed -e 's/-z,defs/-z=defs/g' <configure.ac >tmp && aclocal && autoconf tmp >configure
and then as usual:
$ ./configure && make depend && make
Ok, I have done the first round of testing on my new wine with the above fix. The above fix does allow wine to compile, but there do seem to be some runtime problems that remain. I have a stand alone installation of wine. First I tried to install an app and ran into the following message: err:module:BUILTIN32_dlopen failed to load .so lib for builtin advapi32.dll: /usr/local/wine/lib/wine/advapi32.dll.so: undefined symbol: GetComputerNameW err:module:import_dll Loading module (file) ADVAPI32.dll (which is needed by D:\setup.exe) failed (error -1073741702). I did the following in lib/wine: for FILE in `ls *.so`; do objdump -t $FILE | grep GetComputerNameW && ls -l $FILE; done and see that all files that that define this symbol are links to kernel32.dll.so. The problem seems obvious when I do: ldd advapi32.dll.so libwine.so.1 => /usr/local/wine/lib/libwine.so.1 (0x40042000) libwine_unicode.so.1 => /usr/local/wine/lib/libwine_unicode.so.1 (0x4005a000) libm.so.6 => /lib/libm.so.6 (0x4013b000) libc.so.6 => /lib/libc.so.6 (0x4015d000) libdl.so.2 => /lib/libdl.so.2 (0x40285000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) It appears that advapi32.dll.so does not claim to need kernel32.dll.so, but it does! Any ideas on what went wrong? Regedit did not run for a similar reason. Thanks for your help. James Pellow
On Saturday 05 of April 2003 22:52, James Pellow wrote:
ddraw does not build. If I disable opengl, ddraw fails in the same way. This is definately a glibc problem.
I have similar problem, and it does not look like a glibc incompatibility to me. I had even built Wine 2003-03-18 with my current (2.3.2) glibc version less than 3 weeks ago, but I have upgraded many packages since then. I can build WineX 3.0pre1 or Wine versions using older build process (for example 20020710) without problems, however all new versions won't build. It fails at the linking stage, and the command that fails looks like this: gcc -shared -Wl,-Bsymbolic,-z,defs d3d8.spec.o basetexture.o cubetexture.o d3d8_main.o device.o directx.o indexbuffer.o resource.o shader.o stateblock.o surface.o swapchain.o texture.o vertexbuffer.o volume.o volumetexture.o vshaderdeclaration.o d3d8.dll.dbg.o -o d3d8.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/uuid -lwine_uuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port -lm -lc It outputs lots of undefined references - as in the post that started this thread. I can "fix" it by linking with libraries listed as IMPORTS in "dlls/d3d8/Makefile.in", I can even add it to "dlls/Makedll.rules.in" to make it work with all libraries, but there is another problem: there are no inter-DLL dependencies in my "dlls/Makefile" so DLLs are built in the wrong order. I can also "fix" it by adding a code creating those dependencies to "dlls/make_dlls" (copy&paste from old Wine package), but I wonder why it worked before and why it suddenly stopped. Any ideas? PS. Please ignore my previous message, that change would make Wine compile but not run. -- Piotr Pawłow mailto:pp(a)siedziba.pl
On Friday 04 of April 2003 16:26, James Pellow wrote:
this a try and am having the following error messages repeated many times when trying to link d3d8: shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc'
Try this: $ sed -e 's/-z,defs/-z=defs/g' <configure.ac >tmp && aclocal && autoconf tmp >configure and then as usual: $ ./configure && make depend && make
participants (4)
-
Gregory M. Turner -
James Pellow -
Piotr Pawłow -
Raphaël Junqueira