[version 1.38.0] Problems with dynamic linking to boost libraries
Hello, I'm using boost libraries in my research work and I need to link to graph and program options libraries. I've been working with version 1.37.0 without any problem. Now I updated to 1.38.0. I built the libraries in the same way and the same directories as 1.37.0 (on /usr/local). The compilation and dynamic linkage phase work, but when I run the program it complains with "file not found" on the shared library files. I've tried it in my home Fedora 10 installation and the Debian installation at my workplace and I have the same problem. For the moment, the only workaround I've found is explicitly linking the static versions of both libraries, while still dynamically linking to other libraries (like expat). Is there any problem in the installation phase of "./configure ; make install"? What can I do? Thanks in advance.
Juan Antonio Farré Basurte wrote:
Hello, I'm using boost libraries in my research work and I need to link to graph and program options libraries. I've been working with version 1.37.0 without any problem. Now I updated to 1.38.0. I built the libraries in the same way and the same directories as 1.37.0 (on /usr/local). The compilation and dynamic linkage phase work, but when I run the program it complains with "file not found" on the shared library files.
You need to always provide the exact error message. Also, what does ldd say? Did you recompile your program? - Volodya
Juan Antonio Farré Basurte wrote:
Hello, I'm using boost libraries in my research work and I need to
libraries. I've been working with version 1.37.0 without any problem.
Now I updated to 1.38.0. I built the libraries in the same way and the same directories as 1.37.0
(on /usr/local). The compilation and dynamic linkage phase work, but when I run the program it complains with "file not found" on the shared
I've added /usr/local/lib to /etc/ld.so.conf and now it works. What I don't understand is why the linker didn't complain (the problem was when executing), and why it worked before with 1.37.0. Thanks a lot anyway, Juan link to graph and program options library files.
You need to always provide the exact error message. Also, what does ldd say? Did you recompile your
program?
- Volodya
_______________________________________________ Boost-users
mailing list
Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I've added /usr/local/lib to /etc/ld.so.conf and now it works. What I don't understand is why the linker didn't complain (the problem was when executing),
That's actually the way dynamic linking works under UNIX: You tell the linker which libraries to link with, but aren't tied to this library location when you deploy the program (e.g. on a different computer). Hence you use the -L directive to tell gcc/ld where to look for libraries (shared or static), and have to edit ld.so.conf to tell the dynamic linker (the program which looks through all referenced dynamic libraries for symbols when you start your executable) where to look for libraries when running executables. Note, that you don't have to edit ld.so.conf: you could instead set the variable LD_LIBRARY_PATH to the library location (works like the PATH environment variable, so you can provide multiple paths separated by colons). This way you can accomplish your task without super user privileges. Note, that the variable is called DYLD_LIBRARY_PATH on Mac OSX systems.
I've added /usr/local/lib to /etc/ld.so.conf and now it works. What I don't understand is why the linker didn't complain (the problem was when executing),
That's actually the way dynamic linking works under UNIX: You tell the linker which libraries to link with, but aren't tied to this library location when you deploy the program (e.g. on a different computer). Hence you use
-L directive to tell gcc/ld where to look for libraries (shared or static), and have to edit ld.so.conf to tell
which looks through all referenced dynamic libraries for symbols when you start your executable) where to look for libraries when running executables.
Note, that you don't have to edit ld.so.conf: you could instead set the variable LD_LIBRARY_PATH to the library location (works like the PATH environment variable, so you can
Thanks a lot for all this detailed and useful information :) Regards, Juan the the dynamic linker (the program provide multiple paths
separated by colons). This way you can accomplish your task without super user privileges. Note, that the variable is called DYLD_LIBRARY_PATH on Mac OSX systems. _______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hello, I'm working in a graph algorithm that works on graphs that implement BidirectionalGraphConcept and VertexAndEdgeListGraphConcept. The only additional requirement is that they must have some concrete bundled properties (I don't want to deal with the, I understand old, method of defining properties). For example, if g is a graph and v is a valid vertex descriptor of that graph, g[v].min must be a valid boolean expression. I have defined template classes for those bundled properties, but I wish not to impose using those concrete classes. To do so, I never get g[v] in a variable to later access the properties. For example, I always write g[v].min instead of something like BundledVertexPropertyType &p=g[v]; p.min Ok, for the moment. The problem is that, at some point of my algorithm (concretely when wanting to invoke the topological_sort BGL algorithm) I must have knowledge of what's the concrete type of the bundled properties (i.e., I need to know that BundledVertexPropertyType written before). I can't find in BGL documentation a way to do that. I look, for example, for something like, imagine, graph_traits<Graph>::bundled_vertex_properties_type Is there a documented way to achieve that? If not, is there any way how I can get a property map to provide access to a bundled property without knowing the bundled-property type? Right now I'm using an expression like the following one: get(&BundledVertexPropertyType::index,g) But this obviously requires knowing the BundledVertexPropertyType when writing the code. Is there any way to avoid it? Thanks a lot, Juan
I'm working in a graph algorithm that works on graphs that implement BidirectionalGraphConcept and VertexAndEdgeListGraphConcept. The only additional requirement is that they must have some concrete bundled properties (I don't want to deal with the, I understand old, method of defining properties). For example, if g is a graph and v is a valid vertex descriptor of that graph,
This is a really good question because it deals with application-specific graph concepts. These aren't really addressed anywhere in the library. Since your algorithm is generic, you should be thinking about how to "generically" get the properties of the graph. You can do this by abstracting the property reference as a function call. Instead of, g[v].min, you should be writing: vertex_min(g). Or whatever 'min' actually means in this case. What you're doing is effectively defining application-specific semantics for a graph (that vertices have a min property). In order for a graph to model that property, you just have to provide an overload specific to your graph type. Andrew Sutton andrew.n.sutton@gmail.com
Thanks, Andrew :) That's a good possible solution, if I want a totally-generic algorithm. I was considering doing something simmilar at design time, but finally my design decission was not to be "so" generic and impose the use of bundled properties. I give default struct templates for those bundled properties, but I don't want to impose using that default implementation. So, for a graph accomplishing my preconditions, it should always be possible to use the expression g[v].min, but if I use the expression g[v] I don't know the type of the object it returns. If there isn't any way to find out that, I'll have no other option than choosing between your totally-generic solution or to be still more restrictive and impose using my default implementation of the bundled properties the graph must have. I don't know if I'm being able to say correctly what I mean (English isn't my native language). Cheers, Juan
Since your algorithm is generic, you should be thinking about how to "generically" get the properties of the graph. You can do this by abstracting the property reference as a function call. Instead of, g[v].min, you should be writing: vertex_min(g). Or whatever 'min' actually means in this case.
What you're doing is effectively defining application-specific semantics for a graph (that vertices have a min property). In order for a graph to model that property, you just have to provide an overload specific to your graph type.
Andrew Sutton andrew.n.sutton@gmail.com
_______________________________________________
Boost-users mailing list Boost-users@lists.boost.org
it should always be possible to use the expression g[v].min, but if I use the expression g[v] I don't know the type of the object it returns. If there isn't any way to find out that, I'll have no other option than choosing between your totally-generic solution or to be still more restrictive and impose using my default implementation of the bundled properties the graph must have.
I don't believe that there's a reliable way to access bundled property types. You can probably use the vertex_property_type and one metafunction or another to extract the bundled types, but I don't know the exact process for this. This only applies to graphs that actually define that type, though. Expecting a function isn't really "totally generic". It just hides the differences that are causing your problem. andrew.n.sutton@gmail.com
Hi, I need to use the topological_sort BGL algorithm. This algorithm needs either that the graph has an internal vertex index property or that you provide a property map for it. I'd like to perform conditional compilation, so that I only build and provide the vertex index property map when it's needed, and the internal index property of the graph when it has it. For example, for an adjacency_list with vecS for VertexList, the property already exists in the graph and I wouldn't like to provide a property map for it. But if I choose listS for VertexList, there isn't such internal property and I need to provide the property map. As I don't know what Graph implementation my template will be provided, I need to find a way to know at compile time if that graph has the internal index property or not. Is there any (documented?) way to do it? This is the concrete information I need right now, but, if possible, I'd like to know how to find out if the graph has any concrete internal property, and not only the index one. Thanks, Juan
I need to use the topological_sort BGL algorithm. This algorithm needs either that the graph has an internal vertex index property or that you provide a property map for it. I'd like to perform conditional compilation, so that I only build and provide the vertex index property map when it's needed, and the internal index property of the graph when it has it. For example, for an adjacency_list with vecS for VertexList, the property already exists in the graph and I wouldn't like to provide a property map for it. But if I choose listS for VertexList, there isn't such internal property and I need to provide the property map. As I don't know what Graph implementation my template will be provided, I need to find a way to know at compile time if that graph has the internal index property or not. Is there any (documented?) way to do it? This is the concrete information I need right now, but, if possible, I'd like to know how to find out if the graph has any concrete internal property, and not only the index one.
I don't think that this is really documented anywhere... You might look at pending/property.hpp - there are number of metafunctions there that might be useful. Specifically, I think you'd be looking at property_value, which appears to extract a property from a property list. This may "return" no_property if the requested kind is not supported. Andrew Sutton andrew.n.sutton@gmail.com
I need to find a way to know at compile time if that graph has the internal index property or not. Is there any (documented?) way to do it? This is the concrete information I need right now, but, if possible, I'd like to know how to find out if the graph has any concrete internal property, and not only the index one.
I don't think
that this is really documented anywhere... You might look at
pending/property.hpp - there are number of metafunctions there that might be useful. Specifically, I think you'd be looking at property_value, which appears to extract a property from a property list. This may "return" no_property if the requested kind is not supported.
Andrew Sutton
Thanks a lot for the hint, Andrew. It's a pity there isn't a documented way. I consider it a useful feature. Juan
I need to use the topological_sort BGL algorithm. This algorithm needs either that the graph has an internal
vertex index
property or that you provide a property map for it. I'd like to perform conditional compilation, so that I only build and provide the vertex index property map when it's needed, and the internal index property of the graph when it has it. For example, for an adjacency_list with vecS for VertexList, the property already exists in the graph and I wouldn't like to provide a property map for it. But if I choose listS for VertexList, there isn't such internal
and I need to provide the property map. As I don't know what Graph implementation my template will be
property provided,
I need to find a way to know at compile time if that graph has the internal index property or not. Is there any (documented?) way to do it? This is the concrete information I need right now, but, if possible,
I'd like to know how to find out if the graph has any concrete internal
property, and not only the index one.
I don't think that this is really documented anywhere... You might look at pending/property.hpp - there are number of
useful. Specifically, I think you'd be looking at property_value, which appears to extract a
metafunctions there that might be property from a property list. This may "return"
no_property if the requested kind is not supported.
What about runtime detection? Would get(property_tag,graph) compile correctly for an unexistant property? What would it return, then, at runtime if the property does not exist? a 0 pointer? Thanks, Juan
What about runtime detection? Would get(property_tag,graph) compile correctly for an unexistant property? What would it return, then, at runtime if the property does not exist? a 0 pointer?
Unfortunately, I don't think such a function actually exists. However, if you can detect these at compile time, you can easily reflect that as a runtime query: template <typename Graph, typename Prop> bool has_property(Graph const& g) { return has_property_metafunc<Prop, Graph>::value; } Andrew Sutton andrew.n.sutton@gmail.com
On Thu, 19 Mar 2009, Andrew Sutton wrote: (snip)
Unfortunately, I don't think such a function actually exists. However, if you can detect these at compile time, you can easily reflect that as a runtime query:
template <typename Graph, typename Prop> bool has_property(Graph const& g) { return has_property_metafunc<Prop, Graph>::value; }
It appears that the value_type of an undefined non-bundled property map is always boost::detail::error_property_not_found, so you can use the following metafunction to detect them: #include <boost/graph/properties.hpp> #include <boost/type_traits.hpp> #include <boost/property_map.hpp> #include <boost/mpl/not.hpp> template <typename Graph, typename PropertyTag> struct graph_has_property: public boost::mpl::not_< boost::is_same< typename boost::property_traits< typename boost::property_map<Graph, PropertyTag>::type >::value_type, boost::detail::error_property_not_found > > {}; This always returns true when given a bundled property, however (it does work for testing for non-bundled properties in graphs that have bundled properties). I have not figured out how to test for bundled properties; there is a compile error when trying to get a particular value from a nonexistent member of a bundled property map. Is that a case that is important to you? There are several Boost graph algorithms that make a decision based on whether a property exists; look for the handling of the color map at the bottom of boost/graph/breadth_first_search.hpp for an example (look at the definition of boost::detail::bfs_dispatch). The code there is a more complicated version of the metafunction above, but can also handle an optionally user-specified color map. -- Jeremiah Willcock
there is a compile error when trying to get a particular value from a nonexistent member of a bundled property map. Is
that a case that is
important to you? There are several Boost graph algorithms that make a
Thanks a lot for your detailed answer :) No, for the moment, that case is not important to me, as, for the moment, the only real need I have is to find out whether a given graph has the internal vertex-index property that, for example, adjacency_list with vecS for vertex list has. Based on this information, I'll directly invoke algorithms that need that property, or I'll build a property_map with assigned indices for vertices and pass it to the algorithm. Right now I always do this last option, but it would save running time, if I could detect when this property already exists, so that I don't have to create the property map, which takes linear time. Cheers, Juan
participants (5)
-
Andrew Sutton -
Jeremiah Willcock -
Juan Antonio Farré Basurte -
Rudolf Leitgeb -
Vladimir Prus