Re: solaris and -lintl problems

[Harlan Stenn]

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.