30 November 2011

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.

CompilerPack 0.5b 45.7MB
MSYS Environment 0.5c 56.8MB
Addons 0.5d 91.3MB

Changelog (29 Apr, 2012) :
-Now MSYS Environment and CompilerPack contain only packages strictly related to building/compiling, others goes to Addons. From here onward it will focus on runtime targeting till version 1.0 reached.

mingw-w64:
time64 enabled
try to keep up with official mingw32 by adding Objc++, D (currently only 32bit) and Ada
workaround when using g++ and target is msvcr80 or later by append -lmsvcrt (this may cause harm!)
correction on specs: replace libgphobos with libmgphobos internally (for D) when using -Os flag

mingw32s:
fortran and objc dropped
correction on LFS and enforce time64 and LFS more
correction on specs: no need for mingwexnew since all runtimes use time64
runtimes are now optimized for SSE2 processor hence target arch become i786
now "practically" targeting msvcrt 6.1 at minimal (bundled in windows 2000)
libstdc++ LFS enabled

mingw32:
fortran and objc dropped
correction on LFS, now always on (still use 32bit time by default)
correction on specs: add runtimes replacement when targeting newer msvcr
libstdc++ LFS enabled
added new runtimes for libstdc++ and gomp

experimental: DragonEgg and MELT plugins for GCC
gcc dll dependencies moved to libexec since that place is gcc first lookup
now clang lookup mingw-w64's mingw\include
added helpers for clang and mingw-w64's fronteneds that autoswitch special flags for 64bit target. this automatically enforced by: "export MULTILIB=64" so users don't need to specify those flags anymore manually or worse edit makefile.

restore some executables that clobbered when I run strip *.exe (oops) lesson learned: don't use strip for other than GCC binaries
libsvn (and its perl binding) that taken from msysgit is incompatible with msys' perl, rebuild using latest version, now svn is fully supported either from svn or git svn
turn back xz to msys binary
added two generic 7zsfx and 7zsfx's splitter
automake is still 1.11.1, downgrade to 1.11 (errr I should delete any copies of them)
license infos updated, sorry if something missed :)

Added:
Dual python (msys and native) switchable via PYMSYS environment
Inno Setup
WinAPIOverride's Registry Emulator
Avian (32bit and 64bit), a minimalist GCJ-like java VM which allow native binary creation (JNI) using openjdk and GCC
FreePascal (32bit and 64bit), minimal with rtl only
Mono's csharprepl (C# interpreter 2.0 and 4.0)
minimal Erlang r14
"Rails on Ruby"
GNU CLISP interpreter
Yabasic interpreter and BCX Basic to C Translator
SWF, AS3 Compiler and decompilers
lzo (lzopack), lz (lzip) an lzma variant that not supported by 7za and zpaq an archiver for maniacs
Special Ghostscript with gsdjvu (may have legal issue) and cairo backend
Imagemagick 7's convert.exe with HDRI and OpenMP support
DjVulibre tools
FAR no integration done, planned: custom file association via registry emulator
Oberon2 to C translator (for use with GCC) need real terminal to run (mintty or rxvt)


CompilerPack 0.5a 51.6MB
MD5: a8ffa5fbbf35979ef9201a7bcfe729fe
MSYS Environment 0.5b 21.8MB
MD5: 73fff7b2edf173d38e91793639074c08
Addons 0.5c 39.7MB
MD5: 330a7f4da7bb29dc9c3b1380aba441d4
download at googlecode

Changelog (17 Apr, 2012) :
-git broken build: rebuild with system pthread disabled, updated to 1.7.10, update Tcl/Tk to 8.5.11 as requested gitk

Changelog (10 Apr, 2012) :
-switch to GCC 4.6.3 since no easy workaround for 4.7.0 breakages
experimental:
- custom specs file for targeting runtime now replaced with flags, specify one of : -vcr70, -vcr71, -vcr80, -vcr90 or -vcr100
- enable GCC plugin support
- enable posix thread, time64 and LFS by default for [mingw32s], std::threads need gnuc++0x instead of c++0x flag
- to enable pthread support (including std::threads) -pthread flag required (this is the standard way)
fix:
- when compile as dll automatically switch to shared pthread library, to prevent scattered pthread's exports table
- broken msysgit due to gettext, disabling gettext support
- llvm 3.0 broken due to gcc version change, added 4.6.3 tag
- non GCC and MinGW originated libraries goes to [GCC]\mingw to avoid maintenance headache
update:
- mingw-w64 2.0.2

CompilerPack 0.5 51.9MB [BROKEN]
MD5: 69a6548dcae25a451bf7aca3a1a45d9d
MSYS Environment 0.5a 62.7MB
MD5: d6dcdeecf6741b00f54e8e01d4b88f99

Changelog (04 Apr, 2012) :- no change on compiler pack just moving out "deps" folder
- correct hardlinks of msysgit during post-install
- change cdrtools into msys binary to get benefit from posix path
- added: asciidoc, nginx, minimal php-cgi, rdiff (msys), NTFSLink (need admin to install)
- removed: ruby (not so useful without standard library)
- updated: notepad2, grepwin, scite, doxygen, scons


CompilerPack 0.5 51.9MB [BROKEN]
MD5: 05dcefc35b66ee920d017f0302036b75
MSYS Environment 0.5 62.9MB
MD5: d6dcdeecf6741b00f54e8e01d4b88f99

Changelog (30 Mar, 2012) :
Fix:
- Texi2html, xmlto, git use the wrong path cofiguration
- Many typo corrections
- Better MSVC runtime >= 2008 targeting by setting _WIN32_WINNT and WINVER via specs file, now it's possible to build apps that linked only to MSVCR90.DLL or later out of box! Note: this ability apply to MinGW32 only, MinGW-W64 lacked of #ifdef guards in its headers so you need to know which functions that deprecated/preferred in newer runtime.
- Added libmingwexnew.a (libmingwex for targeting MSVC >= 2008) also rebuild mingwrt to make it smaller, controllable via setgcc/specs
- Rebuild pthread that compatible with MSVC >= 2008 targeting
- Make gdbtui unset TERM internally
Replaced:
- Autotools use mismatched automake-1.11.1 cause autoreconf to fail
- Wrong 7zip SFX files (since version 0.2 it was ordinary SFX, Oops)
- Git 1.7.9 with Git 1.7.10 static build (now moved into /opt/bin)
- Replaced not sane mingw's xsltproc and segfaulted msys' libxml with new msys' build of libxml 2.7.8 and xsltproc 1.1.26
- Pthreads-w32 with current winpthread (mingw32), Pthreads-w32 now goes to secondary library
- Replaced mingw32-w64 with mingw32 that use sjlj (compatible with older TDM)
Removed:
- Msys Perl's devel libs & headers which often trigger configure to detect Perl's presence
- FASM
- Ambiguous mingw folder (contained mingw version of autotools)
Added:
- Minimal Hugs 2006 (haskell 98) interpreter
- Barebone Ruby 1.9.3 interpreter
- Graphviz 2.16
- Static build PHP 5.4.0 interpreter with moderate extensions
- mtall80 and mtall90 (mass manifest embedder), usage for MSVC 2008 target: "cmd //c mtall90.bat" which will embed manifest to all executables in current directory recursively. Need M$ mt (manifest tool) to be present (from WSDK).
- Sqlite3 CLI
- Static build OpenSP 1.5.2 & OpenJade 1.3.3, a SGML/Docbook Processor (msys binary). Now support Docbook documentation toolchains (input: sgml/xml, output: html)
- Spkg 1.0 (not sure if this should be msys or mingw binary, currently mingw). Might be useful to manage package addons libraries in the future.
- Portable Lynx 2.8.7 browser
- Full LLVM 3.0 now restored
New:
- GCC 4.7.0, now only build languages (-java) that considered "default" by GNU
- Better LFS detection for MinGW32
- Enabling posix thread with std::threads for MinGW32


CompilerPack 0.4d 51.9MB
MD5: ee755f186ce134fc94c27faebac2e56f
MSYS Environment 0.4f 62.9MB
MD5: ee8af39bdbc769aa6b849af1b0984857

Changelog (26 Feb, 2012) :
- now installable in a path containing spaces
- junc, gw works with 
path containing spaces
- new: browse, openw
- added: ipython
- fix: sh as default shell not bash, MSYS thene now activated when using msysdev, radare2 lookup path
Changelog (19 Feb, 2012) :
- removed excessive gui tools: regshot, winapioverride32, scylla, processhacker
- added: xml2po (for translation), texi2html
- replaced possibly broken: msys xmllint -> mingw static binary, jscore -> rebuild

Changelog (12 Feb, 2012) :
- added: wxhexeditor, regshot, winapioverride32, drmemory, scylla, processhacker, jscore, lua, mingw-w64 dwarf-2 (for mingw32 compatibility)
- removed: qemu
- fix: incorrect shebang on bzr,hg, make gdb python support portable, many changes on msys.bat & /etc/profile, make openal autostatic, make tcl/tk static build, missing python26.dll (64bit) for gdb (64bit), autoselect 64bit tools in Windows 64bit, setgcc works with spawn
- update: gdb 7.4 with experimental gdbtui (need to unset TERM first before use), binutils 2.22.52
- gcc rebuild
- put some docs in readme, include patches for gcc, gdb, binutils
- many files have been moved around please delete previous version before install this one


0.4c
Changelog (5 Feb, 2012) :
- added: static build bochs (since qemu can't run windows properly), radare2 0.9, postw32 (from freepascal), console2, msysdev, hyperdbg (hdbg), mingw-get (not sure if it usable here, use with caution!), protoc, ldd
- fix: lots of changes in msys.bat loader, pkg-config now run properly outside msys, qemu no longer spit stderror.txt, spawn now works with other shells as it should, wget now look for curl's ca-bundle by default
- new: console2 integration in portable way (spawn -console), msysdev mode (spawn msys), portable singleuser mode
- update: qemu 1.0.50.0git and removed i386 version because x86_64 is the superset of it, mintty, openssl 1.0.0g
- removed: msys-here since I have my own msys-here
I think I will stop updating unless new gcc/clang/msys released I'm quite comfortable with this version


0.4b
Changelog (2 Feb, 2012) :
- added: sphinx, chmcmd (chm compiler from freepascal), static build qemu 1.0, fasm, objconv, distorm
- fix: specs80, specs90, junc, spawn
- update: ca-bundle-crt


0.4a
Changelog (26 Jan, 2012) :
- added: old version but standalone winmerge 2.4.10 (merge), cpuc
- new: junc (create/view/delete junction), spawn (spawn instance of msys with current directory and environment variables), spawnc, spawnp, spawnw
- some msysgit cleanups and license files update


0.4
Changelog (22 Jan, 2012) :
- added: Bazaar, Mercurial, Fossil, nsinstall, ffts (non-GPL FFT from Japan), gmp, mpfr, mpc, qd, intl, zlib, xz, scite (tabbed text editor)
- replaced: msys-xz -> xz, msys-wget -> my wget build
- removed: msys-bsdtar
- experimental: adding msysGIT (some components has been re-build to make it smaller)
- fix: missing pth configurator, make winpthreads autostatic, make TRE a Gnu Regex ABI compatible, restructure directories
- new: msys here (explorer context menu), pkg-config has default search path : [gcc]/mingw/lib/pkgconfig even when PKG_CONFIG_PATH not defined
- updates: intl-tool 0.50.0


0.3.b
CompilerPack 39.1MB
MD5: f50bc0a2f10360425c338ed959529e5f
MSYS Environment 31.6MB
MD5: 99dbd6ef37411260787c1b65b6abc67a

Changelog (15 Jan, 2012) :
- added: OpenGL headers from Mesa and khronos, perl module xml::simple, xsltproc, ragel
- replaced: shared lib openAL -> static lib, pthread-w32(mingw-w64) -> winpthreads r4378,
- experimental: enable std::thread for mingw-w64
- updates: mingw-w64 2.0.1


0.3.a
Changelog (30 Dec, 2011) :
- added: autostatic GLUT and GLEW libraries, OpenCL and OpenAL libraries
- replaced: GNU Regex with static lib TRE
- now include license information
- minor cleanup and updates


0.3
Changelog (15 Dec, 2011):
- added: clang 3.0 (preconfigured with mingw-w64, to use it set CC=clang CXX=clang++), tcc, locales and docs
- removed: strawberry perl, wix (can use python to generate msi), pywin32
- enabling localization for gcc and binutils in portable way
- change the way switching gcc that do not block multi session
- added specs templates and experimental auto-manifest for msvcr8 and 9
- rebuild : gcc, cmake (now smaller)
- bundling gcc's dependencies so users can rebuild/update gcc/clang easily
- installation: create hardlinks in post-install
- packages updates: gdb, upx, nasm, yasm, mingw-make


0.2 (68.8MB)
MD5: ec7d3da61672ba14ed409a6e5dc7af08
Changelog (2 Dec,2011) :
- cosmetic work to mimick Windows Powershell
- fix: pkgconfig which return CR newline instead of CRLF causing configure to failed
- integration: Windows SDK detection, GrepWin, Notepad2
- fix: invalid PATH insertion
- added pywin32, removed junction.exe
- load default GCC and Perl at startup


tuma_porting_kit-0.1.exe 67.2 MB (installed 603 MB)
MD5: fb51c33747450337ffda10191ef56e94

Tips for complete noob (to be continued..)
- to install just run the self extracting installer, it will extract to [current folder]\MSYS, once finished run msys.bat (it is portable installation)
- to see compilers and gdb manual use "info" or "man"
- in msys "/" is the [current folder]\MSYS above and all driveletters mounted after "/" e.g "D:" = "/d", therefor "/" also equal to "/[current driveletter]/[path]/MSYS" see details by type "mount"
- to compile a source package usually we "cd"ing (change directory) into the root of source's folder then type "configure" and then "make"
- the recommended way to compile however is to create a "build folder" outside (better one) or inside source folder then from "build folder" type ../[source folder]/configure or ../configure
- to cleanup compilation files use make clean, for total cleanup use make distclean (need re-configure)
- to install use make install which by default goes to /local folder
- to change default install location use --prefix="[install folder]" to configure line
- we can pause operations in msys by drawing mouse into console (like when we select area), I often do this when my CPU rang overheated during compile and to continue right click on the console. This also equal to copying the content of selected area.
- to redirect compilation messages into file, we can use the usual ">logs.txt" way
- to force verbose compilation when it was suppressed use make V=1
- there is "cp" -> "copy", "rm" -> "del", "mv" -> "ren", or we can use alias copy=cp if that bothersome
- like most console program we may switch into "DOS" mode by typing cmd, there all environment variables will automatically converted to windows style once we're done type exit.
- path auto-completion only works in unix style e.g /path/path/file
- when unix style path feed to non msys program it will be converted to windows path style albeit with "/" instead of "\" separator
- msys is semi-case-sensitive environment where path and file are case-insensitive and most of the rest including variable name are case-sensitive
- to define global variable e.g compiler flags use export varname="value"
- in windows arguments can be represented as %1 %2 %3... similarly in msys $1 $2 $3... and for %errorlevel% in msys this is most likely $?, too bad no %~[x][varname] expansion there
- unlike windows, most command options are begin with "--" or "-" instead of "/" e.g <code>configure --help
- if we get source snapshot tarball with no configure available use "autogen.sh"
- if source packages do not use autotools (configure), try look for makefile or makefile.gcc file then use make -f [makefile] to compile. Other possibilities SConstruct (scons), CMakeLists.txt (cmake)
- to define compiler's flags while overriding global compiler's flags, feed the configure line e.g configure CFLAGS="someflags"
- to change default libtool's dll naming we may modify soname_spec variable (usually inside libtool file after configure done)
- to build an orphaned library (a library required by only a library) as static lib, use --enable-static --disable-shared in configure line
- when throwing python in compilation inside msys, things will get very ugly: path will be mixed between "\\", "\" and "/" separator and most likely fail the process. The easy fix is to actually edit bundled python's ntpath.py and change with sep="/"
- when compiling 32bit binaries I suggest use mingw32 simply because either some packages may need adjustment for mingw-w64 or mingw-w64 is not too similar to mingw32
- according to mingw project, dwarf2 is the future and it's not recommended to mix between mingw32, mingw-w64, dwarf2 and sjlj even if it's possible, so be warned
- a library usually has .a(static lib) or .dll.a(impor lib) extension, although this is just naming convention gcc will prefer .dll.a (dynamic linking) over .a file by default. More precisely: libfoo.dll.a, foo.dll.a, libfoo.a and at last foo.lib.
- if we get undefined error during linking and we find the missing function in library xyz then we can:
re-configure by append LIBS=-lxyz to configure line or
edit suspected makefile and add -lxyz to LIBS declaration or
issue manual make command with the missing -lxyz
- if we still get undefined error maybe we're linking to incorrect static library? maybe we forgot to define something like -DSTATIC_LIBXYZ? or sort of declspec stuff in the suspected lib
- to generate smallest executable (for .exe only) use CC="gcc -flto", CFLAGS=-Os and LDFLAGS="-Wl,-s " but lto (gimple) isn't matured yet and you may encountered ICE

16 comments:

  1. Wonderful! You have done some great porting. I must check out your porting kit!

    Andre

    ReplyDelete
  2. Nice build with a lot of additional libraries.

    However, compared to other builds:

    No thread support built in (for c++0x)?
    GMP, GMPXX, MPFR, MPC dynamic only?

    ReplyDelete
  3. Isn't c++0x std::threads still experimental?
    if not I will enable it in 0.3b, thanks for inform me

    The reason for GMP, GMPXX, MPFR, MPC being dynamic build is it make compiler executables (cc1.exe and friends) much smaller :D, after all it's just compiler dependencies, unless you mean that your program need them? I only supply them so the users can rebuild the compiler

    thanks for trying!

    ReplyDelete
  4. I am not sure about how experimental is std::thread, as I have used boost::thread before (and WinAPI threads before that) and after gcc-4.6.2 was released I have started using std::thread. I haven't used all the features yet but the things I used do work for me.

    The reason I was trying your build of compiler, is that the build I use (from code.google.com/p/mingw-builds/downloads/list which has std::thread support) is having problems with long double numbers (i.e. by assigning -1. the value stored in long double variable is -0.).
    It is just much easier to learn all that new features of new standard C++11 (which is of course not fully implemented yet) by having everything you need in compiler.

    I do actually use GMP, GMPXX, MPFR libraries in calculations as the precision of standard types is simply not enough, but that is not a big problem, as I can copy static libraries from other build and use them in yours as long as the version of the compiler is the same (I do hope :) ).

    Thank you for Your input into open source tools popularity.

    ReplyDelete
  5. I have re-read some mailing-list and std::thread is still not supported in mingw/cygwin due to incomplete feature in pthread-win32, personally I have tried gcc from code.google.com/p/mingw-builds but its (patched?) pthread.h cause trouble to some packages (won't even compile)...

    ReplyDelete
  6. correction: it seems not pthread-win32 but winpthreads http://mingw-users.1079350.n2.nabble.com/enable-std-thread-experimental-patch-td6733978.html

    and the reason why some package failed is pthread_t are different. Anyway it still experimental.

    About your usage of gmp and friends, please note that all of them use march=core2 flag

    ReplyDelete
  7. Looks like you are right, it is still experimental...

    march=core2 is not a problem as all my multi-threaded applications are executed on multi-core processors. :)

    Thank you for clarification of the situation.

    ReplyDelete
  8. Hello, thank you very much for providing these packages; I was looking to install myself a MSYS installation but knowing of the lots of packages that are available it's a lot of work and I stumbled upon yours.

    I would like to request something for the next release if possible. Right now you're including the libiconv binaries but not the development headers and libraries (right now is the file libiconv-1.14-1-msys-1.0.17-dev.tar.lzma in SourceForge). I'd appreciate if that could be included by default too (maybe under the "local" folder).

    I'd also like to know if you plan on updating your compiler package with GCC 4.7 which is now considered to be stable.

    Thank you very much anyway for everything and congratulations on a well done work.

    ReplyDelete
  9. There is a lot things in version 0.5 to be planned. some of them:

    - proper MSVCRxx specs mode: done (tested by building whole GTK against msvcr90.dll)
    - complete documentation toolchain: lack docbook-utils (in progress, openjade is done though)
    - LFS in mingw32 : done
    - winpthread and std::thread in mingw32: in progress
    - spkg integration : in progress
    - turn git to static build: done
    - merge clang,tcc,gcc into one folder: in progress

    anyway iconv in my gcc is a system library (so does pthread and dlfcn), hence reside in [gcc]\triplet

    Thanks for using my pacakges

    ReplyDelete
  10. Error (509)
    This account's public links are generating too much traffic and have been temporarily disabled!

    ReplyDelete
  11. knew it man, I'm slowly mirror them (not all maybe). version 0.5 will come out this weekend, o yeah with gcc 4.7.0 i hope

    ReplyDelete
  12. Git seems to be broken in the current pack, I'm trying to execute a cloning operation from Github and this is the output:

    fatal: Unable to find remote helper for 'https'

    or http in case I try it that way.

    ReplyDelete
  13. Thanks man, I though there is just another missing hardlinks for git-remote-http git-remote-https and git-remote-ftps but turn out there is also threading error too since I override git's pthread. Will rebuild that

    ReplyDelete
  14. Hello, I don't have much knowledge about the different exception models, but I read that they're not to be mixed. So I have a question, I'm rebuilding a library to be used by a program. That program uses more libraries of different projects, some of them were built with MSVC and some were built with MinGW but older versions of the toolchain using sjlj exceptions.

    Would it be safe to build a library (libmpg123 in this case) using a MinGW toolchain which uses Dwarf2 exceptions? Does anybody know which exception model MSVC uses or if either sjlj or dwarf2 are compatible with it?

    Also, when trying to build libmpg123 with the default compiler (mingw32 in the package) it doesn't even pass through configure state failing some tests. Would it be related to dwarf2? Because the other compilers are able to pass through configuration.

    Sorry for the many questions I asked, and excuse any wrong English wording or grammar.

    ReplyDelete
  15. the general assumption is using sjlj for interchange (they are more popular at the moment) and according to some debates is more sane for windows. The configure test errors probably because I messed up mingw headers in 0.5, sorry. I've made corrections maybe tomorrow will be uploaded. I don't know about MSVC's try googling "Structured Exception Handling"

    PS: I'm bad at english too :)

    ReplyDelete