MinGW - Minimalist GNU for Windows

Fork

• mingw-dist
• build-aux
• wtklite
• pexports
• website
• mingw-get
• mingw-org-wsl
• mingw-pkgspecs

Donation

Help will always be appreciated, but do please note:­–

1. mingw-w64, tdm-mingw, and msys2 are all independent forks — we do not support them, (and indeed, the first two use our registered trademark without permission, and thus illegally).
2. While you do appear to have a fair bit of experience, and would likely be an asset to the project, we would really like you to indicate what aspects of MinGW you would be most interested in working on — your "book" really is a bit too vague.

If I had gone into detail it would have truly been a book and yes, I'm aware they are independent forks, I looked at them as part of my process getting things working. TDM has been untouched for years, but still has some relevance. It includes the python dll, and a newer version of GCC than mingw32. msys2 I think pacman draws a specific Linux crowd, but why not just use Linux if you don't care about a little bit of a GUI edge. I came to you because mingw32 is the original and has a Windows GUI included. I'm just guessing as I don't even know if the code is out there for the GUI, but I'd imagine it's using wxWidgets which I also have compiled on my machine. My first setup was somewhat broken because I didn't include pkg-config (which I believe should be build in.) Instructions relating to using ./configure --prefix=/mingw32 when using configure are also obscured. So my current setup... first I setup pkg_config, then each package was compiled using the above. I can code in C and a bunch of other languages including .NET/Mono, what I don't know I can learn. I've scripted in Korn, Bourne and C Shells in the past. I have an unlimited supply of VirtualBox PC's to install and re-install on. Like I think I mentioned, on my network, I have Windows 2000, XP, 7 as well as Debian, Anti-X and Ubuntu Linux. (yes, all Debian flavors) If I were to pick a starting place for updating the project, I would start with the broken links, then the documentation, and yes, advertising that this version works on XP can't be a bad thing. Make pkg_config a part of the base install and go from there. There is a huge difference between Windows developers and Linux developers. Windows developers expect to install the tools and be up and running where Linux developers are used to 'building' the development environment. Where I fit... I left it vague so that I could fall in place where needed. Let me know what your priorities are and I'm sure I can fit somewhere in there.

Reply To ayperor

TDM has been untouched for years, but still has some relevance. It includes the python dll, and a newer version of GCC than mingw32.

Newer than GCC-8.2.0? Really? It looks, to me, like it hasn't been touched since 2015, and it offers no better than GCC-5.1.0. We've offered GCC-6.3.0, GCC-7.3.0, and most recently GCC-8.2.0, since then.

Granted, we don't publish a python DLL, (or anything python related), but that's because the python folks, themselves, despite their own free software roots, eschew free software tools, and insist on using Microsoft's non-free MSVC to build their windows ports, and none of us care to devote time to creating a competing MinGW build. FWIW, I haven't used windows myself, for around five years now; when I did, I used the windows port of mercurial, from the mercurial project itself, and that also shipped with a python DLL. I never had any problem with mixing MinGW tools with such upstream products, even though they themselves weren't built with MinGW.

Reply To ayperor

msys2 I think pacman draws a specific Linux crowd, but why not just use Linux if you don't care about a little bit of a GUI edge.

IMO, msys2 goes way beyond the original "minimalist" goals of our original MSYS — so much so that it has effectively become cygwin by another name! I never much liked cygwin either, and yes, I entirely agree on the "why not just use Linux?" question, which is why I use self-built cross-compiler tools, on LMDE, to build all of my own MinGW contributions.

I came to you because mingw32 is the original and has a Windows GUI included.

I assume that you mean the GUI incarnation of mingw-get?

I'm just guessing as I don't even know if the code is out there for the GUI, ...

It's in our git repository.

but I'd imagine it's using wxWidgets ...

Nope. We looked at wx-widgets; it's good, but it's way too heavy for what we wanted mingw-get to be.

Ok, perhaps the version information was about the early stages of getting it working and I stopped at gcc.exe (MinGW.org GCC-6.3.0-1) 6.3.0 because I've also set it up on XP. I sent this in the beginning of January, and did all of this a couple weeks before so things aren't as fresh as they were but that wasn't really the main objective of my note. I had a bunch of other points in there as well but the real point was really the question of "where can I help out?"

Reply To ayperor

If I were to pick a starting place for updating the project, I would start with the broken links, ...

On www.mingw.org? Yes, any that we find do need to be corrected — I've been correcting any that have been brought to my attention, but I don't have the time to review every wiki page.

then the documentation, ...

Yep. A wiki seems like a great idea — let the community provide, and maintain the documentation. All well and good, until the original page authors abandon their work.

and yes, advertising that this version works on XP can't be a bad thing.

Agreed. Even better ... it should still work on Win9X, (although I no longer have access to any platform on which to verify this).

Make pkg_config a part of the base install and go from there.

Where does the pkg-config dependency arise?

Where I fit... I left it vague so that I could fall in place where needed. Let me know what your priorities are and I'm sure I can fit somewhere in there.

Well, you've already alluded to web-site maintenance (I think). Priorities there are:–

1. Migrate existing content from Drupal to WordPress ... we already have a sandbox set up, with a few pages converted, but still many more to go.
2. Set up Let's Encrypt certification, and serve content via https, rather than http.

On the programming front, there are a number of packages, still languishing on SourceForge, which need to be migrated to OSDN; in the process, some of those could probably benefit from updates.

There is a small problem in here... Keeping in mind your first reply. Instead of going to the site and looking for the git, I did a quick google search and I'm not sure you got a chance to look at https://en.wikipedia.org/wiki/MinGW

From Wikipedia, the free encyclopedia

but it starts out with... MinGW (Minimalist GNU for Windows), formerly mingw32, is a free and open source software development

Agreed. Even better ... it should still work on Win9X, (although I no longer have access to any platform on which to verify this).

PKGS=sdl SDL_gfx SDL_image /List of packages LVER=lua-5.3.4 CFLAGS=-O2 -Wall -W -I$(LVER)/src pkg-config --cflags $(PKGS) LDLIBS=$(LVER)/src/liblua.a -lm pkg-config --libs $(PKGS) SDLV=1.2.15

so here is just one of the PKGS listed above manually run... $ pkg-config --cflags SDL_image -D_GNU_SOURCE=1 -Dmain=SDL_main -IC:/MinGW/include/SDL

Reply To ayperor

If I were to pick a starting place for updating the project, I would start with the broken links, ...

The broken links in the config file the mingw-get uses... There are a bunch of key packages that won't download because of broken links.

I don't understand. There shouldn't be any broken links there. We haven't removed anything from SourceForge, so unless they've reneged on their promise to maintain the dl/sf.net redirection capability, (which I certainly wouldn't put past them), all references to older (unmigrated) packages should remain valid.

Mainly version updates that were not reflected in the file.

Are you referring to updates for packages which have been migrated to OSDN? If so, then yes, these will not be reflected in the (abandoned) catalogue on SF. You must point your catalogue source to OSDN, (as it will be, if you install mingw-get using the version of the mingw-get-setup.exe tool from OSDN), to keep up to date, (and thereafter, the links to replaced SF packages cannot persist).

I can run thorough a couple of clean installs and find out which links are broken.

Please do.

Reply To ayperor

There is a small problem in here... Keeping in mind your first reply. Instead of going to the site and looking for the git, I did a quick google search and I'm not sure you got a chance to look at https://en.wikipedia.org/wiki/MinGW

Well, all that disinformation is beyond our control ... we don't have the resources to police all the rubbish, (and lies), which may get posted on Wikipedia, or similar sites.

I initially downloaded mingw-get-setup.exe from the OSDN website and ran it. it seems to use some files from osdn, then others come from sf. I recall that some of the packages were upgraded from what the setup was looking for. In other words, there was a revision number in the file on sf for example, the setup is looking for blablabla-1-blablabla but when I follow it to the url it's trying to get it from, I found that blablabla-2-blablabla is out there, and blablabla-1-blablabla doesn't exist so it fails to download it. I'm going to jump into it tomorrow, I have a virtual all setup which has none of this installed. I'll just download the setup, and begin the install, document my choices, then what's missing and what it should be. What I did initially to work around the problem was to rename blablabla-2-blablabla to blablabla-1-blablabla and drop it in the cache folder, re-run the install and it picked up on the cached version and all was good. The install works until it gets into the mingw-get portion of the setup. This is where we find broken links.