--with-nptl and glibc-2.3.2

[James Pellow]

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

[Raphaël Junqueira]

-----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-----

[Gregory M. Turner]

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/.

[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

[Gregory M. Turner]

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

[James Pellow]

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

[Piotr Pawłow]

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]

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