Fortran is lost?

[angelog0]

Description / Steps to reproduce the issue

The last update has removed the Fortran language in MSYS2. I use it both on MSYS2 and MINGW64. Without Fortran in MSYS2 there are no reasons to continue use MSYS2 it self.

Verification

• [X] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MSYS_NT-10.0-19045

[MehdiChinoune]

I think It'already documented that MSYS environment is to provide tools required to build MinGW-w64 packages. gcc-fortran is not needed for any MinGW-w64 package.

[angelog0]

Then you have to remove almost half packages (emacs, mutt, asciidoc, ...), if not more. But, at this point, why an user should use MSYS2/MinGW and not the old Msys/MinGW which still support Fortran? Just because it is (not verifyed, sorry) 32 bit?

[MehdiChinoune]

Feel free to use outdated packages. MSYS2 has some differences with MSYS see https://www.msys2.org/wiki/History

[lazka]

@angelog0 just wondering, what were you using msys fortran for?

[sskras]

(To second the @lazka's question)

@angelog0: hey, you still have mingw64/mingw-w64-x86_64-gcc-fortran ! Does it have issues in MSYS2 environment?

[angelog0]

I have always found useful to work with both, MSYS2 and MINGW64, to compare results, find bugs, test command line options etc.

You cannot justify its removal saying that MSYS2 is only to have a POSIX environment to build MINGW apps: there are many MSYS2 apps which are unrelated with this. Why removing Fortran? Usually when one builds GCC the build is done for the three basic languages. If I remember correctly by default the build of GCC produces C. C++ and Fortran. Anyway it is some time I do not build GCC and maybe things changed..

[sskras]

@angelog0, while I understand your frustration, the project developers are seemingly free to do whatever they want or have decided.

I think folks like you and me have two practical choices:

1. To create and maintain their own repo containing MSYS2-based builds of arbitrary software (e. Alpine email program in my case).

2. To switch to different runtime that also provides *nix-like environment for Windows, but makes no artificial restrictions on a set of POSIX-based software to be built here.

   I know of other two such runtimes:

   2a. Cygwin 2b. Midipix

I am sure you have heard about Cygwin already. Now I would like to highlight the Midipix project:

Midipix[1] is a POSIX/Linux-compatible environment for Windows XP/Server 2003 or later, facilitating cross-compilation and execution of applications written for POSIX/Linux without suffering substantial performance loss.

Unlike Cygwin[2], Midipix does not require interaction with the Windows environment subsystem in order to implement its system calls.

Unlike Interix[3], Midipix is not an environment subsystem itself and does not introduce its own subsystem server and client DLL(s).

Neither virtualisation nor kernel-mode drivers are required in order to use Midipix: instead, a small set of “runtime components” mediate communication between Musl, the libc chosen for this project, and the Windows NT executive (NTOSKRNL.EXE.)

Current state of Midipix is that it:

• is still pre-alpha, albeit the software that builds usually runs just perfectly;
• can be be built only from Linux at the moment;
• has no installer – it produces a .zip file that needs to be extracted into the new dir;
• uses quite old port of MinTTY (v2.8.1) which feels a lot faster than MSYS2-based one;
• bundles quite old GCC version 4.6.4;
• misses a bunch of syscalls yet;
• misses a lot of things in /proc;
• is driven by like 2 developers at the moment;
• was promised to have its' first release this year (although I estimate that to happen in 2024);
• has main communication happening on IRC channel #midipix on Libera.Chat.

I am currently testing the 2022.11.18.20.22.52 build and it feels quite impressive to me:

Subjectively it's like 3-6 times faster than Cygwin.

[angelog0]

I am sure you have heard about Cygwin already.

I used Cygwin for almost ten years and switched to MSYS2 because [...]

I have also heard about Midipix...

[angelog0]

You do not respond why you have removed one of the three main pillars of GCC and not other apps that have nothing to do with the build of MINGW applications.

You cannot dismiss this discussion by saying that developers are free to remove software that they no longer deem necessary: it is an insult to those who have followed this project for nearly a decade!

[angelog0]

I close this. Do what you think

[MehdiChinoune]

You do not respond why you have removed one of the three main pillars of GCC and not other apps that have nothing to do with the build of MINGW applications.

We are discussing this topic on discord. What criteria for MSYS2 packages, but what is sure is that gcc-fortran is not one them as It's already available as MinGW package.

[Kreijstal]

I think I got hit by this, as in, there is a python package that requires numpy + POSIX, you need fortran to get numpy, so this makes it impossible to build this package on msys enviroment, I guess cygwin would be the option, but :(

[Biswa96]

there is a python package that requires numpy + POSIX, you need fortran to get numpy

Could you provide the link?