[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ld/dlltool - .def file format error

From: Stefan Kowski
Subject: ld/dlltool - .def file format error
Date: Mon, 27 Mar 2006 17:21:22 +0200 (CEST)
User-agent: SquirrelMail/1.4.6

platform: Windows, MinGW 3.4.2


we found a problem with the .def file syntax in the GNU utilities.


Currently, we are modifying out build system to support the gcc compiler.
Linking some shared libraries, we found that the executables cannot be
executed because Windows reports an error, saying that the executable is
corrupt (it shows an error popup dialog). The same executable works fine if
the library is linked statically.

As we had a look at the import descriptor table of the executable (using
Microsofts DUMPBIN tool), we found the the shared library function had an
empty library name in the table, causing the error.

The reason was that we did not specify a library name in the .def file we
using to link the shared library.

Our .def file content:

      <function> @1

This file has been used successfully with Microsoft Visual Studio because
the library name after 'LIBRARY' is optional. If it is not specified, the
output name of the library will be used automatically.
(see http://msdn2.microsoft.com/en-us/library/30fw19zw(vs.80).aspx)

Without having the library name, gcc/ld will link the library, but it cannot
be used because the import library is not correct, making the executable
using it corrupt because of the empty library name.

Our suggestion: use the output name of the library if there is no name
specified in the .def file, to get the same behaviour as the Microsoft LINK

Why do we leave out the library name: this is because we use a version
information in the library name (e.g. mylib40.dll). If we had a library
name in the .def file, we would have to patch the .def file each time the
version number changes. As the Microsoft linker automatically uses the
dll output name, it works quite fine.

I hope you can use this suggestion to improve the linker. Feel free to ask
if you have any questions.

Best regards,
Stefan Kowski

reply via email to

[Prev in Thread] Current Thread [Next in Thread]