Re: Building Elfutils with Mingw32

[Ulf Hermann <ulf.hermann@qt.io>]

Hi,

I'll answer some questions here:

> Given that Windows doesn't even use ELF why would you even want elfutils on
> such a platform?

There is a large number of developers who build software for ELF-based 
embedded systems on windows and test/debug/profile/deploy it over some 
network or USB connection. Those people want to have elfutils for their 
debugging and profiling. They want to use elfutils on the host (the 
windows box) because that is much faster.

Those people are not me and I'm not talking about sanity.

Qt Creator (the Qt IDE) has a profiling view that takes data produced by 
perf and paints pretty graphs from that. The actual perf data is 
recorded on the target (potentially an embedded device), then streamed 
or copied to the host, then run through perfparser to produce meaningful 
stack traces. perfparser uses elfutils for the actual work. That work is 
quite heavy. A sample frequency of 1000Hz is not uncommon. Few embedded 
device can do that "on the side" while still producing meaningful 
results for the actual task. Finally, Qt Creator takes the processed 
data and displays a UI to explore it. There is another UI for the same 
data, "Hotspot" by Milian, but I don't know if that can run on windows.

> And why aren't people simply using cygwin for such a port?

If we built perfparser with cygwin, the people who use it would also 
need cygwin. People building embedded devices generally have a colorful 
mess of different tools, none of which you can rely on in advance. I 
haven't considered shipping cygwin with perfparser. Is that actually 
possible? It looks like it needs some installation procedure I would 
have to burden the user with.

> Without it you don't even have a normal POSIX like system.

Indeed, but we have gnulib and the various adapters I wrote myself (some 
of which should probably be upstreamed to gnulib). That deals with the 
problem. We get binaries that only depend on a basic windows system.

This comes at the price of using the most basic C library that Microsoft 
offers, msvcrt.dll. In order to use the elfutils libraries built that 
way you have to jump through the open/close and malloc/free hoops we 
provide in eu_compat.lib. However, that is only a problem for perfparser 
or other software linked against elfutils, not for the user.

> And when using mingw do people still use a normal gcc compiler (to cross
> build)? Or is the goal to build with some alternative windows
> compiler?

The gold standard would indeed be the ability to build it with Microsoft 
compilers and their associated C libraries. Then we could get  rid of 
the malloc/free and open/close hacks. However, given that Microsoft 
compilers have a rather different idea of C than elfutils, I didn't go 
there. Building it with gcc is more overhead for me when producing the 
binary. I cannot cleanly integrate it into the Qt Creator build system 
since that assumes it can use the same compiler for everything. However, 
for the users it doesn't make a difference.

> But if there is consensus (among the Windows hackers) about using one
> common target for the port then maybe we should have an official
> branch on sourceware?

Such a thing would certainly be welcome from my point of view!

> Also there is a mingw container setup on builder.sourceware.org which
> we might use for doing CI on the port?
> https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-fedora-mingw

I'll have to look at it in detail, but that also sounds great! So far 
there is no automated CI. I just run the tests manually when I change 
anything.

best regards,
Ulf