How to enable GCC i686-w64-mingw32 multilib

I always opt i686-w64-mingw32 multilib when building GCC. That mean 32bit by default and 64bit via -m64. in GCC 4.9 (or since GCC 4.8 SEH introduction) this configuration seems to be broken / unsupported. By common sense if x86_64 multilib is supported then the inverse should be possible too.

Here is the patch:

--- D:/Tarball/gcc49s/libgcc/config.host.bak Thu Mar 27 22:40:31 2014
+++ D:/Tarball/gcc49s/libgcc/config.host Sun Sep 28 14:24:20 2014
@@ -646,8 +646,20 @@
  if test x$enable_sjlj_exceptions = xyes; then
   tmake_eh_file="i386/t-sjlj-eh"
  else
-  tmake_eh_file="i386/t-dw2-eh"
-  md_unwind_header=i386/w32-unwind.h
+  case ${host} in
+    i[34567]86-w64-mingw*)
+      if [ "${enable_multilib}" = yes ]; then
+        tmake_eh_file="i386/t-seh-eh"
+      else
+        tmake_eh_file="i386/t-dw2-eh"
+        md_unwind_header=i386/w32-unwind.h
+      fi
+      ;;
+    i[34567]86-pc-mingw*)
+      tmake_eh_file="i386/t-dw2-eh"
+      md_unwind_header=i386/w32-unwind.h
+      ;;
+  esac
  fi
  # Shared libgcc DLL install dir depends on cross/native build.
  if test x${build} = x${host} ; then

Might be a bit ugly but still make sense and works! Overall that's just a naming/convention mess. With the patch we should have SJLJ in 32bit and SEH exception in 64bit mode by default (a.k.a no exception handling specified at configure).

How to build PyGI AIO with Moluccas

Read about Moluccas first, its gcc has experimental CRT targeting for this guide.

MS CRT targeting initially laid by official mingw.org but still far incomplete. At first I thought it would be as easy as set cflag/cxxflag __MSVCRT_VERSION__=0x0900 and add -lmsvcr90 to GCC's specs file, well for a trivial program? yes it can but thats all it can get. As my experiment goes by there are many issues piling up (from incomplete msvcr implib to puzzled LFS/Y3K macros) that forcing me to modify mingw's crt and win32api files to allow a package completely linked to the new msvcrt dll. In the end I decided to add new GCC flags to simplify this: -vcr70 to -vcr110. The flags correspond msvcrt redist version bundled by each release of Visual C++. Even today it still far from complete.

What it has to do with this guide? there is an article wrote by win32 contributors of Gnome framework (or whatever you called it) that explain the concern. While my approach is far cry in comparison to use real thing (yeah I know MSVC has free express edition) it still useful in some cases at least for OSS zealot (even if they use Windoze).

This guide will focus on latest stable version of GTK-related (should be called GObject-related) libraries as this written. The main packages are Glib 2.38.1 + GTK 3.10.2 + GI 1.38.0 + PyGObject 3.10.1 and we are targeting python 3.3 (which use msvcr100.dll). I must tell you though, there is steady progress to support MSVC from upstream at least for major libraries including GI thingy.

If you don't need CRT targeting, you can use any GCC of your preference in moluccas by put it into moluccas root then switch over using setgcc [gcc folder name].

Download moluccas 0.8a, you need to download the following packages:

M08.exe
M08-basemsys.7z
M08-basetools.7z
M08-ccomp.7z and newer gcc
M08-tex.7z

1. Saves all of them in the same folder,
2. Run M08.exe and specify install path (it's a portable installation). Click OK. Correction: If you have conemu instance(s) already run you need to quit all before clicking OK, see Maximus comment.
3. The installer dialog will vanish quickly to bootstrap conemu and continue with extraction. Due to the sheer number of files, the extraction (write to harddisk) will be way slower than what the CPU capable of.
4. Once completed, run conemu.exe to start
5. Moluccas will try to detect any presence of Visual C++ and try to integrate the latest version you have. During first run it also initialize Miktex installation
6. In the end conemu panel will bring the <^> prompt
7. Type spawn to start an instance of conemu. The panel will hide and still accessible via systray icon.

edit:

I will put latest patches and buildscript at https://github.com/tumagonx/pygi-mingw-patches

The Moluccas 0.8

Version 0.8 is here. I now called it Moluccas (not to be confused as some kind of mollusca).  It can be grabbed at https://sourceforge.net/projects/tumagcc/files/0.8/

The installer is M08.exe and you can pick up which 7z packages to install (categorized) but at least "base" is mandatory. Put all in the same folder and you're ready to install. There is brief overview of what's inside in each package at the link above. It still lack of documentation though only man included.

Enjoy my biggest OSS Collection with build environment!
All suggestions are welcome.

Main changelog:

- Fixes many typos and silly mistakes when tested in Windows 7
- All executable flagged with LAA
- Simplified startup: run conemu to start (old mode console, no longer supported though possible)
- Isolation: this version use ReactOS's cmd completely so it can be run independently of Windows' cmd.
- Installation speedup: Installer will use all cores (1 core/package)
- Explorer integration is disabled to provide zero host modification during startup (can be enabled by invoke molumenu). But many gui apps still write registry entries especially MFC based one.
- Fix integration with MSVS 2010 or (later?)
- Lots of manual tweaking in GUI apps to make it tight and blend in
- Small fixes in mingw headers and xtraposix libraries

Preparing version 0.8

I knew it will be more belated than previous version, this is getting bigger... Tuma MinGW 0.8 will focus on integration fixes and aim to become more established collection. On gcc side there is very little changes and will be the last with 4.7.x series (barebone 4.8.1 is provided though), originally I want to bundle static gtk libraries, but decided that's not worthy enough (I will put it up separately).

This version will have serious GUI apps addition and I have evaluate dozens of FOSS each weekend to find apps that lean and fast (avoiding .net/java whenever possible). But they're just alternative workflow from commandline counterpart which has considerable advatage. I still not quite done with cleanup so I dumped those in extratool package.

Oh yeah I want to drop the name, I think it's not a problem since it's not popular at all anyway. Candidates: celebes, moluccas or rangrang (the last is meaningful cause I love ants, they are the oldest architect)

I hope could finish it on sunday tomorrow.

Node.js with posix path support

It was Mat Sutcliffe who sent me a patch to compile node.js with mingw last weekend, if I recalled node.js used to be compilable with mingw via scons but apparently they switch to gyp entirely and mingw support became broken since then. I though it was a bit weird to sent it to me, but it turn out the process would involve msys python (needed by gyp to work properly).

The patch itself is a win-win solution as it will build native win32 binary but with support for posix path (MSYS and CYGWIN) via generic mount mechanism. He further explain why he choose mount over cygpath, that is because node.js operate asynchronously so by using mount path would settled once rather repeatedly as with cygpath.

This is binary of node.js 0.10.12 (built as ./configure --gdb --without-etw --without-perfctr)
nodejs-0.10.12.7z
original patch for mingw by Mat -> replace msysmnt with mount
modified patch for mingw-w64
python msys

The functionality is implemented in path.js which is bundled inside the executable. So actually you could modify (if you wish) that part (look for mingwToWindowsPath resolvedPath) with your favorite hex editor if you don't want to recompile. Just make sure you don't add and reduce the string block length. Or if you think mingw is such mundane task feel free to apply patch only to path.js and then compile it with M$VS as usual :-)

How to build with mingw:
1. extract the source file for node.js homepage
2. download python for msys and extract to msys installation
3. download one of appropriate patches (above) put in source tree
3. start mingw, navigate to source tree and apply patch
4. ./configure [your options] (make sure that python for msys is the active one)
5. python tools/gyp_node -f make
6. LINK=g++ make -C out BUILDTYPE=Release V=1

Notes:
- I'm not sure about etw and perfctr whether those compilable with mingw but both don't compile out of box. 
- The download is contain official installation hierarchy with node.exe replaced. Since it's not installer (it make no sense anyway) I'll assume you know what to do next ;-)

Enjoy!

SHC 3.8.9 MSYS port

To continue previous post, I actually port shc-3.8.9 quite long time ago for fun. But now I want to see if it can act as a wrapper for shellscript (bash/perl) under plain cmd box. And boom it failed :-))

SHC is actually an encryptor not compiler, with time trial feature (not tested). I don't quite remember anymore how I patched this little tool. But as usual MSYS is lacking this and that so it need bandage or cutoff :)

SHC however does need compiler (msysdev-gcc) to build its decryptor along the launcher itself. I have tested it under bash and it works fine. Under cmd box things are bit vague, it seems like:

decryptor -> look for shell (based on shebang?) -> found, sh launched -> ...WTF?... -> launch new cmd.exe session (again) instead

Hmmm

anyway it works for MSYS :-p

Download: http://osspack32.googlecode.com/files/shc-3.8.9.7z

Note make sure msysdev-gcc is ready and always use the -T option of shc

Overhead! overhead

The next tuma mingw should be a big one, really... a bloated one! thanks to the fairly long period after 0.6x the last release, it's now really turned to a distro of console based apps inside ConEmu box. I got miktex and whatever tex (asymptote, dblatex, jade, etc) integrated, along with dozens of additional tools. But I have big problem: clean-up

The cleanup turn out really overkill, I have done it almost every weekend since the end of december and still not finished yet. The total size expectedly grow almost exponentially. The number of apps? sheesh I've lost count of it, one thing for sure all of them are OSS and not even freeware can be included (maybe one grey area exception).

My msys folder has been accumulated to the level that executable lookup (those in PATH environment) is slowed down to a noticeable 1 second. But then wasn't it is the same condition for a fully installed cygwin too? dunno but it's really annoying.

I think it needs renaming too, something like Crossblaw: Console oRiented OSS between Linux and Windows. Afterall it's not about my gcc build anymore... Now now the name get bloated too lol

I hope it could benefit many Windows users (especially newbie) who want to taste the best that generic Linux has offered, powerful loads of console apps. Because I know that the GUI part of Linux is still no match for the undead XP. Vice versa of course.

Final problem: How I supposed to upload this monster (if it ever done)? too bad I'm living in a country with medieval internet infrastructure.

Gotta sleep now

Irssi for MSYS

Previously I tried to port finch which failed and have been looking at centerim too which nowhere easier. Now I'm back to focus on just the IRC part and let pidgin do YM task, the choice is clear: Irssi it also the most promising one to port than the two before. Irssi however is dull without perl just like all irc client supposed to be but adding perl would be too big, too many files.

I decide go with Msys setup which should be straightforward and it is, except how the plugins works. There is no libirrsi.dll or such thing so how it could load dll? note that the plugins isn't loadable module, it does depends/linked to Irssi (which has to be irssi.exe itself in windows unless it linked to irssi wholly). I learned about C Perl embedding too from this which involved joining dynaloader.o file in final linking.

irssi + twirssi in action

As you can see with perl, Irssi could be used as twitter client too although the popular way is using bitlbee gateway, unfortunately bitlbee is not work well with windows and the port is unmaintained. Msys version of Irssi has its quirks too, the obvious one is due to msys' limitation jabber plugin unlikely work but most important ones such as OTR and SILC may work. Because of limited nix functionality I'm stuck with DateTime::TimeZone perl module, which assume Msys as unix rather than Win32 for this particular issue, where perl should look up windows' registry to find local timezone thus modifying local.pm needed by aliasing 'msys' as 'Win32'. Also msys file permission is not entirely nix style which lead unexpected behavior.

BTW installing twirssi on vanilla msys-perl can be troublesome, there are dozens of modules from CPAN will be installed/updated which in the end still not completely satisfy its dependencies. Careful

irssi-0.8.15_msys.7z

It's Just Wrong: MSYS Python

I thought it would be helpful to have python which understand both posix path and windows path: MSYS version of python that is. In my old review about MinGW python, this kind of build already hampered with incompatibilities especially due to python heavily rely on inconsistent "defines" across modules sometime use uname() then sys.platform then posix or not (os.name).. meh.. this make workaround also inconsistent.

What did I tried is even worse:
- with uname = msys it's unknown system to python fine lets change it to cygwin, well this will create another problem since msys is not cygwin (different runtime unlike MinGW vs MSVC) its c modules should have different suffix to avoid python try to load native win32 module by accident (I set it to .myd meh...). Note: "msys" or "cygwin" or "mingw" is a hardcoded value that returned by sys.platform it can be only changed via hex editing once python.exe compiled
- distutils which used when building extension then would call uname (unlike mingw or msvc) to decide platform / compiler flags etc and what you get is insane name: MINGW32_NT-5.1-1.0.17(0.48/3/2) <- yes there even slashes there :-)
- unlike mingw build which can be changed to win32 (hardcodedly) to provide more compatibility thats not the case for msys which the only possible option is cygwin with above quirks.
- many c-extension tests failed! not really a problem if we just want barebone or purelibs though

In the end I decide to edit ntpath.py and site.py of native msvc python to make it use "/" under msys, this again have its own quirks too: win32 python need to use ";" as path separator which ":" already used as driveletter and because it doesn't know root "/". Meh...

Anyway here is the msys binaries of python 2.6.7: python-2.6.7_msys.7z (sources and patches from cygwin repo)

How to perfectly mix 32bit and 64bit libraries in MinGW

Assuming you have multilib (dual 32bit/64bit) GCC and you have common libraries in /usr/local you could put all 32bit and 64bit in /usr/local/lib folder altogether.

How? I found out that GCC filename lookup for libraries (be it import lib or static lib) have the following order:
In case of -l[foo] getting parsed:
1. lib[foo].dll.a
2. [foo].dll.a
3. lib[foo].a
4. [foo].lib

The common convention is (1) as import library and (3) as static library however this may varied among makefiles. If you're willing to do a little renaming work or better more edit the libtool or makefiles. You could arrange them this way:

32bit import lib: lib[foo].dll.a
32bit static lib: lib[foo].a
64bit import lib: [foo].dll.a
64bit static lib: [foo].lib

This way, during compile gcc will look for all possibilities till found the matched bitness with import lib having higher priority than static lib. Huh lucky number 4 eh?

Hence the same -L/usr/local/lib and -lfoo for both 32 and 64bit hence single .pc (pkg-config) file too. Nice!

I use this convention in my MinGW toolchain

MSYS/MinGW Porting Kit

What I use to build most binaries here? MSYS+MinGW, yet I rarely post something specific about it...

Tonight I cleaned up my toolchains and dump everything into one kind of integrated package, a porting kit I would say. Formerly it just a small set of MSYS and TDM's GCC, slowly it grew up by adding some tools for packaging/deployment. Recently I even build my own GCC (i686-w64-mingw32 multilib) based on 4.6.2 version due to TDM's GCC multilib have default 64bit target which not so parallel with the spirit of 32-bitness of this blog fu fu fu... so I compile GCC multilib that do the opposite (32-bit by default and optionally targeting 64-bit). Furthermore as with  MinGW-W64 get matured but not fully compatible with MinGW32 I made alternate GCC mimicking official MinGW32 which migrated to dwarf2 based exceptions and switch between them as needed.