Fix GHDL 4.1.0 Install

[TheMDev]

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online ghdl is error-free.
• brew style --fix ghdl reports no offenses.

---

Hi, After #168502 was merged trying to use GHDL results in the following error:

ghdl:warning: ieee library directory '/usr/local/lib/ghdl/ieee/v08/' not found
ghdl:error: cannot find "std" library

The new version expects the following binary and directories to be linked, whereas the previous version does not. Reverting to 79b16a2 confirms that GHDL 3.0.0 works fine without the binary and directories being linked.

/usr/local/Caskroom/ghdl/4.0.0/bin/ghwdump
/usr/local/Caskroom/ghdl/4.0.0/include/ghdl
/usr/local/Caskroom/ghdl/4.0.0/lib/ghdl

I added a link and unlink step in the postflight, which seems to have resolved the issue.

I am not entirely sure why ghdl is a cask, as it seems it could easily be a formula, If that is the preferred fix, I can create a formula as well.

[dltmtt]

Apparently there's already been some discussion on whether GHDL should be a cask or a formula in #46031 and in #79102 if you wanna look into that. As a user I'd expect ghdl to be a formula too, but I haven't looked into the requirements that formulae need to satisfy

[krehel]

Thanks @TheMDev for the fixes.

Agreed with @MDXZ-delti - was also just posting those links. Historically this seems to have been an issue, though you are welcome to try. I don't know if it's worth the hassle, though.

[TheMDev]

I see... #46031 sheds some light on the requirements for ADA and GCC and why this isn't a formula already. I may look into getting that working, but it seems like quite the undertaking. In the meantime, if we could get this merged and revisit this if I make any progress, that would be great.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[TheMDev]

I have been working on getting gnat to compile on MacOS 14; however, due to some changes to the compiler and linker in macOS, building gcc gnat is currently not possible. I have been creating a patch to merge upstream in gcc; however, this appears to be quite a challenge. If whoever is maintaining brews gcc or someone knowledgeable in gcc is willing to reach out to get this moving faster, I would be more than happy to work with them to fix this. In the meantime, it would be great to merge this, as a formula is currently unlikely.

For reference, the current issue with building gcc gnat is the libtool.m4 that generates the configure files for gcc incorrectly passes the -single_module flag to the linker, which has been obsolete for over a decade but recently started throwing a warning in MacOS 14 x86 but not aarch64. This results in lt_cv_apple_cc_single_mod being set to no instead of yes. This results in libstdc++.6.dylib-master.o being generated with debugging symbols during the bootstrap process, which results in a bootstrap comparison failure while comparing stages 2 and 3.

[p-linnane]

Any other thoughts here @Homebrew/cask?

[miccal]

Thank you @TheMDev.