[pkg-wine-party] Bug#556019: Bug#556019: wine-unstable: fails to load native .dll files

[Jacob Emmert-Aronson]

>Jacob Emmert-Aronson skrev:
>> Package: wine-unstable
>> Version: 1.1.32-1
>> Severity: grave
>> Justification: renders package unusable
>> 
>> In the upgrade to 1.1.32-1, wine moved renamed most 'wine' folders
>> to 'wine-unstable', but in amd64, /emul/ia32-linux/usr/share/wine/
>> was not renamed.  Further, the wine.inf simlink in this folder
>> points to /usr/share/wine/wine.inf, which no longer exists, the
>> file having been moved to /usr/share/wine-unstable.
>
>I have great difficulties figuring out what you mean.
>
>For one, there's no such thing as /emul/ia32-linux/usr/share/wine in
>the packages, there should probably not even be
>a /emul/ia32-linux/usr/share on the system. No packages built for
>squeeze/sid even contain /emul/ia32-linux anymore. (My lenny
>backports on people.debian.org may use /emul/ia32-linux/usr/lib,
>though; perhaps there's something broken in them, for all I know,
>but if you're using them, try to use the packages in sid instead.)

In that case, I think I can piece together where the simlink must have
come from.  I still had /lib32 and /usr/lib32 as simlinks to
directories within /emul/ia32-linux.  Because wine.bin uses a relative
link to call wine.inf, it was (on my system) attempting to find
wine.inf in a subdirectory of /emul/ia32-linux.  I must have, at some
point in the past, installed the simlink there myself and then
forgotten about it, rather than taking this as a sign that /emul/
should not still be on my system.

>Also, wine.inf is not a symlink, and to my knowledge, it never has
>been.
>
>> Even after correcting the simlinks so that the wine executable
>> finds wine.inf, any program that requires a native dll file
>> crashes upon being run in wine as wine cannot load the dll files.
>> For example:
>> 
>>   err:module:import_dll Loading library nvcuda.dll (which is
>> needed by L"Z:\\home\\jre21\\fah-gpu\\FahCore_11.exe") failed
>> (error c0000020). err:module:import_dll Loading library cudart.dll
>> (which is needed by L"Z:\\home\\jre21\\fah-gpu\\FahCore_11.exe")
>> failed (error c0000020). err:module:LdrInitializeThunk Main exe
>> initialization for L"Z:\\home\\jre21\\fah-gpu\\FahCore_11.exe"
>> failed, status c0000135
>
>Error code c0000020 (STATUS_INVALID_FILE_FOR_SECTION) is a type of
>critical failure in attempting to load a PE image, but the above
>isn't enough to understand where it comes from. Unless, I suppose,
>this is a problem of Wine not finding the correct fakedlls or
>something.
>
>Anyway, from the looks of it, your system is seriously broken and you
>need to repair it before attempting to run Wine. At a minimum,
>completely uninstall Wine, completely remove the obsolete
>/emul/ia32-linux and other stuff lingering around that shouldn't
>exist, and maybe then try reinstalling Wine.
>
>If the packages themselves had been this broken, I'd probably have
>received bug reports about that already, from users with less broken
>setups. (At least I hope so...)

I deleted the simlinks to /emul/ia32/... and reinstalled every package
that uses /lib32 or /usr/lib32, and then purged and re-installed all
my wine packages.  It was then that I discovered exactly why the
library failed to load.  The library is a wrapper that converts cuda's
Windows system calls to their Linux equivalents.  It is linked against
libwine.so.1, which, in the transition to 1.1.32, the debian package
renames to libwine-unstable.so.1.  Installing libwine.so.1 as a
simlink to libwine-unstable.so.1 solved the issue.

I apologize for assigning incorrect severity; the issue turned out to
be much more limited in scope than I had at first assumed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-wine-party/attachments/20091113/17f00118/attachment.pgp>