Re: Building Elfutils with Mingw32
Ulf, My only other suggestion for avoiding manually specifying O_BINARY and O_TEXT would be to override the open call on Windows and use O_BINARY as the default and switch to O_TEXT on a condition. Maybe that condition could be based on the file signature or some other analysis of the file contents. Probably not the most efficient or deterministic solution, but it's the only alternative I can think of. Specifying O_BINARY and O_TEXT is probably the better option. Gnulib states that O_BINARY and O_TEXT are "essential for portability to native Windows platforms" https://www.gnu.org/software/gnulib/manual/html_node/fcntl_002eh.html Best, Colin From: Ulf Hermann Sent: Friday, September 15, 2023 01:57 To: McAllister, Colin ; elfutils-devel@sourceware.org Subject: Re: Building Elfutils with Mingw32 CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. Indeed I have noticed the other patches, but I don't think they are the same as mine. So, now we have a three way merge. I guess some more of the changes could be merged if properly cleaned up and made to benefit other obscure platforms, too. However, there are a few I got a definite "no" for. In particular the windows dance around text/binary mode when opening files was not welcome. I couldn't come up with a better solution than adding an O_BINARY or O_TEXT to every single open() call. We actually need the distinction as some files need to be opened in text mode for the tests to pass. If you can come up with anything better here, please let me know. best regards, Ulf
make check fails for version 0.189 on aarch64
Hi, I'm currently trying to build elfutils in version 0.189 on an aarch64 system. Unfortunately, make check fails with the following errors: https://nopaste.ipfire.org/view/Sx7pjy4g The full log can be found here: https://pakfire.ipfire.org/jobs/28a23239-80a6-4a24-b506-dbc367d96afa/log The same configuration works on x86_64. I currently run out of ideas what to try next. I know that the test suite passes on Debian for aarch64. So there must be an error with the system itself, but as said, I lack ideas how to debug this further. Some input would be highly appreciated. Greetings Jonatan
Re: Building Elfutils with Mingw32
Hi Colin, Hi Ulf, On Thu, Sep 14, 2023 at 07:44:08PM +, McAllister, Colin via Elfutils-devel wrote: > I did see that there were quite a few patches sent to the ML toward the end > of 2022 that attempted to add Windows support. > https://sourceware.org/pipermail/elfutils-devel/2022q4/005449.html > https://sourceware.org/pipermail/elfutils-devel/2022q4/005667.html > > It looks like some of the patches were merged, but quite a few were never > applied. I'm wondering if it'd be possible to finish adding support upstream > such that a fork would no longer be needed? > > I would be happy to help contribute however I can. Thanks. It would be nice if elfutils was a bit more portable. The trouble is that not many people have that much experience with Windows. At least I have none. When reviewing these patches I always get really confused. And I don't fully understand the use case. Given that Windows doesn't even use ELF why would you even want elfutils on such a platform? And why aren't people simply using cygwin for such a port. Without it you don't even have a normal POSIX like system. 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? But all that really is my confusion. It does make reviewing these change proposals really hard though. Because I often don't know whether some abstraction is really needed. And I do worry about unnecessary abstractions/ifdefs/code because it is unclear how to maintain them long term if I am not sure why. 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? 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 Thanks, Mark
Re: make check fails for version 0.189 on aarch64
Hi Jonatan, On Fri, Sep 15, 2023 at 08:42:28PM +0200, Jonatan Schlag via Elfutils-devel wrote: > I'm currently trying to build elfutils in version 0.189 on an aarch64 > system. Unfortunately, make check fails with the following errors: > > https://nopaste.ipfire.org/view/Sx7pjy4g > > The full log can be found here: > > https://pakfire.ipfire.org/jobs/28a23239-80a6-4a24-b506-dbc367d96afa/log > > The same configuration works on x86_64. I currently run out of ideas > what to try next. I know that the test suite passes on Debian for > aarch64. So there must be an error with the system itself, but as said, > I lack ideas how to debug this further. > > Some input would be highly appreciated. So you only got 4 FAILs. FAIL: run-backtrace-native.sh FAIL: run-backtrace-dwarf.sh FAIL: run-backtrace-native-core.sh FAIL: run-deleted.sh And they all seem to fail in the same way. You get a backtrace, but almost all symbol names come out empty/null. But your configure line does contain -g so you should at least get it for the elfutils libraries and (test) programs. The only possible issue with your configure line is the use of -fdebug-prefix-map which I believe doesn't work correctly when also using LTO. And maybe your /usr/lib64/libc.so.6 might not have any symbols? Cheers, Mark
