xml-cppdom-devel

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

[Kevin G. <go...@gm...>]

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 -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(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 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.
-----

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

Thanks!

--Kevin Godby

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/

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

[Kevin G. <go...@gm...>]

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 -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(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...

I re-ran scons as 'scons var_arch=ia32' to compile only the 32-bit
version and it succeeded.  (It will be running on a 32-bit system..
but apparently the default is to build all architectures.)

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.

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

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

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).

Thanks again for your help!

--Kevin Godby

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/

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

[Kevin G. <go...@gm...>]

Hello.

> 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 at
> 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.

I'll use the packages that you have available.  As to the version of
VR Juggler, which do you recommend?  Is the 2.1 version relatively
stable?  Have you tried compiling either 2.0.2 or 2.1 on Ubuntu and
does one compile more easily than the other?

Thanks!

--Kevin

[xml-cppdom-devel] VR Juggler on Ubuntu (was Re: Problems compiling xml-cppdom)

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

[I am cc'ing the vrjuggler-info list on this message since it is more abo=
ut
VR Juggler than CppDOM.]

Kevin Godby wrote:
> Hello.
>=20
>> I have packages for CppDOM, GMTL, and flagpoll. I intend to make packa=
ges
>> for VR Juggler, PyGMTL, and PyJuggler, but they are not a high priorit=
y at
>> the moment. They will probably be available before the end of this mon=
th,
>> 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 Autoc=
onf 2.60.
>=20
> I'll use the packages that you have available.  As to the version of
> VR Juggler, which do you recommend?  Is the 2.1 version relatively
> stable?

Yes. We're preparing for the 2.2 release, so it is pretty stable at this
point. Beyond that, it has been used as the basis for some large projects=

that we have done.

> Have you tried compiling either 2.0.2 or 2.1 on Ubuntu and
> does one compile more easily than the other?

I have built 2.1 (with all features enabled), but I haven't tried 2.0.2 y=
et.
It would be a quick thing for me to try, but it will have to wait until M=
onday.

 -Patrick


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