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
