--with-nptl and glibc-2.3.2
james at alentdesignsolutions.com
Sat Apr 5 14:52:10 CST 2003
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
> 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!
More information about the wine-devel