Hi, I am using Debian GNU/Linux Lenny with kernel verison 2.6.26-2-amd64 (x86_64) and want to compile wine 1.1.38 form the source Tarball. After successful compilation and installation through "make install", I get the following error when trying to run wine (e.g. when trying to run winecfg or any other application). wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: invalid ELF header To check whether this is really the case,I tried: readelf -h /usr/local/lib/wine/ntdll.dll.so it reports: readelf: Error: Not an ELF file - it has the wrong magic bytes at the start I checked whether this is really the file that I have compiled in the source directory (wine-1.1.38/dlls/ntdll/ntdll.dll.so). It is. I made sure that there is no other version of wine installed on the system. I also tried to run wine directly out of the source directory through the wine-1.1.38/tools/winewrapper. I get the same error. I guess that there is a problem with the configuration of the compile process. However, I was not able to find any previous post in the forum or the mailing lists that addresses exactly this problem. Does anybody know how to solve this problem? Yves
ysa wrote:> wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: invalid ELF headerLooks like you compiled Wine wrong. What all options did you give configure? Do you have all requirements installed? See this page for more info: http://wiki.winehq.org/WineOn64bit
vitamin wrote:> > This means you have broken preloader which breaks binaries when relocating to specific address. This is needed for some brain damaged programs like copy protection.Ah, this is an offset that prevents the code of ntdll.dll to be overwritten by such brain damaged programs? So maybe the problem was that the preloader was not set up correctly when I had this option activated?
ysa wrote:> Ah, this is an offset that prevents the code of ntdll.dll to be overwritten by such brain damaged programs?No, they assume that some dlls are always at the same address for every process. ysa wrote:> So maybe the problem was that the preloader was not set up correctly when I had this option activated?Wine uses preloader as a utility to mark particular libraries (*.dll.so are not a real dlls, they are dlls wrapped in shared libraries) to be loaded into specified address. If after that you get broken ELF library - it means your preloader is broken and can damage binaries. This can damage your entire system if you let it loose (allow to "optimize" your system).
vitamin wrote:> > Wine uses preloader as a utility to mark particular libraries (*.dll.so are not a real dlls, they are dlls wrapped in shared libraries) to be loaded into specified address. If after that you get broken ELF library - it means your preloader is broken and can damage binaries. This can damage your entire system if you let it loose (allow to "optimize" your system). >Maybe the problem is that it uses a 64-bit version of prelink. I have the Debian stable version (0.0.20071009-1) of prelink installed in /usr/sbin/prelink which is the one that is detected by the ./configure script.
The strange thing is that even the upstream version of Prelink from http://people.redhat.com/jakub/prelink/ destroys ntdll.dll.so. So in my perspective, there are two possibilities: 1. the problem lies in the Debian version of libelfg0 2. the problem lies in the way ntdll.dll.so is compiled on my system before prelink is applied Has somebody an idea?
I have found the real solution! The problem was that the Linux version of Antivir (http://www.avira.com) was installed on the system on which I was trying to compile Wine. It uses dazukofs (http://www.dazuko.org) to allow on-access virus scanning. Antivir did not put file into quarantine nor did it write anything to its log file but it was certainly the source of the error. So this is a bug of Antivir and not of Prelink.