[PATCH 64bit] Fix ONDEE for 64bit

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

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

> I also don't understand the connection to libgnat.

libgnat does use such an X.Y versioning scheme, but it does not use
libtool.  I just mentioned it to preempt what I thought was a likely
counterpoint; it has nothing to do with libgcj.


More information about the Cygwin-patches mailing list