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

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

Kevin Godby wrote:
> On 1/5/07, Patrick Hartling <pa...@13...> wrote:
>> Kevin Godby wrote:
>> > Hello.
>> >
>> > I'm having trouble compiling xml-cppdom (as a prerequisite for
>> > compiling VR Juggler).
>> >
>> > When I try to compile svn trunk, I get the following error:
>> >
>> > -----
>> > g++ -o build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so -m=
64
>> > -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(functexcept.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
>> trunk,
>> and its build is surprisingly unfamiliar to me. Perhaps someone else
>> knows
>> where that option could/should be added.
>>
>> I notice that you're building the Boost Spirit parser for CppDOM. I
>> may be
>> wrong, but I don't think that you want to do that. IIRC, it ended up
>> being
>> slower than CppDOM's current parser. Of course, the Spirit parser is
>> likely
>> to be much smarter and more robust, so perhaps the author could chime =
in
>> here about the best course...
>=20
> I re-ran scons as 'scons var_arch=3Dia32' to compile only the 32-bit
> version and it succeeded.

I'm glad to hear it. The lack of -fPIC is definitely a bug--either in SCo=
ns
or in the CppDOM build.

> (It will be running on a 32-bit system..
> but apparently the default is to build all architectures.)

For better or for worse, yes, that is the case.

> As to the Spirit parser, that must also be the default (as I didn't
> specify any other options than the architecture to scons).  I've
> attached a log file of the trunk build.

It's probably because you have Boost installed in /usr. The build
auto-detects whether it should try to use the Spirit parser based on whet=
her
Spirit is available. There should probably be an override to prevent that=
=2E

>> > When I try to compile the released 0.6.6, I get the following error:=

>> >
>> > -----
>> > 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 w=
ill
>> not be compiled.
>>
>> As far as this error goes, I don't know why you would be seeing multip=
ly
>> defined symbols in this case. The dump_node() function is declared
>> inline.
>> Looking at the code, I don't see any reason why it shouldn't be
>> defined in a
>> .cpp file to get rid of the inline hack.

I looked into this a little more, and moving dump_node()'s implementation=

into a .cpp file is not as straightforward as I had hoped. :(

> It auto-detected the CppUnit libraries; I didn't tell it where to find
> them.  I've attached a log file of my attempt to build the 0.6.6
> release as well.

I'm not sure what to tell you about this. I haven't tried building 0.6.6
with CppUnit on Ubuntu, and I don't see anything obviously wrong in the c=
ode.

>> > 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 y=
ou
>> want 64-bit. If you want a 32-bit build, I can send you the package.
>=20
> I'm interested in the 32-bit .deb package if it's available.  I'd also
> be interested in any other .deb packages you might have for VR Juggler
> and its dependencies (CPP DOM and GTML, primarily---I think most the
> other prerequisites already have .deb packages in the Ubuntu
> repositories).

I have packages for CppDOM, GMTL, and flagpoll. I intend to make packages=

for VR Juggler, PyGMTL, and PyJuggler, but they are not a high priority a=
t
the moment. They will probably be available before the end of this month,=

though. I put what I have so far here:

   http://www.infiscape.com/~patrick/ubuntu/

BTW, once you get to compiling VR Juggler, you'll want to use the 2.0.2
source (or the latest 2.1 source) as it contains a fix for using Autoconf=
 2.60.

 -Patrick


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