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
