Thanks, Russ, I did the nm and the libintl_ prefix is *not* present in intl/libintl.a; does this point to a -I order problem? What is a good way to fix this? H -- >> I am frequently seeing failures like this one (from gcc-3.3.2): >> gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -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-objc-common.o c-dump.o libcpp.a main.o libbackend.a ./intl/libintl.a ../libiberty/libiberty.a >> Undefined first referenced >> symbol in file >> libintl_bindtextdomain libbackend.a(intl.o) >> libintl_gettext c-parse.o >> libintl_textdomain libbackend.a(intl.o) >> ld: fatal: Symbol referencing errors. No output written to cc1 >> collect2: ld returned 1 exit status >> *** Error code 1 > I think you're getting the wrong libintl. Those look like the library > interface to GNU libintl that gets set up in its header files. I've > encountered exactly those error messages before on Tru64 when the system > libintl was built dynamically and the GNU libintl was built statically and > Tru64's odd library resolver picked up the system version in preference. > That obviously isn't what's happening here, but I wonder if you've somehow > got a libintl in the intl directory that's built without the libintl_ > prefix renaming. I'd check intl/libintl.a with nm and see whether it's > defining symbols with the libintl_ prefix or not.
