This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 64bit] Fix ONDEE for 64bit


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:
> 
> #ifndef BUILDING_GCC_MAJOR
> #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.


Yaakov


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]