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 10:30, Corinna Vinschen wrote:
> 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?
What about
#if BUILDING_GCC_MAJOR == 4
#define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
#else
#error LIBGCJ_SONAME versioning scheme needs attention
#endif
for now?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat