This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 3.0.1 PATCH: Substitute LIBICONV in gcc/Makefile.in


>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> A fresh bootstrap of gcc 3.0.1 20010719 on alpha-dec-osf5.1
Rainer> just failed since jv-scan didn't link:

Thanks.

Geoff, it turns out that my long (and unbelievably laborious) testing
strategy for my iconv patch was doomed to failure.  That's because
somehow the link could succeed even when libiconv was not linked
against.

I dug a little more and it turns out that this can happen because the
-I option to find libiconv's iconv.h is not actually passed to the
compilation.  So the link error one would expect in this case never
occurs :-(.  Or, in other words, despite the fact that I believed I
tested the libiconv case, I actually failed to do so.

Rainer> This happens since java/Make-lang.in refers to $(LIBICONV),
Rainer> but the AC_SUBST in aclocal.m4 has no effect at the moment, so
Rainer> the variable is undefined, while Tru64 UNIX V5.1 needs -liconv
Rainer> for those functions.  The patch below fixes this.  Ok for
Rainer> branch and mainline, provided the bootstrap completes?

I can't approve this, but I do agree that it is the right thing to do.

However, I think it is insufficient.  We must also modify the gcc
Makefile to take the appropriate -I and -L options into account.  But
doing that requires a more complex patch.  That's because gcc doesn't
define CPPFLAGS=@CPPFLAGS@ (ditto LDFLAGS) in Makefile.in (imho it
should).

The CPPFLAGS/LDFLAGS change is only needed if we want
--with-libiconv-prefix to work correctly.  I don't know if this is
critical.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]