This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH 64bit] Fix ONDEE for 64bit
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat