[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: solaris and -lintl problems
From: |
Harlan Stenn |
Subject: |
Re: solaris and -lintl problems |
Date: |
Tue, 03 Feb 2004 19:33:27 -0500 |
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.