ghdl: add 'ghdl-llvm' (for mingw32) and/or 'ghdl-gcc' (for mingw32|mingw64)

[eine]

GHDL was added in #6688 🎉 🎉 🎉

However, the current package is an split package that builds GHDL with mcode for MINGW32 and with LLVM for MINGW64. This PR is for tracking other builds: LLVM on MINGW32 and GCC on either MINGW32 or MING64.

---

GHDL supports three different backends: mcode (built-in, for x86 32/64 bit only), LLVM and GCC.

	mingw32	mingw64
mcode	ok	build successful Segmentation fault at runtime (mcode is not supported on win64 yet)
LLVM	build error see below	ok
GCC	not contributed yet	not contributed yet

Hence, I have tested these locally with:

cd mingw-w64-ghdl-mcode
MINGW_INSTALLS=mingw32 makepkg-mingw -sCLfc
pacman -U mingw-w64-i686-ghdl-mcode-v0.36-1-any.pkg.tar.xz

cd mingw-w64-ghdl-llvm
MINGW_INSTALLS=mingw64 makepkg-mingw -sCLfc
pacman -U mingw-w64-x86_64-ghdl-llvm-v0.36-1-any.pkg.tar.xz

LLVM for mingw32 produces the following error during build:

gcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourceforge.net/projects/msys2> for instructions.
gnatmake: "run-bind.adb" compilation error
make: *** [../ghdl/src/grt/Makefile.inc:126: grt/run-bind.o] Error 4
make: *** Waiting for unfinished jobs....

[eine]

@mati865, @lazka, may I have some help here? This PR contributes two packages, one for mingw32 only and another one for mingw64 only. However, it seems that CI services are trying to build both of them on both platforms, and it is complaining about one in each of them.

[mati865]

It's the question for @Alexpux but IIRC packages that build only for one arch weren't easily accepted in the past.

[eine]

Oh, that's unfortunate. GHDL is one of a kind (the only open source simulator and synthesizer for VHDL 2008) and it is the de facto standard simulator for CI. The mcode backend is a handcrafted one that is very efficient, but it is not supported on Windows 64 bit yet. Regarding the llvm backend, it should work on mingw32 too, but there was the compilation error mentioned above.

FTR, we currently provide MSYS packages based on similar PKGBUILD files to those in this PR. See https://github.com/ghdl/ghdl/releases/tag/nightly. However, it'd be handy to have them upstreamed, since the combination of GHDL + GtkWave (already provided by MSYS2) is the most lightweight development environment for VHDL and it is FOSS.

[mati865]

GCC was upgraded since then, maybe it no longer crashes?

[eine]

GCC was upgraded since then, maybe it no longer crashes?

I will try immediately. However, even if LLVM works on both archs (which I hope it does sooner or later) I would still like to know if an exception could be made for backend mcode. It is a great piece of code with awesome performance. For reference, running the same test suite takes 14min37s with mcode (https://github.com/ghdl/ghdl/runs/747461038?check_suite_focus=true) and 40min3s with llvm (https://github.com/ghdl/ghdl/runs/747461043?check_suite_focus=true).

[eine]

@mati865, it is still failing with the same error: https://dev.azure.com/msys2/mingw/_build/results?buildId=5480&view=logs&j=faa49efd-b80d-59ec-f116-4ddab3c93356&t=e8ed0256-efd3-5cc6-f8ac-cad94af7904f&l=519. It seems to be related to *-gcc-ada, not to *-gcc.

[mati865]

You could try building with Clang by setting CC=clang and CXX=clang++ but I don't know how to help.

[eine]

I tried with clang and clang++. It is complaining about siginfo_t, sigsegv_act, SA_SIGINFO, etc. Those seem to exist in the repos of this org. Hence:

• I might be missing something obvious.
• GHDL might need to be built as an MSYS tool, instead of MING32/MINGW64. However, I hope this is not the case, because it can be built successfully on MINGW64 with LLVM backend, using GCC.
• I asked the maintainer of GHDL whether this might be some missing issue or bug in GHDL.

[mati865]

Seems like it doesn't support being built with Clang?
So fixing GCC bug would be necessary but I doubt anyone here can do it.

[eine]

Maybe #6586 is precisely about the GCC bug here?

[eine]

• GHDL might need to be built as an MSYS tool, instead of MING32/MINGW64. However, I hope this is not the case, because it can be built successfully on MINGW64 with LLVM backend, using GCC.
• I asked the maintainer of GHDL whether this might be some missing issue or bug in GHDL.

He replied:

GHDL needs to be built in MINGW32/64 (like it is for mcode). But the configure script needs to be adjusted. The build is x86_64-w64-windows-gnu which is not identified as a windows host.
Not sure this will fix the crash.

[stahta01]

Would a split package be okay if it used mcode for mingw32 and llvm for mingw64?

Tim S.

[eine]

@stahta01, my proposal is precisely to contribute two packages (mingw-w64-ghdl-mcode for MINGW32 only and mingw-w64-ghdl-llvm for MINGW64 only). Those are known to work, because they are tested in GHDL's CI workflows (e.g. https://github.com/ghdl/ghdl/actions/runs/164507689), and nightly builds are available through Action ghdl/setup-ghdl-ci.

However, the CI jobs here fail because they attempt to build both packages for both environments.

[stahta01]

See #6686 PR for split package please comment on it and take over package management.

Tim S.

[eine]

Oh, I know see what you meant. I understood just the opposite. Thanks!

Ideally, I don't like that approach. However, since having separate packages is not an option for now, I will take care of it. I saw that you are using a tagged release, and that's why the LLVM 10 patch is required. Since both GHDL and MSYS2 are rolling projects, I will use a commit hash instead. Thanks again!

[eine]

I opened #6688, based on this PR and on #6686. I will keep this PR open to track support of other possible builds which are currently failing.

[lazka]

Should this stay open? Just wondering..

[eine]

@lazka, I'd like to keep it as a draft, if you are ok with that. Currently, 2/6 builds (backends) are available in upstreamed packages. This is for tracking the other 4 variants (LLVM on MINGW32, mcode on MINGW64 and GCC on both of them).

This might seem stalled because the work in progress is available in ghdl/ghdl#1547. I keep the content of the first comment in this PR updated according to the findings there.

[lazka]

OK, no problem. 👍