Contents

Name
Version
Some data
Version History
August 30, 2004
Introduction
Why a MinGW port?
What's the difference from the MSVC port?
Restrictions
Configuring bigloo for MinGW
Known Issues
Author

README.mingw - Instaling bigloo on Windows MinGW system.

@VERSION@

Initial date of writing   : March 21, 2004 Hans Oesterholt-Dijkema

This readme is in Plain Old Documentation (POD) format. It can be processed by Perl's pod2html, or better even by Hans Oesterholt's spod2html (which at the moment of writing has not yet entered the public domain). To convert the document using spod2html use 'spod2html --pod README.mingw'. It will generate README.mingw.html.

Initial date of writing   : March 21, 2004 Hans Oesterholt-Dijkema Last revision             : August 30, 2004 Hans Oesterholt-Dijkema

I removed a couple of bugs from the mingw bigloo 2.6d version. In cprocess.c, I had to include malloc.h to get a working alloca function. This made the recette crash on the process tests.

In os.scm, the dirname function didn't work right. This generated errors in the recette.

In recette/string.scm a unix-path->list function working on a UNIX Path would yield a wrong result, as the path separator on windows is ';', not ':'. I changed the test.

I also added a bigger stack size in the ldextraopt configuration script.

This README handles the MinGW Port of Bigloo.

MinGW and Win32 are different things. Although MinGW compiles for Win32 (together with MSYS) it behaves quite Unix Like.

But why not use the MSVC port of bigloo? The answer to this is straightforward. A MinGW user wants to be able to use gnu make, bmake that is. He/she wants to use ./configure for making his/hers projects. Mostly a MinGW user is a Unix minded person that wants to be able to compile hers/his software on a Windows platform, so that she/he can support the big group of Windows users.

The short answer: A MinGW user is a Unix user that can't go around Windows.

Not so much. The MinGW port is closer to Unix, so it does have some of both worlds. It e.g. uses Posix Threads where possible. It handles bot Unix paths and Windows paths. It uses a similar compiler scheme to the unix source, but needs a bit of windows there too. On the other side: it uses a lot of the MSVC port code base. It just sets the right directive to reuse that code.

  • The MinGW Port can't do dynamic libraries. gcc won't make the right exception code to use in dll's for Boehm's GC as opposed to MSVC. If you want dynamic libraries: use the MSVC port.

  • The MinGW port is a Native Backend only port. You can't do the JVM nor the DOTNET port. Use the MSVC port for those.

  • The fair threads code contains some signal handling code that can't be used on windows. I don't know the impact of that.

Start an MSYS session. You can only compile bigloo for MinGW from an MSYS session. See to it that you have the redhat posix thread port in your MinGW system. See to it that c:/MinGW/bin is in your path.

Now you can type e.g.:

 tar xzf bigloo2.6d.tar.gz
 cd bigloo2.6d
 ./configure --prefix=c:/progs/bigloo --jvm=no --dotnet=no
 make
 make install

To run the recette you can use

 make test
  • Compiling fthreads, the garbage collector code has a declaration problem (in any case, with gcc 3.3.3). The prototype for GC_CreateThread needs to be changed.

     HANDLE WINAPI GC_CreateThread(...)
    

    becomes

     GC_API HANDLE GC_CreateThread(...)
    
  • The patch alters a .scm file, that need to be recompiled. So you need bigloo to apply the patch. Mostly the unix bigloo will do this job, but I personally ran into problems with runtime/Llib/os.scm. I needed to compile a windows bigloo before altering this file. Maybe the MSCV port of bigloo can be of help to bootstrap these .scm files.

Hans Oesterholt-Dijkema <hdnews -at- gawab -dot- com>