Harlan Stenn <hstenn@xxxxxxxxx> writes: > If there is a better place to discuss this issue please tell me. > I am tyring to build a number of GNU packages on a solaris9 machine. > 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. -- Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/>
