You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xerces.apache.org by "Tovrea, George W (US SSA)" <ge...@baesystems.com> on 2009/09/10 21:55:04 UTC
Problems linking to Xerces-C++ 2.8.0
## --------- ##
## 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:
tovrea@siamese%printenv CXX
/net/whistler/auto/users/tovrea/local/sol2/bin/g++
tovrea@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
tovrea@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:
tovrea@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 `write@SUNW_0.9'
/net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `open@SUNW_0.9'
/net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `pthread_equal@SUNW_0.9'
/net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `close@SUNW_0.9'
/net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `read@SUNW_0.9'
/net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `pthread_self@SUNW_0.9'
collect2: ld returned 1 exit status
These reference do not look familiar. Are they part of xerces_c?
Bill Tovrea
BAE Systems
16550 West Bernardo Drive
San Diego, CA 92127
Telephone: (858) 592-5292
Pager: (888) 971-4964
E-mail: George.Tovrea@baesystems.com
Re: Problems linking to Xerces-C++ 2.8.0
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi George,
Tovrea, George W (US SSA) <ge...@baesystems.com> writes:
> Some hits seemed to indicate that /usr/ccs/bin/ld should be used,
> not /usr/sfw/bin/gld.
In my experience you need to use Sun ld with gcc on Solaris.
Boris
--
Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog
Open-source XML data binding for C++: http://codesynthesis.com/products/xsd
XML data binding for embedded systems: http://codesynthesis.com/products/xsde
RE: Problems linking to Xerces-C++ 2.8.0
Posted by "Tovrea, George W (US SSA)" <ge...@baesystems.com>.
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 write@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
tovrea@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:dbertoni@apache.org]
Sent: Thursday, September 10, 2009 1:32 PM
To: c-users@xerces.apache.org
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:
>
> tovrea@siamese%printenv CXX
> /net/whistler/auto/users/tovrea/local/sol2/bin/g++
> tovrea@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
> tovrea@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:
>
> tovrea@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 `write@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `open@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `pthread_equal@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `close@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `read@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `pthread_self@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
Re: Problems linking to Xerces-C++ 2.8.0
Posted by David Bertoni <db...@apache.org>.
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:
>
> tovrea@siamese%printenv CXX
> /net/whistler/auto/users/tovrea/local/sol2/bin/g++
> tovrea@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
> tovrea@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:
>
> tovrea@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 `write@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `open@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `pthread_equal@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `close@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `read@SUNW_0.9'
> /net/whistler/auto/users/tovrea/local/sol2/lib/libxerces-c.so: undefined reference to `pthread_self@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