|From:||Brandon J. Van Every|
|Subject:||[Chicken-users] Cygwin corner cases|
|Date:||Fri, 14 Jul 2006 12:10:59 -0700|
|User-agent:||Thunderbird 220.127.116.11 (Windows/20060516)|
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.
Brandon Van Every
|[Prev in Thread]||Current Thread||[Next in Thread]|