ntdll.dll.so: invalid ELF header

[ysa]

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

[vitamin]

wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: invalid ELF header

Looks 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

[ysa]

vitamin: At least in the case of the debian source package I'm pretty sure that I have all the build dependencies, since I have run apt-get build-dep wine before compiling Wine.

However, I solved the problem by removing the line (commenting it out)

Code: Select all

EXTRADLLFLAGS = -Wl,--image-base,0x7bc00000

from the file:
dlls/ntdll/Makefile.in

and removing (commenting out) the options -Wl, --image-base,0x7bc0000

from the line:

Code: Select all

EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b800000

in the file:
dlls/kernel32/Makefile.in

Afterwards I run ./configure && make depend && make again.

Then the corresponding dll.so files were real ELF binaries and winecfg works as well as well as the game Zork Nemesis (at least it starts now).

readelf -h dlls/ntdll/ntdll.dll.so reports now:

• ELF Header:
  Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data: 2's complement, little endian
  Version: 1 (current)
  OS/ABI: UNIX - System V
  ABI Version: 0
  Type: DYN (Shared object file)
  Machine: Intel 80386
  Version: 0x1
  Entry point address: 0x1fae0
  Start of program headers: 52 (bytes into file)
  Start of section headers: 2441904 (bytes into file)
  Flags: 0x0
  Size of this header: 52 (bytes)
  Size of program headers: 32 (bytes)
  Number of program headers: 5
  Size of section headers: 40 (bytes)
  Number of section headers: 38
  Section header string table index: 35

I had the same problem when I tried to compile the stable version 1.0.1 from the debian source package. And the same solution applies there.

I am happy that it works now but I don't understand why this linker option (--image-base 0x7b800000) I removed was there in the first place. It seems to prevent Wine from running after compilation on my machine. And without it Wine seems to run without problems. So does anybody know why it there?

Yves

[vitamin]

However, I solved the problem by removing the line (commenting it out)

Code: Select all

EXTRADLLFLAGS = -Wl,--image-base,0x7bc00000

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.

[ysa]

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?

[vitamin]

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.

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).

[ysa]

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.

[ysa]

I read on http://wiki.winehq.com/Prelink that prelink is just used to modify the base address and does not have to be active at run time.

By looking at the source code of winegcc and setting the -v (verbose) option, I found out that prelink is called the following way after ntdll.dll.so has been compiled by gcc:

Code: Select all

/usr/sbin/prelink --reloc-only 0x7bc00000 ntdll.dll.so

If one does not pass the the options "-Wl, --image-base,0x7bc0000" to winegcc, then prelink is not called.

Therefore I'm now convinced that prelink destroys my ntdll.dll.so.

I wonder which version of prelink would be needed for Wine to compile ntdll.dll.so correctly?

Btw. I tried to use the 32-bit-Debian version of prelink but that didn't change anything.

[vitamin]

I read on http://wiki.winehq.com/Prelink that prelink is just used to modify the base address and does not have to be active at run time.
I found out that prelink is called the following way after ntdll.dll.so has been compiled by gcc.

Correct that's what I meant saying Wine uses it as "utility". It's a post compile operation.

I wonder which version of prelink would be needed for Wine to compile ntdll.dll.so correctly?

It should understand 32-bit ELF files just fine. 64-bit prelink work here just fine (64-bit distro). So you don't any special version. It more looks like some bug with prelink. You might want to submit bug report to your distro.

[ysa]

You might want to submit bug report to your distro.

I filed a bug report on the Debian version of prelink:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569318

[ysa]

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?

[ysa]

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.

[vitamin]

So this is a bug of Antivir and not of Prelink.

Awesome... I'd really suggest you throwing that POS away if it just decides to damage files like that. Besides all on-access anti-viruses are ineffective. As Rutkowska put it:

An A/V product, at least in the form as we have them today, is a waste of money and resources.

[Eyeez84]

I read on http://wiki.winehq.com/Prelink that prelink is just used to modify the base address and does not have to be active at run time.

By looking at the source code of winegcc and setting the -v (verbose) option, I found out that prelink is called the following way after ntdll.dll.so has been compiled by gcc:

Code: Select all

/usr/sbin/prelink --reloc-only 0x7bc00000 ntdll.dll.so

If one does not pass the the options "-Wl, --image-base,0x7bc0000" to winegcc, then prelink is not called.

Therefore I'm now convinced that prelink destroys my ntdll.dll.so.

I wonder which version of prelink would be needed for Wine to compile ntdll.dll.so correctly?

Btw. I tried to use the 32-bit-Debian version of prelink but that didn't change anything.

also face this problem. :'(

[vitamin]

also face this problem. :'(

And I'm assuming you read the entire post and found the solution too?

[Bryanf]

This is a complicated problem. Fortunately, solution is posted here.

[oiaohm]

I have a felling this should be a wiki page. Complex and down right annoying on what needs to be checked.

[Blowbrown4]

Good day, i've got a problem with antivir, probably someone knows:
error (211): program file of AntiVir has been modified".
I wonder if prelink is affecting it?

[dimesio]

Good day, i've got a problem with antivir, probably someone knows:
error (211): program file of AntiVir has been modified".
I wonder if prelink is affecting it?

What does this have to do with Wine?

[jjmckenzie]

On Wed, Aug 10, 2011 at 5:56 AM, Blowbrown4 <[email protected]> wrote:

Good day, i've got a problem with antivir, probably someone knows:
error (211): program file of AntiVir has been modified".
I wonder if prelink is affecting it?

Is a Linux anti-virus program complaining about one of the Wine static
library objects (.so file) after you upgraded to a new version of
Wine? This should be expected and you should rescan that file to get
the new file signature. If you have not changed the file, then
something is going on with your system and you should seek assistance
in an appropriate venue.

James

[WineGeek79]

Good day, i've got a problem with antivir, probably someone knows:
error (211): program file of AntiVir has been modified".
I wonder if prelink is affecting it?

What does this have to do with Wine?

That is what I don`t get here also