Installing Mingw32 repository packages

This document gives verbose description of installation prerequisites, with the hope that it will be usable even for beginners. PW32 uses the same packaging scheme, so you may also read its installation instructions for additional information. For more info on package description files, read packaging conventions.

This document describes installation procedure for Mingw32 repository packages. The package structure and archiving method was specially designed to make installing in most cases as simple as unzipping package in an appropriate place. With that, Mingw32 repository packages contain full information about contained software at whole (such as name, version, urls, dependencies on other packages, etc.) and each file individually. Such an information will allow comprehensive package manager support (currently, such package manager do not exist, but see Zippo as well as my comments what's wrong with it). However, right now structure of package information allows two most common operations - installing new package and upgrading installed package - to be performed by simple unpacking package archive.

Before installing the first package

Before installing packages, working environment should be prepared. This is simple procedure, consisting of following steps:

Below each step discussed in some detail

Setting up Mingw32 prefix subtree

All Mingw32 repository packages should be installed into some directory. It is highly recommended that it was dedicated directory, i.e. each used solely for package installation and nothing else. It may be a subdirectory of some other directory, though, to avoid confusion (such as unexpected recursive deletion), you may want to have it top-level. Directory where your GCC-Mingw32 installed (or its subdirectory) is a bad choice for prefix directory, because Mingw32 releases are used to change frequently, and README usually recommend to delete pevious release before installing new. The last recommendation is that prefix directory was located on the same drive letter where GCC (and your other development software) resides. As specific example, I currently have it in /usr/local on my development drive (E: on the box I write this on). This cannot be suggested as a good choice, since /usr/local is standard GNU/Unix directory, so conflict may arise if some POSIX layer is used. Something like /mingw32 on your development drive is a better choice.

After you have choosen prefix directory, create it. Afterwards this directory will be referred as $prefix. By default, by $prefix will be meant POSIX-like path (i.e. path without drive letter and using forward slashes, e.g. when you chose E:\mingw32, $prefix will be /mingw32). Occasionally, full DOS path of prefix directory will be needed, such cases will be explicitly noted.

Registering prefix binary directory

After package installation, all its executable files will be in $prefix/bin. To allow executables and DLLs to be started/linked from any directory, this directory should be added to your PATH environment variable (you have to use DOS full path). This can be done in several ways, among them:

  1. For Win9x systems, modifying autoexec.bat file
  2. For WinNT systems, modifying Environment Settings in Control Panel
  3. Most portable and convenient way is to set up it with special bat file which will startup your working shell
The latter case looks following way:
PATH e:\mingw32;%PATH% command
Replace e:\mingw32 with DOSofied path of $prefix/bin and command with commands to start your shell (the above will just start command.com).

Registering prefix include and library directories

This step is required for developers, who's going to install development packages containing files used to compile and link software. When development package of particular library is installed, all library header files go to $prefix/include and import libraries - to $prefix/lib. When compiling and linking software, compiler needs to know that it should search headers and libraries at the locations above. There are several ways to do that:

  1. Each time explicitly pass -I$prefix/include and -L$prefix/lib to compiler
  2. Setup environment variables to point there (read GCC documentation for more info)
  3. Modify compiler's specs file
Since I use many different environments and compilers, I prefer the third, since it's easy to mess environment variables. Specs file needs following modifications: Here is the patch against gcc-2.95.2-1:
*** specs.org	Mon Jul 17 07:02:57 2000
--- specs	Mon Jul 17 07:03:18 2000
***************
*** 5,11 ****
  
  
  *cpp:
! -remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT}
  
  *cc1:
  %(cc1_spec) 
--- 5,11 ----
  
  
  *cpp:
! -I/usr/local/include -remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT}
  
  *cc1:
  %(cc1_spec) 
***************
*** 17,23 ****
  
  
  *link:
! %{mwindows:--subsystem windows}                    %{mconsole:--subsystem console}                    %{shared: %{mdll: %eshared and mdll are not compatible}}                    %{shared: --shared} %{mdll:--dll}                    %{shared|mdll: -e _DllMainCRTStartup@12}
  
  *lib:
  %{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32}                   -luser32 -lkernel32 -ladvapi32 -lshell32
--- 17,23 ----
  
  
  *link:
! -L/usr/local/lib %{mwindows:--subsystem windows}                    %{mconsole:--subsystem console}                    %{shared: %{mdll: %eshared and mdll are not compatible}}                    %{shared: --shared} %{mdll:--dll}                    %{shared|mdll: -e _DllMainCRTStartup@12}
  
  *lib:
  %{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32}                   -luser32 -lkernel32 -ladvapi32 -lshell32

Replace /usr/local with your $prefix.

Installing the package

To install new package, you simply need to unzip it to your prefix:

unzip <package_name> -d $prefix
This assumes you use standard InfoZIP (recommended, you cac get it here), but you can use any other unzipping utility which supports long filenames (WinZip ok, pkunzip no).

Upgrading the package

To upgrade already installed package with newer version, also simply unzip it into $prefix:

unzip <package_name> -d $prefix
All package description files will be replaced with new versions. Of course, upgrade operation may leave stale files, but this can be fixed only with package manager.


Paul Sokolovsky | use this form to submit bug