henman at it
Dec 13, 2006, 1:03 AM
Post #1 of 2
(285 views)
Permalink
|
It was noted that cygwin has a a POSIX API wrapper for the Win32 API, with the gcc and other gnu tools.
Mingw and DJGPP, unlike Cygwin, are designed for developing with the Win32 API directly and consequently they are not as useful for porting Unix projects to Windows or writing code that works on both Windows and Unix
If you only need to build executables and static libraries the cygwin will normally build the source successfully (except from sometems win-32 quirks pop up).
However, when it comes to shared libraries, ms-w32 dll format files are not the same as the *nix shared libraries (.so). At link time, a DLL effectively consists of two parts; the DLL itself which contains the shared object code, and an import library w
hich consists of symbol stubs) functions which are actually linked into the executable, at a rate of one stub per entry point. So some differentiation is necessary for cygwin when building shared libraries, to allow for dll building.
.
"Cygwin can't replace the Windows runtime linker/loader so we're all stuck with it's behavior". I believe that this is still the case.
Some of gpg related programs GNU auto-tools input files mention only mingw32 and set a W32 or some sort or other. It would be nice to also include a test case for cygwin and use the proper makefile.am and configure.in or .ac files.
for example
-----------
"makefile.in" ... so from makefile.am needs
<libname_la>_LDF+AGS = -no-undefined -version-info x:y:z
"configure.in"
-------------
before the line containting AM_PROG_LIBTOOL the libtool provided macro,
"AC_LIBTOOL_WIN32_DLL" needs to be added.
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel[at]gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
|
