My Win32 builds of GNOME software that need a POSIX regular expression (regex) library were until now (December 2006) built against Henry Spencer's regex library. More specifically, a Win32 build of it as distributed by the gnuwin32 project (see http://gnuwin32.sourceforge.net/packages.html). Unfortunately there has been a fatal confusion in the name of the DLLs of the Spencer and GNU regex libraries. In the gnuwin32 version "3.8" of the Spencer regex library, the DLL was called "regex.dll". This version can be found at http://prdownloads.sourceforge.net/gnuwin32/regex-spencer-3.8-bin.zip and http://prdownloads.sourceforge.net/gnuwin32/regex-spencer-3.8-lib.zip and is what I used. In the current gnuwin32 version of Spencer regex, "3.8.g.3", the DLL is called "rxspencer.dll". (It presumably still offers the same API and ABI as the "3.8" regex.dll, though. But in this case the rename is a good thing. Read on.) Now comes the catch: the name "regex.dll" is also (situation in December 2006, at least) used by the gnuwin32 distribution of the GNU regex library version 0.12. (This is as such a quite old version of GNU regex, built from sources from 1993. The GNU regex sources were subsequently merged into glibc, and no separate official distributions of GNU regex source have been made since.) This clash is horrendous, as these two regex libraries are not at all binary compatible, but this is hard to notice, as they provide the same POSIX regex functions as entry points. For starters, the regex_t struct type is larger in the GNU regex library than in the Spencer regex library. Also, some constants defined in the regex.h header like REG_NEWLINE and REG_NOSUB have different value in the two implementations. (Both naturally provide a regex.h file, as they should, that is not a problem as such.) My earlier Win32 builds were against gnuwin32's "3.8" builds of Spencer regex, and thus the binaries who use it link to regex.dll, which should be the Spencer regex DLL. If one instead uses the regex.dll from gnuwin32's GNU regex 0.12 package, one will hopefully get a crash, or in the worst case, silent data corruption. It is very possible and likely even that somebody who downloads my gtkhtml 3.12.0 build, for instance, notices that it requires something called "regex.dll", and then assumes this is the gnuwin32 build of GNU regex. He downloads that, notices that yes indeed, there is regex.dll, and it contains the required entry points. So let's use gnuwin32's 3.8.g.3 build of Spencer regex then? That seemed like a good idea, until I noticed that it is horribly broken. It has been built with an nonstandard addon to the mingw environment that redefines the off_t type as long long. The regoff_t type in Spencer's regex.h is typedeffed as off_t. Horror! This means that the rxspencer.dll thinks a regmatch_t is two long longs, while user code built in a normal mingw environment thinks it's two longs. Thus the 3.8.g.3 build is not usable either. Since December 2006 I will do my Win32 builds of GNOME software against an own build of the regex part from a fresh glibc, that provides a DLL called libgnurx-0.dll. I package this as "libgnurx" (a name I just came up with myself). This should hopefully avoid any confusion. So, what to learn from this: If you build and distribute Win32 binaries, don't forget this simple rule: Never, ever, use the same name for two incompatible DLLs. Note that *adding* API to a library (which is something quite normal and common to do as a library evolves) does not make it incompatible. Deleting API or otherwise changing the ABI does. Always change the name of the DLL when it grows incompatible with earlier versions. Another important lesson: Don't use "secret sauce" additions to a standard build environment (like mingw) that change the definition of standard types like off_t. This can cause a library you build and distribute to be binary incompatible with client code built without the "secret sauce". --Tor Lillqvist ,