I don't know if this was in anybody's interest

Yes of course!!!

I'll run some testing on this and will merge this once I think this is OK.

OK, I tried to build glib on i686-pc-mingw32.shared, and it failed. The problem is that MinGW does not provide a prototype for rand_s() (see http://sourceforge.net/p/mingw/bugs/2122/). However mingw-w64 does.

This bug is fairly hard to fix, because all three options seem rather unrealistic:

1. Patch mingwrt using a variant of http://sourceforge.net/p/mingw/bugs/2122/attachment/rand_s-mingw.patch
   The patch only applies to mingwrt 4.*, applying it on 3.20 (which mxe uses) is possible but rather difficult because currently mxe simply gets the binary and installs it. Patching means getting the source and build it, and all sorts of chicken vs. egg problem appears.

2. Disable glib on i686-pc-mingw32.
   glib is crucial to many projects:

   timothy_gu@ubuntu-lenovo:~/mxe$ make show-downstream-deps-glib
   agg atk atkmm cegui chromaprint ffmpeg freetype fribidi ftgl gd gdk-pixbuf
   glibmm graphicsmagick gst-plugins-base gst-plugins-good gstreamer gtk2
   gtkglarea gtkglext gtkglextmm gtkimageview gtkmm2 gtksourceview
   gtksourceviewmm2 harfbuzz imagemagick lensfun libass libbluray libcaca
   libcroco libgda libgdamm libgee libglade libgsf liblqr-1 librsvg libxml++
   mdbtools ocaml-cairo ocaml-camlimages ocaml-lablgl ocaml-lablgtk2 opencv
   openscenegraph pango pangomm pcl plotmm poppler qscintilla2 qt5 qtactiveqt
   qtbase qtconnectivity qtdeclarative qtenginio qtgraphicaleffects
   qtimageformats qtlocation qtmultimedia qtquick1 qtquickcontrols qtscript
   qtsensors qtserialport qtservice qtsvg qtsystems qttools qttranslations
   qtwebkit qtwebsockets qtwinextras qtxmlpatterns qwt sdl2_ttf sdl_pango sdl_ttf
   sfml t4k_common vtk wt xine-lib
   

   Without glib the purpose of mxe is basically diminished.

3. Remove i686-pc-mingw32.
   There are still packages that can only be built with MinGW, and removing this target isn't very nice.

So, I propose that we either figure out a way to make MinGW use the old version while mingw-w64 the new one, or to delay this update. @tonytheodore?

Some more greps:

timothy_gu@ubuntu-lenovo:~/mxe$ grep -r rand_s usr/i686-pc-mingw32.shared/include/*
timothy_gu@ubuntu-lenovo:~/mxe$ grep -r rand_s usr/i686-w64-mingw32.shared/include/*
usr/i686-w64-mingw32.shared/include/stdlib.h:  _CRTIMP errno_t __cdecl rand_s(unsigned int *randomValue);

It seems it's also a problem in 2.40.0..
There is only one instance of rand_s in the glib source code, could it be replaced with a different method?

Yes, and in 2.39.1. See GNOME/glib@0e1924a. Another solution is to revert the said commit, but that would make it unsupported and untested by upstream.

There is only one instance of rand_s in the glib source code, could it be replaced with a different method?

We can probably use the unsecured rand().

So, I propose that we either figure out a way to make MinGW use the old version

I suppose it's the same general question for recent versions of qt5 and supplementing directx headers - how much do we continue supporting MinGW when mingw-w64 is more current and MinGW v4 seems to be on hold?

It would be interesting to know if people are using i686-pc-mingw32 because it's the default or if there's a preference for it.

Replying to @tonytheodore:

It would be interesting to know if people are using i686-pc-mingw32 because it's the default or if there's a preference for it.

Yes. Most projects I knew switched to mingw-w64, simply because MinGW is dead.

Any more opinions on this? If not, I say we should delay this pull request until after the release which can happen in anywhere between 1 and 4 months depending on the availability of @tonytheodore.

Now in #492 we have decided not to support MinGW anymore. I will merge this in about a week after some more testing.

Merged, thanks! I also have updated the two packages to 2.42.0.