Linking problems: graphml.c/hpp

I'm trying to use graphml.cpp/hpp in a project.

When linking the main executable against expat-2.0.0, I get:

Link separator
graphml.o: In function
`graphml_reader::handle_vertex(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)':
graphml.cpp:(.text._ZN14graphml_reader13handle_vertexERKSs[graphml_reader::handle_vertex(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)]+0xf5): undefined
reference to `__cxa_get_exception_ptr'
graphml.o: In function
`graphml_reader::handle_edge(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)':
graphml.cpp:(.text._ZN14graphml_reader11handle_edgeERKSsS1_S1_[graphml_reader::handle_edge(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)]+0x465): undefined reference to
`__cxa_get_exception_ptr'

Anyone knows, what's going wrong here?

Re: Linking problems: graphml.c/hpp

On 12/17/2006 05:49 PM, Jens Müller wrote:
> I'm trying to use graphml.cpp/hpp in a project.
> 
> When linking the main executable against expat-2.0.0, I get:
> 
> Link separator
> graphml.o: In function
> `graphml_reader::handle_vertex(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&)':
> graphml.cpp:(.text._ZN14graphml_reader13handle_vertexERKSs[graphml_reader::handle_vertex(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&)]+0xf5): undefined
> reference to `__cxa_get_exception_ptr'
> graphml.o: In function
> `graphml_reader::handle_edge(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> const&, std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&)':
> graphml.cpp:(.text._ZN14graphml_reader11handle_edgeERKSsS1_S1_[graphml_reader::handle_edge(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> const&, std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&)]+0x465): undefined reference to
> `__cxa_get_exception_ptr'
> 
> Anyone knows, what's going wrong here?

Do you know if expat was compiled with a C++ compiler? Eg. g++ instead
of gcc? It looks like that may be the problem.

Re: Linking problems: graphml.c/hpp

Tiago de Paula Peixoto schrieb:
>> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>> const&, std::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const&)]+0x465): undefined reference to
>> `__cxa_get_exception_ptr'
>>
>> Anyone knows, what's going wrong here?
> 
> Do you know if expat was compiled with a C++ compiler? Eg. g++ instead
> of gcc? It looks like that may be the problem.

Well, I compiled it myself and installed it in my user dir.

CC is gcc, that should be a C compiler ...

But honestly, I don't get it. Why should libexpat provide the symbol
`__cxa_get_exception_ptr' if compiled with a C compiler.

I just looked at libexpat.a with mc - all the names exported look nice
and unmangled. Shouldn't there a name mangling be in place if compiled
as C++?

Re: Linking problems: graphml.c/hpp

On 12/17/2006 08:44 PM, Jens Müller wrote:
> Tiago de Paula Peixoto schrieb:
>>> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>>> const&, std::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const&)]+0x465): undefined reference to
>>> `__cxa_get_exception_ptr'
>>>
>>> Anyone knows, what's going wrong here?
>> Do you know if expat was compiled with a C++ compiler? Eg. g++ instead
>> of gcc? It looks like that may be the problem.
> 
> Well, I compiled it myself and installed it in my user dir.
> 
> CC is gcc, that should be a C compiler ...
> 
> But honestly, I don't get it. Why should libexpat provide the symbol
> `__cxa_get_exception_ptr' if compiled with a C compiler.
> 
> I just looked at libexpat.a with mc - all the names exported look nice
> and unmangled. Shouldn't there a name mangling be in place if compiled
> as C++?

Yes, which means you used gcc to compile it. As far as I know you should
have to compile expat with g++, instead of gcc, so that exceptions can
be thrown from inside the hook functions, and caught outside. Otherwise
the "main loop" from expat doesn't know anything about exceptions, and
they wouldn't come through... This problem manifests itself with missing
symbols during linkage, but honestly I don't know the details. It could
be that "__cxa_get_exception_ptr" is referenced by your program, and the
linker expects it to be defined in the expat library... If you compile

Re: Linking problems: graphml.c/hpp

Tiago de Paula Peixoto schrieb:
> On 12/17/2006 08:44 PM, Jens Müller wrote:
>> Tiago de Paula Peixoto schrieb:
>>>> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>>>> const&, std::basic_string<char, std::char_traits<char>,
>>>> std::allocator<char> > const&)]+0x465): undefined reference to
>>>> `__cxa_get_exception_ptr'
>>>>
>>>> Anyone knows, what's going wrong here?
>>> Do you know if expat was compiled with a C++ compiler? Eg. g++ instead
>>> of gcc? It looks like that may be the problem.
>> Well, I compiled it myself and installed it in my user dir.
>>
>> CC is gcc, that should be a C compiler ...
>>
>> But honestly, I don't get it. Why should libexpat provide the symbol
>> `__cxa_get_exception_ptr' if compiled with a C compiler.
>>
>> I just looked at libexpat.a with mc - all the names exported look nice
>> and unmangled. Shouldn't there a name mangling be in place if compiled
>> as C++?
> 
> Yes, which means you used gcc to compile it. As far as I know you should
> have to compile expat with g++, instead of gcc, so that exceptions can
> be thrown from inside the hook functions, and caught outside. Otherwise
> the "main loop" from expat doesn't know anything about exceptions, and
> they wouldn't come through... This problem manifests itself with missing
> symbols during linkage, but honestly I don't know the details. It could
> be that "__cxa_get_exception_ptr" is referenced by your program, and the
> linker expects it to be defined in the expat library... If you compile

bad_any_cast when reading graphml

I just tried to use your code to read a graphml file. I compile 
graphml.cpp myself and have it linked to my executable.

Boost version is 1.33.1.

My code looks like this:

// system headers
#include <string>
#include <iostream>
#include <fstream>

// Boost graph library, including LEDA wrapper
// #include <boost/graph/leda_graph.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <boost/dynamic_property_map.hpp>

// graph_tool: graphml reader
#include "graphml.hpp"

struct VertexProperties
{
   float x;
   float y;
};

struct EdgeProperties
{
   float length;
};

Re: bad_any_cast when reading graphml

Jens Müller wrote:
> 
> struct VertexProperties
> {
>    float x;
>    float y;
> };
> 
> struct EdgeProperties
> {
>    float length;
> };

My fault - changed this to double, and it worked.

Well, nearly - now it crashes when it reaches the edges:

$ ./separator -f test -i planar100k.graphml
terminate called after throwing an instance of 'boost::property_not_found'
   what():  Property not found: length.
Aborted

Why isn't
   dp.property("length", get(&EdgeProperties::length, g));
sufficient?

property_not_found - confusion between edge and graph property?! (was: bad_any_cast when reading graphml)

Jens Müller wrote:
> Jens Müller wrote:
> 
>>struct VertexProperties
>>{
>>   float x;
>>   float y;
>>};
>>
>>struct EdgeProperties
>>{
>>   float length;
>>};
> 
> 
> My fault - changed this to double, and it worked.
> 
> Well, nearly - now it crashes when it reaches the edges:
> 
> $ ./separator -f test -i planar100k.graphml
> terminate called after throwing an instance of 'boost::property_not_found'
>    what():  Property not found: length.
> Aborted
> 
> 
> Why isn't
>    dp.property("length", get(&EdgeProperties::length, g));
> sufficient?

Program received signal SIGABRT, Aborted.

Re: property_not_found - confusion between edge and graph property?!

On 12/21/2006 12:44 PM, Jens Müller wrote:

> Is it trying to set a graph property instead of an edge property?!
> -> boost::mutate_graph_impl<...>::set_graph_property (#8)

It seems like it is... Could you please send your graphml file attached,
if it's not very big, or a smaller version that shows the same problem?

Thanks.
--

-- 
Tiago de Paula Peixoto <tiago <at> forked.de>

_______________________________________________
graph-tool mailing list
graph-tool <at> forked.de
http://lists.forked.de/mailman/listinfo/graph-tool

Re: property_not_found - confusion between edge and graph property?!

Tiago de Paula Peixoto wrote:
> On 12/21/2006 12:44 PM, Jens Müller wrote:
> 
> 
>>Is it trying to set a graph property instead of an edge property?!
>>-> boost::mutate_graph_impl<...>::set_graph_property (#8)
> 
> 
> It seems like it is... Could you please send your graphml file attached,
> if it's not very big, or a smaller version that shows the same problem?
> 

I just changed the following in the code:

void handle_property(std::string key_id, std::string descriptor,
                          bool is_vertex, std::string value)
     {
         if (false) // (descriptor == "") <-- workaround?!
             m_g.set_graph_property(m_key_name[key_id], value, 
m_key_type[key_id]);
         else if (is_vertex)
             m_g.set_vertex_property(m_key_name[key_id], 
get_vertex_descriptor(descriptor), value, m_key_type[key_id]);
         else
             m_g.set_edge_property(m_key_name[key_id], 
get_edge_descriptor(descriptor), value, m_key_type[key_id]);
     }

(change in line 362 of graphml.cpp)