| Message ID | 20110129101408.GG11288@gmx.de |
|---|---|
| State | New |
| Headers | show |
On Sat, 29 Jan 2011, Ralf Wildenhues wrote: > Proposed patch for trunk below. Gerald, can you (or somebody else > who experiences the problem) please confirm that it fixes things for > you (after rerunning autoconf-2.64 in libjava/)? Thanks, Ralf! I did run three tests on x86_64-unknown-freebsd8.2 to assess the patch: First, I ran a full bootstrap of the failing scenario (which depends on how/where libiconv is installed) configured with --disable-rpath; then I ran the same without --disable-rpath; and finally I ran a test without --disable-rpath but your patch applied and autoconf rerun for libjava. The second test, which is default behavior, failed. The first (my current workaround) and third (your change) succeeded. Long story short, I am happy to report that your patch fixes bootstrap. > Otherwise, bootreg on i686-pc-linux-gnu is running. OK for trunk > if it passes and given positive feedback? What about backporting > after a few weeks? The issue has been present since at least 4.0, > so it is not a recent regression. As far as I can tell, it would be good to backport this to GCC 4.5 which is the latest release. Personally I don't see a need to backport farther, but of course others may disagree. Gerald
* Gerald Pfeifer wrote on Sun, Jan 30, 2011 at 12:16:19AM CET: > On Sat, 29 Jan 2011, Ralf Wildenhues wrote: > > Proposed patch for trunk below. Gerald, can you (or somebody else > > who experiences the problem) please confirm that it fixes things for > > you (after rerunning autoconf-2.64 in libjava/)? > Long story short, I am happy to report that your patch fixes bootstrap. Thanks for testing. I've pushed the patch to trunk now. I'm not quite sure if I've overstepped my privileges there, please be sure to tell me if so. > > Otherwise, bootreg on i686-pc-linux-gnu is running. OK for trunk > > if it passes and given positive feedback? What about backporting > > after a few weeks? The issue has been present since at least 4.0, > > so it is not a recent regression. > > As far as I can tell, it would be good to backport this to GCC 4.5 > which is the latest release. Personally I don't see a need to backport > farther, but of course others may disagree. I'll wait a few weeks before looking at a backport. Cheers, Ralf
diff --git a/libjava/configure.ac b/libjava/configure.ac index 52e5d78..284a013 100644 --- a/libjava/configure.ac +++ b/libjava/configure.ac @@ -1240,6 +1240,8 @@ else AM_ICONV AM_LC_MESSAGES AC_STRUCT_TIMEZONE + LDLIBICONV=`echo " $LIBICONV " | sed "s/${acl_cv_wl--Wl,}/ /g; s/,/ /g"` + AC_SUBST([LDLIBICONV]) AC_CHECK_FUNCS(gethostbyname_r, [ AC_DEFINE(HAVE_GETHOSTBYNAME_R, 1, diff --git a/libjava/libgcj.spec.in b/libjava/libgcj.spec.in index 8d39532..22eec3d 100644 --- a/libjava/libgcj.spec.in +++ b/libjava/libgcj.spec.in @@ -7,6 +7,6 @@ *startfile: @THREADSTARTFILESPEC@ %(startfileorig) %rename lib liborig -*lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ @LIBMATHSPEC@ @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig) +*lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ @LIBMATHSPEC@ @LDLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig) *jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ @LIBGCJ_BC_SPEC@ -fkeep-inline-functions