On 2018-03-28 at 15:44, Markus Grunwald wrote: > Hello, > > to play some old games, I wanted to start wine, but it always fails with > errors like that in the attached gna.txt :( > > Not even winecfg is starting (I created gna.txt with starting winecfg). > > It used to work so well a while ago... > > > That's what I have installed (debian testing, upgraded today): > > % dpkg -l wine\* | egrep '^ii' > ii wine 3.0-1 all Windows API > implementation - standard suite > ii wine32:i386 3.0-1 i386 Windows API > implementation - 32-bit binary loader > ii wine64 3.0-1 amd64 Windows API > implementation - 64-bit binary loader > ii winetricks 0.0+20180217-1 all package manager for > Wine to install software easily > > > > Can you help me with that, please? Looking online, the large majority of places where "failed to map segment from shared object" occurs outside of this post itself seem to have an additional explanatory comment appended to it. In the log you attached, no such comment appears to be present. I haven't found much of anything hinting at what might lead to that situation. Possible hints I have found for other causes of that "umbrella" message include: * ulimit too low. (Results in "Cannot allocate memory" explanatory comment.) * One or more of the executable files which the program is trying to load (here, 'version.dll.so') is stored on a filesystem which is mounted noexec. (Results in "Operation not permitted" explanatory comment. Since the paths indicate that this is apparently being loaded from under /usr/lib/i386-linux-gnu/, it doesn't seem very likely that noexec could be in play.) * The relevant executable file does not have the execute bit set. (Not clear what explanatory comment results. I don't think this should apply for .dll.so files like this one; certainly the analogous file for my Wine install doesn't have that bit set.) * SELinux is blocking the file from being loaded. (Results in "Permission denied" explanatory comment. Other LSMs, such as AppArmor, might presumably result in the same problem.) There's also a semi-weird case where access to local files was mediated by ActiveDirectory authentication, and the environment where the program was being launched wasn't retaining the environment variable which provided the username against which the authentication would be done, so the program couldn't access local files. That seems unlikely to apply, however. I don't know whether any of these may bear at all on your environment, but at least they might give you places to start looking... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature