[Chicken-users] Cygwin corner cases

[Brandon J. Van Every]

John Cowan wrote:

Scripsi:

  

Fair enough.  I'm certainly not -- I build and run Chicken solely
under Cygwin, and as soon as the CMake builds actually work I'll be
trying them out in that environment.
    

I forgot to mention that the cyg- prefix on Cygwin DLLs is precisely so
that Cygwin and MinGW (or plain Win32) versions of DLLs can coexist on
the same box.  Linkers other than Cygwin's will not find Cygwin-specific
DLLs that begin with cyg-.  So cygchicken should not become libchicken.
  

Another variation of DLL Hell.  Now what if the application actually wishes to know about and manipulate the names?  Now they've gotta do everything special for Cygwin.

At http://www.openldap.org/faq/data/cache/301.html there's a nice
discussion of building MinGW under Cygwin and why you want to use the
-mno-cygwin switch instead of the MinGW gcc directly (basically because
if your build environment contains symbolic links, MinGW-built versions
of the compiler etc. will not understand them).  There is nothing
LDAP-specific here.


  

If you read closely, you will see why -mno-cygwin is an invitation to headaches:

At first glance, it may look like Cygwin GCC does all of the right things. As a matter of fact, it does MOST of the right things. Unfortunately, it does some things wrong:

    * Generic GCC is hard-coded to always look in /usr/lib and /lib when searching for libraries. This is a problem when using "mingw" mode because Cygwin libraries are installed in /usr/lib. The linker should never search in the Cygwin-specific lib directory when linking "mingw" binaries. However, since the Cygwin-specific lib directory is the same directory as one of GCC's hard-coded directories, this has the potential to happen and cause problems.
    * Whether in "cygwin" or "mingw" mode, Cygwin GCC's linker adds the "cyg" prefix to DLL basenames during its library search phase. This should not happen in "mingw" mode.

The solution to the first problem involves moving files around and fixing GCC's specs file. The solution to the second problem is a simple fix to the specs file.


People who install MinGW from www.mingw.org or via Dev-Cpp, get an environment that is meant to work properly with MinGW in all respects, and is extensively tested by many people for such.  They don't have to deal with weird corner cases that someone forgot, and that someone is always forgetting as development marches onwards.  They don't deal with .h file confusion, they've got the .h files they're supposed to have and no others.  It is hard enough to get people to take MinGW seriously, to adopt it as a reliable compiler.  I have no interest in trying to get them to take "MinGW" under Cygwin seriously.


Cheers,
Brandon Van Every