Same result when using
$CXX -o ffmeta ffmeta_main.cc -pthread -D__STDC_CONSTANT_MACROS
-B{HOME}/local/sol2/bin $CPPFLAGS $LDFLAGS -lavformat -lavcodec -lavutil -lx264
-lbz2 -lz -lxerces-c
I googled for wr...@sunw_0.9. Seems this is a pretty common problem with no
specific, concrete fixes. One I did notice was some issues with GC configure. I
did not use the recommended - I used
tov...@siamese%$cc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /net/whistler/auto/users/tovrea/GCC_SOL/gcc-4.4.0/configure
--prefix=/net/whistler/auto/users/tovrea/local/sol2 --enable-shared
--with-ld=/usr/sfw/bin/gld --with-as=/usr/sfw/bin/gas --enable-bootstrap
--enable-languages=c,c++ --enable-version-specific-runtime-libs --enable-cxx=yes
Thread model: posix
gcc version 4.4.0 (GCC)
Some hits seemed to indicate that /usr/ccs/bin/ld should be used, not
/usr/sfw/bin/gld.
-----Original Message-----
From: David Bertoni [mailto:[email protected]]
Sent: Thursday, September 10, 2009 1:32 PM
To: [email protected]
Subject: Re: Problems linking to Xerces-C++ 2.8.0
Tovrea, George W (US SSA) wrote:
> ## --------- ##
> ## Platform. ##
> ## --------- ##
>
> hostname = siamese
> uname -m = sun4u
> uname -r = 5.10
> uname -s = SunOS
> uname -v = Generic_118833-33
>
> /usr/bin/uname -p = sparc
> /bin/uname -X = System = SunOS
> Node = siamese
> Release = 5.10
> KernelID = Generic_118833-33
> Machine = sun4u
> BusType = <unknown>
> Serial = <unknown>
> Users = <unknown>
> OEM# = 0
> Origin# = 1
> NumCPU = 1
>
> /bin/arch = sun4
> /usr/bin/arch -k = sun4u
> /
>
> Compile:
>
> tov...@siamese%printenv CXX
> /net/whistler/auto/users/tovrea/local/sol2/bin/g++
> tov...@siamese%env | grep FLAGS
> CPPFLAGS=-I/net/whistler/auto/users/tovrea/local/sol2/include
> LDFLAGS=-L/net/whistler/auto/users/tovrea/local/sol2/lib/gcc/sparc-sun-solaris2.10/4.4.0
> tov...@siamese%setenv LDFLAGS
> "-L/net/whistler/auto/users/tovrea/local/sol2/lib
> -L/net/whistler/auto/users/tovrea/local/sol2/lib/gcc/sparc-sun-solaris2.10/4.4.0"
>
> Error:
>
> tov...@siamese%$cxx -o ffmeta ffmeta_main.cc -D__STDC_CONSTANT_MACROS
> -B{HOME}/local/sol2/bin $CPPFLAGS $LDFLAGS -lavformat -lavcodec -lavutil
> -lx264 -lpthread -lbz2 -lz -lxerces-c
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined
> reference to `wr...@sunw_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined
> reference to `o...@sunw_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined
> reference to `pthread_eq...@sunw_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined
> reference to `cl...@sunw_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined
> reference to `r...@sunw_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined
> reference to `pthread_s...@sunw_0.9'
> collect2: ld returned 1 exit status
A quick Google search suggest you're linking the pthread and c libraries
in the wrong order. What happens if you use the -pthread command line
switch, instead of linking explicitly with libpthread?
In general, it's a bad idea to explicitly link with compiler/system
libraries with GCC. Instead, you should let the compiler select the
correct libraries based on the command line switches you provided.
Dave
