Re: [PATCH] Don't link ecj1 against libgcj.so.* (PR libgcj/38396)

[Paolo Bonzini <bonzini at gnu dot org>]

> But when we are already touching this...
> It is true that for !ENABLE_SHARED USE_LIBGCJ_BC doesn't make any sense.
> Perhaps we should disable USE_LIBGCJ_BC if !ENABLE_SHARED during configury.
> 
> Still, I guess we should avoid -lgcj_bc for -static, so perhaps
> if "$enable_shared" != yes; then
>   use_libgcj_bc=no
> fi

This could go in configure.host too:

 case "${host}" in
   *linux*|*-kfreebsd*-gnu|*-gnu*)
-    use_libgcj_bc=yes
+    use_libgcj_bc=$enable_shared
   ;;
   *)
     use_libgcj_bc=no
   ;;
 esac

> if test "$use_libgcj_bc" = yes; then
>   LIBGCJ_SPEC="%{s-bc-abi:%{static:-lgcj;:-lgcj_bc};:-lgcj}"
> fi

And I agree on this too.  If it fixes the bug, it would indeed be a
better fix.

> in configure.ac.  I'm not convinced we want to get rid of libgcj.la
> in ecjx_LDADD for !USE_LIBGCJ_BC, that includes all kinds of weird targets
> which perhaps want rpath or something similar sticked into the executable.

Though this means that, on those targets, libtool cannot produce
executables with the correct rpath.  It is perfectly possible that this
hasn't ever been exposed, but it would be a major breakage anyway.  So,
while for 4.4 it is not safe and we should help libtool handle this case
correctly, for 4.5 maybe it is worth trying it.

Paolo