Re: [xml-cppdom-devel] Problems compiling xml-cppdom

[Patrick H. <pa...@13...>]

Kevin Godby wrote:
> Hello.
>=20
> I'm having trouble compiling xml-cppdom (as a prerequisite for
> compiling VR Juggler).
>=20
> When I try to compile svn trunk, I get the following error:
>=20
> -----
> g++ -o build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so -m64
> -shared build.linux/type-debug--arch-x64/cppdom/cppdom.os
> build.linux/type-debug--arch-x64/cppdom/xmlparser.os
> build.linux/type-debug--arch-x64/cppdom/xmltokenizer.os
> build.linux/type-debug--arch-x64/cppdom/ext/OptionRepository.os
> build.linux/type-debug--arch-x64/cppdom/SpiritParser.os -L/usr/lib
> /usr/bin/ld: /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a(functexce=
pt.o):
> relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can
> not be used when making a shared object; recompile with -fPIC
> /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a: could not read
> symbols: Bad value
> collect2: ld returned 1 exit status
> scons: *** [build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so]=
 Error 1
> scons: building terminated because of errors.
> -----

When it builds the object files, is -fPIC used? If not, you could add it =
to
the CFLAGS in the SConstruct ... somewhere. I haven't used the CppDOM tru=
nk,
and its build is surprisingly unfamiliar to me. Perhaps someone else know=
s
where that option could/should be added.

I notice that you're building the Boost Spirit parser for CppDOM. I may b=
e
wrong, but I don't think that you want to do that. IIRC, it ended up bein=
g
slower than CppDOM's current parser. Of course, the Spirit parser is like=
ly
to be much smarter and more robust, so perhaps the author could chime in
here about the best course...

> When I try to compile the released 0.6.6, I get the following error:
>=20
> -----
> g++ -o build.linux-i686/test/suite/runner -m32
> build.linux-i686/test/suite/runner.o
> build.linux-i686/test/suite/TestCases/ErrorTest.o
> build.linux-i686/test/suite/TestCases/NodeTest.o
> build.linux-i686/test/suite/TestCases/ParseTest.o
> build.linux-i686/test/suite/TestCases/PredTest.o
> build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o
> build.linux-i686/test/suite/TestCases/SpiritTest.o -L/usr/lib
> -Lbuild.linux-i686/instlinks/lib -lcppdom -lcppunit -ldl -ldl -ldl
> build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o: In
> function `testHelpers::dump_node(cppdom::Node&, int)':
> test/testHelpers.h:13: multiple definition of
> `testHelpers::dump_node(cppdom::Node&, int)'
> build.linux-i686/test/suite/TestCases/NodeTest.o:test/testHelpers.h:13:=

> first defined here
> collect2: ld returned 1 exit status
> scons: *** [build.linux-i686/test/suite/runner] Error 1
> scons: building terminated because of errors.
> -----

Don't tell the build where to find CppUnit. That way, the test suite will=

not be compiled.

As far as this error goes, I don't know why you would be seeing multiply
defined symbols in this case. The dump_node() function is declared inline=
=2E
Looking at the code, I don't see any reason why it shouldn't be defined i=
n a
=2Ecpp file to get rid of the inline hack.

> I'm using Ubuntu Linux 6.10 (edgy).  Any advice?

I made a 32-bit .deb package for Ubuntu 6.10, but it looks as though you
want 64-bit. If you want a 32-bit build, I can send you the package.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/