Hi,
can you try with preloading?
LD_PRELOAD="/usr/local/wine/lib/kernel32.dll.so /usr/local/wine/lib/ntdll.dll.so" wine regedit
Regards,
Raphael
----Message d'origine----
>De: James Pellow <james(a)alentdesignsolutions.com>
>A: wine-devel(a)winehq.com
>Sujet: Re: --with-nptl and glibc-2.3.2
>Date: Mon, 7 Apr 2003 17:37:02 +0000
>
>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
>
>