This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH 64bit] Fix ONDEE for 64bit
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.
> 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.
Yaakov