Control: tag -1 + wontfix Hi Niels,
On Thu, 08 Sep 2016 21:56:38 +0200, [email protected] (Niels Möller) wrote: > The default dll search path used by wine32 does not include the location > of the libgcc_s_sjlj-1.dll library supplied with gcc-mingw-w64-i686. > > I can't say if it's wine, mingw, or both, which are wrong here. Wine's > dll directory, /usr/lib/i386-linux-gnu/wine/, seems reasonable, so I'm > filing it on mingw. But maybe it's no good idea to have > gcc-mingw-w64-i686 install files in the same directory. So we might need > to extend wine's dll path to add some suitable directory for other > packages to install dlls in. gcc-mingw-w64 ships different variants of libgcc, so it can’t just drop one in a directory on the default Wine DLL path — Windows programs built with gcc-mingw-w64 have to ensure that the appropriate DLLs are available alongside them. > My expectation is that if I compile a program using i686-w64-mingw32-gcc > or i686-w64-mingw32-g++, I should be able to run that executable using > wine. I've used to be able to do that, not sure at which package upgrade > it stopped working. Here's an example where this fails: I don’t think it was ever possible to do that; even when gcc-mingw-w64 (or gcc-mingw32) shipped a single version of libgcc, it wasn’t provided in a directory Wine would use on its own. What *is* possible is that previous versions of the compiler didn’t produce binaries needing libgcc in as many cases, so you might end up with a binary which just works whereas now you don’t. > #include <cstring> > #include <stdio.h> > > int > main(int argc, char **argv) > { > printf("foo\n"); > return 0; > } > > To reproduce, save into a file "hello.cxx", compile using > > i686-w64-mingw32-g++ hello.cxx > > and run it using > > WINEDEBUG=err+all wine ./a.exe > > Expected result is a line "foo" written to stdout. Instead, I get > the error > > err:module:import_dll Library libgcc_s_sjlj-1.dll (which is needed by > L"Z:\\home\\nisse\\hack\\test\\a.exe") not found > err:module:LdrInitializeThunk Main exe initialization for > L"Z:\\home\\nisse\\hack\\test\\a.exe" failed, status c0000135 > > By strace (strace -f -e open wine a.exe), I see that wine attempts to open > > [pid 31177] > open("/usr/lib/wine/../i386-linux-gnu/wine/./libgcc_s_sjlj-1.dll.so", > O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 31177] > open("/usr/lib/wine/../i386-linux-gnu/wine/./libgcc_s_sjlj-1.dll.so", > O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) which seems > ok, /usr/lib/i386-linux-gnu/wine/ exists and there are a lot of dll files > there. But not libgcc. > > $ apt-file search libgcc_s_sjlj > gcc-mingw-w64-i686: > /usr/lib/gcc/i686-w64-mingw32/4.9-posix/libgcc_s_sjlj-1.dll > gcc-mingw-w64-i686: > /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc_s_sjlj-1.dll > > I have this package installed, and the files exist on my system, they > just aren't found by wine. Besides the different location, also note the > different file name, ".dll" vs ".dll.so". Yes, .dll.so files are Wine-specific. The goal of the mingw-w64 packages is to produce binaries which work on Windows (and incidentally, Wine). > The debian wine* packages I have installed are wine, wine32 and wine64, > all version 1.8.4-1. > > The debian gcc-mingw* packages installed are gcc-mingw-w64, > gcc-mingw-w64-base, gcc-mingw-w64-i686, gcc-mingw-w64-x86-64, all > version 4.9.1-19+14.3. > > I'm running this on an x86_64 machine running mostly debian stable, > but certain packages, including wine, installed from testing (apt-get > install -t testing wine). > > Some curiosities: > > * Switching the order of the two includes, or deleting the include of > <cstring.h>, makes this example work. It then prints out the message > "foo", as expected. (The executable then no longer depends on the > libgcc dll, I guess). > > * The strace output also shows that wine attempts to open > "/usr/lib/wine/../i386-linux-gnu/wine/./%1.dll.so" Regards, Stephen
pgpwV2cZqpSjk.pgp
Description: OpenPGP digital signature
