--with-nptl and glibc-2.3.2

[James Pellow]

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