elfutils for windows 0.173

elfutils for windows 0.173

[Ulf Hermann]

This is not an official release, but since I'm not the only one talking about porting elfutils to other platforms, I decided to point you to the place where the version of elfutils are available that we use to build the Qt Company versions of perfparser (that is, https://code.qt.io/cgit/qt-creator/perfparser.git/).

At https://download.qt.io/development_releases/prebuilt/elfutils/ you will find i686 and x86_64 windows builds of the code at https://code.qt.io/cgit/qt-creator/elfutils.git/ . This is basically elfutils plus a number of compatibility patches, and gnulib to add functionality missing from the windows C library. It also contains the 32bit ARM frame pointer fallback for stack unwinding. The latter only works for specific use cases. It can unwind through JIT'ed JavaScript code generated by QML, and otherwise doesn't create any problems I'm aware of.

The windows binaries are self-contained and the DLLs can be used with any compiler on windows. This means they contain parts of libgcc, libdl, libstdc++, libintl, libiconv, and libz. The respective sources are also provided at the above URL.

The binaries are built using mingw-w64 (http://mingw-w64.org/) on msys2 (http://www.msys2.org/). There is a README.windows in the source package with more details on how to build from source.

If you are going to link a windows application against one of the DLLs provided in the packages, there is one catch: In order not to require separate builds for the various compilers and C libraries Microsoft provides, all the binaries are linked against msvcrt.dll. Memory obtained via msvcrt.dll's malloc() cannot be free()'d with a different C library's free(), and vice versa. The same holds for open() and close(). If you link your application against msvcrt.dll, too, then this won't be a problem. If not, you can use the additional eu_compat.dll provided in the packages. eu_compat.dll forwards msvcrt.dll's malloc(), free(), open(), close() and a few other symbols, prefixing the names with "eu_compat_". Therefore, you can link against eu_compat.dll and make sure to only use eu_compat_open() for obtaining file handles to be passed to libelf or libdw, and the same for the other problematic functions. In version 0.173 there is also a libeu_compat.h to help you with this.

There are also linux x86_64 builds of the same code available at the above URL, but those are probably less interesting for anyone but myself.

Ulf