This is the mail archive of the
mailing list for the GCC project.
Bootstrap broken because of missing intl routines
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org
- Date: Fri, 04 Jul 2003 23:53:54 -0400
- Subject: Bootstrap broken because of missing intl routines
- References: <200307050106.VAA04578@caip.rutgers.edu>
>>>>> 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
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.
Zack> I think I see what's wrong (short: version skew between *_GNU_GETTEXT
Zack> autoconf macros) I have to leave now but I will try to do something
Zack> about it tomorrow morning.
Remember that gcc.gnu.org will be offline tomorrow morning for "a
few hours" to move the machine to a new co-location facility, so all of
these problems are not going to be fixed until the machine comes back up.
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
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