[PATCH 64bit] Fix ONDEE for 64bit

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Mar 5 09:30:00 GMT 2013

On Mar  5 03:14, Yaakov wrote:
> On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> > On Mar  5 00:09, Yaakov wrote:
> > > 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:
> > 
> > Where exactly is the problem?  I thought *we* can define how the DLL is
> > called.  Is anything outside of the GCC toolchain expecting a specific
> > DLL name and relying on it? 
> No, we don't control the DLL name; libjava/Makefile.am and
> libjava/libtool-version determine the soname of libgcj based on
> standard libtool naming and versioning practices.  Since GCC 3.2
> (libgcj.so.3), there has been a consistent +1 version bump for each
> major.minor release, hence the x+6 for the 4.x series
> (for 4.8: cyggcj-14.dll, libgcj.so.14, etc.).
> The define in cygwin*.h or mingw32.h is used in
> libgcc/config/i386/cygming-crtbegin.c:__gcc_register_frame(), so it's
> the define that needs to match the build system, not the other way
> around.

Sigh, ok.  I'll use your definition.  What do we do when gcc 5.0
is getting close?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list