This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bootstrap broken because of missing intl routines
> From: David Edelsohn <dje@watson.ibm.com>
>
> >>>>> Kaveh Ghazi writes:
>
> Kaveh> (An obvious work-around is to configure with --disable-nls)
>
> Nope. I always bootstrap on AIX with --disable-nls, and that now
> fails:
>
> gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long -fno-common
> -DHAVE_CONFIG_H -o cc1 \ c-parse.o c-lang.o c-pretty-print.o
> attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
> c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
> c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o
> prefix.o c-objc-common.o c-dump.o c-pch.o libcpp.a rs6000-c.o
> main.o libbackend.a ../libiberty/libiberty.a
> ld: 0711-317 ERROR: Undefined symbol: .iconv_open
> ld: 0711-317 ERROR: Undefined symbol: .iconv_close
> ld: 0711-317 ERROR: Undefined symbol: .iconv
>
> So, Zack's patch appears to now require NLS support on all systems and
> break --disable-nls configuration, which is unacceptable.
Hmm, well --disable-nls allowed me to link cc1 on solaris2...
Yours looks like a different problem, gettext vs iconv.
Checking... ah solaris2 has the iconv* functions in libc, that's why
it worked for me.
I would agree that Zack should have tested his patch on a non-glibc
system that didn't have any libintl etc before installing it.
Nevertheless, I am confident he'll fix it ASAP. It looks like the
gettext problem is just a matter of adding libintl.a to the link
command for cc1. The iconv stuff I'm not sure about, we may need to
import an iconv package.
> Zack> I don't want to delay this patch for it, because I
> Zack> need this patch in order to move cpplib to its own directory, and
> Zack> that needs to happen in stage 1 which is almost over.
>
> I again STRONGLY voice my displeasure at a development cycle that
> solely is based on dates and not functionality. Yes, we need to have
> milestones associated with dates, but leading developers to believe that
> they need to commit functionality earlier than they feel it is ready and
> fully tested to meet some inflexible deadline only leads to the current
> instability.
>
> I would recommend goal dates and goal features with regular
> updates of which features are on target. If we know about a large change
> and it will be a little late to meet the Stage 1 deadline, we can
> accomodate the slippage for individual features. Instead we have a
> perceived hard deadline for a mysterious set of features, which serves no
> one.
>
> David
While I would agree that a feature-based cycle works for employee
based projects, we still are in a situation in which the RM on
volunteer based project cannot enforce anyone to work on any features,
he can only enforce a deadline. That's the crux of this problem.
However since I just got bit by this, I'll move myself from the
goal-date column to "on the fence", due to being annoyed by all the
mainline breakage recently. Working around the missing intl just
get's me to the next bootstrap failure from Jan's patch. :-/
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu