Closed angelog0 closed 1 year ago
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.
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?
Feel free to use outdated packages. MSYS2 has some differences with MSYS see https://www.msys2.org/wiki/History
@angelog0 just wondering, what were you using msys fortran for?
(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?
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..
@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:
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:
.zip
file that needs to be extracted into the new dir;/proc
;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.
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...
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!
I close this. Do what you think
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.
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 :(
there is a python package that requires numpy + POSIX, you need fortran to get numpy
Could you provide the link?
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
Windows Version
MSYS_NT-10.0-19045