[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: solaris and -lintl problems
From: |
Russ Allbery |
Subject: |
Re: solaris and -lintl problems |
Date: |
Mon, 02 Feb 2004 16:29:54 -0800 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Common Lisp, linux) |
Harlan Stenn <address@hidden> 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 (address@hidden) <http://www.eyrie.org/~eagle/>