2013/3/23 Dave Korn <dave.korn.cyg...@gmail.com>: > On 22/03/2013 09:00, Kai Tietz wrote: > >> (LIBGCJ_SONAME): Make name minor-build-version dependent. >> >> Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please >> especially a look to LIBGCJ_SONAME change. I think we should include >> MAJOR_VERSION here, too. Ok for apply? > > I'm not sure about it: > >> -/* We should find a way to not have to update this manually. */ >> -#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-13.dll" >> - >> +#ifndef BUILDING_GCC_MAJOR >> +#include "bversion.h" >> +#endif >> +#define ___cyg_mkstr(x) #x >> +#define __cyg_mkstr(x) ___cyg_mkstr(x) >> +#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 > > > AIUI, the libgcj soversion has no fixed relation to the GCC major/minor > version of necessity, but is specified by the parameters in > $srcdir/libjava/libtool-version, which is manually updated. We really ought > to run a script to extract the version info fields from there and do the > calculation ourselves if we're going to try to automate it. Even if it is > policy to bump the libgcj soversion with every minor release of GCC, there's > no use us having the "right" value if someone neglects to update libjava; only > generating it from the libjava file will guarantee everything stays in > absolute lockstep. > > cheers, > DaveK
Hmm, well, not sure about that too. We shouldn't put hard dependencies into gcc's build about target-libraries, but yes - if unavoidable - a automated way to detect version-number I would welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Cheers, Kai
