
this is in reference to the following postings to c++-sig and boost-users: 1. http://lists.boost.org/boost-users/2006/02/17367.php 2. http://mail.python.org/pipermail/c++-sig/2006-September/011202.html the summary: individuals, including myself, are seeing "ImportError: dynamic module does not define init function (inithello)" whenever trying to import a module compiled with mingw against boost.python, specifically the python examples and tutorial distributed with boost. the symptom: g++ fails to properly link whenever a null library search path (ie -L"") is specified (because maybe it stops parsing arguments there?). the cause: MINGW_BIN_DIRECTORY is null the short answer (for those newbies just trying to get through the tutorial/example and don't care to dive into the details of boost.build): bjam -sMINGW_BIN_DIRECTORY=C:\MinGW\bin (or where ever your mingw installation is) the longer answer: see attached patch the explanation: A. in gcc-tools.jam: 1. the gcc-Link-action contains -L"$(STDLIBPATH:T)" 2. STDLIBPATH is set based on following commands: a. flags gcc GCC_STDLIB_DIRECTORY : $(GCC_STDLIB_DIRECTORY) ; b. GCC_STDLIB_DIRECTORY ?= $(GCC_ROOT_DIRECTORY)$(SLASH)lib ; c. flags gcc STDLIBPATH : $(GCC_STDLIB_DIRECTORY) ; but when using mingw, the values in gcc-tools.jam are set... B. in mingw-tools.jam 1. local GCC_BIN_DIRECTORY = $(MINGW_BIN_DIRECTORY) ; 2. local GCC_STDLIB_DIRECTORY = $(MINGW_STDLIB_DIRECTORY) ; 3. flags mingw STDLIBPATH : $(GCC_BIN_DIRECTORY) ; so for mingw, STDLIBPATH is always composed of GCC_BIN_DIRECTORY (which is really MINGW_BIN_DIRECTORY). if you set MINGW_STDLIB_DIRECTORY, but not MINGW_BIN_DIRECTORY, you end up with -L"mingw_stdlib_directory" -L"". you must set MINGW_BIN_DIRECTORY to get rid of the null string or insure the null string in MINGW_BIN_DIRECTORY never gets added to STDLIBPATH. i successfully compiled boost.python without needing to set MINGW_BIN_DIRECTORY because the mingw tools are in my path and everything "just works". but if you try to compile python extensions (or at least the tutorial and examples), then things start mysteriously failing. i haven't had time to fully test my patch by building all of boost with it applied, but i'm currently in the process and last i looked bjam had compiled date and filesystem libraries, and was working on iostreams. thanks for boost.python and the mingw support (it feels liberating to compile free software, gratis & libre, with free software; and we'll overlook the operating system ;-). -- undefined@pobox.com