Standalone installation targets in makefile for GHDL 'mcode' compiled with MinGW32/MinGW64/UCRT64

[Paebbels]

Is your feature request related to a problem? Please describe.

To ease using pyGHDL for developers, a MinGW64 or UCRT64 standalone GHDL mcode is preferred. So the embedded libghdl can be used with a natively installed CPython 64-bit (not the Python within MSYS2).

Currently, such a setup is achieved by:

1. configuring GHDL with a PREFIX outside of MSYS2 like C:\Tools\GHDL
2. building GHDL using make.
3. installing GHDL using make install.
4. manually copying some DLLs from MSYS2 installation directory to the GHDL installation directory.

An additional make target like install_standalone could trigger the install target and additionally do some copy/install operations so manual copying is replaced. This also ensures that MSYS2 updates are applied to the GHDL standalone installation as well (overwriting files with new variants).

Describe the solution you'd like

• Add a new make target.
• Restrict supported platforms to:
  • MinGW32 - mcode
  • MinGW64 - mcode
  • UCRT64 - mcode
• Copy these files:
  • for MinGW32:
  • /c/msys64/mingw32/bin/libgcc_s_dw2-1.dll → $PREFIX/lib/libgcc_s_dw2-1.dll
  • /c/msys64/mingw32/bin/libgnat-12.dll → $PREFIX/lib/libgnat-12.dll
  • /c/msys64/mingw32/bin/libwinpthread-1.dll → $PREFIX/lib/libwinpthread-1.dll
  • for MinGW64:
  • /c/msys64/mingw64/bin/libgcc_s_seh-1.dll → $PREFIX/lib/libgcc_s_seh-1.dll
  • /c/msys64/mingw64/bin/libgnat-12.dll → $PREFIX/lib/libgnat-12.dll
  • /c/msys64/mingw64/bin/libwinpthread-1.dll → $PREFIX/lib/libwinpthread-1.dll
  • for UCRT64:
  • /c/msys64/ucrt64/bin/libgcc_s_seh-1.dll → $PREFIX/lib/libgcc_s_seh-1.dll
  • /c/msys64/ucrt64/bin/libgnat-12.dll → $PREFIX/lib/libgnat-12.dll
  • /c/msys64/ucrt64/bin/libwinpthread-1.dll → $PREFIX/lib/libwinpthread-1.dll

Notes:

• /c/msys64 is the MSYS2 installation directory.
• Environment variable MINGW_PREFIX provides the matching mingw32, mingw64 and ucrt64 directory name with leading /. E.g. /mingw64.
• The first copy rule can be translated to: cp $MINGW_PREFIX/bin/libgcc_s_dw2-1.dll $PREFIX/lib/libgcc_s_dw2-1.dll
  assuming $PREFIX is the target for the GHDL installation.

Describe alternatives you've considered

Installing GHDL from nightly builds by downloading ZIP files and overwriting directory contents.

Additional context

The described manual installation method and running GHDL mcode (and llvm) standalone is used by me an my colleagues for several years now.

This helps solving first steps towards #2313.

Later llvm backends could be installed as standalone too. Let's get this proof-of-concept working. I have matching dependency lists for llvm too.

[tgingold]

I am not sure to see the relation with #2313, except we need to copy the dll.

Is there an easy way to know the dll dependencies ?

[Paebbels]

I haven't seen any dependency changes in GHDL since I use this method, except if you add new stuff like maybe synth or changes to GHW. So for now, all is very fixed or eitherway related to your rules in Makefile.in.

Biggest changes I see a few times per year are version numbers like GNAT version and LLVM version. configure already knows LLVM version, that can be handed over. GCC/GNAT version we need to compute - haven't seen it yet in configure.

On GitHub Actions, we have a Bash script (scripts/msys2-mcode/GetStandaloneDeps.sh to compute the dependencies for mcode from DLL files with ldd. This is how we create the standalone ZIP files.

Integrating this script into Makefile.in looks too complicate for me, here I would kindly ask to take over if you want to automate this part.

---

For LLVM it's more complicated. Here we need some *.a and *.o files, so ld is happy. Also here I haven't seen any changes in GHDL's dependencies, as you seam to use only standard and basic functions from C and/or Ada.

[Paebbels]

OTOH, isn't there just one LLVM version and one GNAT version available in MSYS2 at a time. So when GCC/GNAT changes from 11 to 12, all 11s DLLs are removed and replaced with 12s DLLs.

Maybe we can just use a * pattern, because it's only used in a MSYS2 environment :).

[tgingold]

Let's try to use the script.

How are MSYSTEM and MSYSTEM_PREFIX set ?

[Paebbels]

• MSYSTEM is either MINGW32, MINGW64 or UCRT64.
• MSYSTEM_PREFIX is either /mingw32, /mingw64 or /ucrt64

[Paebbels]

Here you find it in the CI logs: https://github.com/ghdl/ghdl/actions/runs/3913814251/jobs/6690297400#step:7:6

[Paebbels]

This also relates to https://github.com/ghdl/ghdl/issues/1560. In Dec. 2020 I already analyzed what files are needed. Since then, there are just a few changes.

[tgingold]

Do we want to provide a standalone LLVM ? I am not sure it really make sense, as you need a linker, the libraries... Let just provide mcode.

[Paebbels]

Currently, GHDL standalone variants are limited for simulation to MinGW32 - mcode. Thus we have a memory limit and execution speed limit.

When GHDL should be used together with Python (and not through our plans of a wheel), then there is a second installation of GHDL - mcode64 via MinGW64 or UCRT64 needed, so libghdl matches the CPython 64-bit installation.

OTOH, a full blown MSYS2 setup is needed:

GHDL	Installation Size	Usecases	Cons
MinGW32 - mcode - standalone	~50 MB	Simulation on Windows	Memory limit; duplicate to MinGW64 - mcode
MinGW64 - mcode - standalone	~50 MB	pyGHDL
MinGW64 - llvm - standalone	~200 MB	Simulation on Windows	Currently broken
MinGW64 - llvm - MSYS2	~8.000 MB	Simulation/Synthesis on Windows	All scripts need to be executed within MSYS2 Hard to run GHDL e.g. from PowerShell

For me as a developer, an MSYS2 exists anyway, but endusers might not want to have a 8..10 GB installation.

---

Yes providing the linker is the easiest part as this is 1..3 programs. The libs are more complicated. Actually the knowledge is hidden in make files with -l*** options, right?

[tgingold]

The real solution is to finish the port of mcode for win64. Shouldn't be a lot of work.

Let's focus on standalone mcode and python.