Re: solaris and -lintl problems

[Russ Allbery]

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/>