[PATCH 64bit] Fix ONDEE for 64bit

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Tue Mar 5 06:19:00 GMT 2013

On Mon, 4 Mar 2013 15:40:22 +0100, Corinna Vinschen wrote:
> On Mar  4 14:15, Corinna Vinschen wrote:
> > Thanks, but here's a question:  If the libgcj ABI version really changes
> > with every GCC major.minor release, wouldn't it then make sense to
> > change the libgcj DLL versioning scheme so it uses the GCC major.minor
> > number rather than an arbitrary version number?
> > 
> > In other words, why not cyggcj-4.8.dll?  This would allow easy
> > automation of Cygwin's LIBGCJ_SONAME, and everybody would know what
> > GCC version it's based on.
> Here's my version of the LIBGCJ_SONAME setting:
> #include "bversion.h"
> #endif
> #define ___cyg_mkstr(x) #x
> #define __cyg_mkstr(x)  ___cyg_mkstr(x)
> #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MAJOR) "." \
> 				__cyg_mkstr (BUILDING_GCC_MINOR) ".dll"

I don't know if the version changes are a matter of policy or just how
it has happened, but in any case that's not the current versioning
scheme, nor is it how libtool libraries are usually versioned (and no,
libgnat is not built with libtool).  As long as this continues, the
following would work instead if you want to automate it:

#define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"

Also, you missed the #undef CXX_WRAP_SPEC_LIST before #define
CXX_WRAP_SPEC_LIST in cygwin-w64.h; this avoids a bunch of warnings
building GCC.


More information about the Cygwin-patches mailing list