November 2005 - Boost-users - lists.preview.boost.org

program_options library and mingw
by Thomas Porschberg 09 Nov '05

09 Nov '05

Hi, I try to use the program_options library in a cygwin environment by compiling my application with the -mno-cygwin -mwindows compiler flag. This flag should lead to a pure windows application. I have boost libraries version 1.33 installed(via http://cygwin.com/) I link my application against libboost_program_options-gcc-mt-s which is sufficient under Linux. However under cygwin I get an undefined reference to `_environ' linker error. I did nm /usr/lib/libc.a | grep _environ and got 00000004 B _environ 00000000 I __imp____cygwin_environ 00000000 I __nm____cygwin_environ (but my build environment[GNU Builds tools] seems to ignore the -lc flag at the linker option line) Has someone experience with this library under cygwin/mingw ? Thomas --

1 0

[BGL] adjacency_list with hash_setS: bug ?
by Johan Oudinet 09 Nov '05

09 Nov '05

Is there any example using an adjacency_list with hash_setS for EdgeList ? I think there is a mistake in adjacency_list.hpp:21: // ====================== #if !defined BOOST_NO_HASH #include <hash_set> // instead of <ext/hash_set> ? #endif // ====================== I'm using gcc 4.0.2 with boost 1.33.0 and I can't compile a simple example using adjacency_list with hash_setS: // ====================== # if defined __cplusplus # if defined __GNUC__ && __GNUC__ >= 3 # include <ext/hash_set> # include <ext/hash_map> # if __GNUC__ >= 4 || __GNUC_MINOR__ >= 2 namespace std { using ::__gnu_cxx::hash; using ::__gnu_cxx::hash_set; using ::__gnu_cxx::hash_map; } # endif # else # include <hash_set> # include <hash_map> # endif /* defined __GNUC__ and __GNUC__ == 3 */ # endif /* defined __cplusplus */ #define BOOST_HAS_HASH 1 // for boost::hash_setS #include <boost/config.hpp> #include <boost/graph/adjacency_list.hpp> using namespace boost; int main() { typedef adjacency_list<hash_setS, vecS, bidirectionalS> Graph; Graph g; } // ========================== -- Johan

2 2

Re: [Boost-users] boost::python and Python 2.4
by Nat Goodspeed 09 Nov '05

09 Nov '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Noel Yap > Sent: Tuesday, November 08, 2005 9:14 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] boost::python and Python 2.4 > > I see the problem. Since the location of pyconfig.h depends upon > which compiler was used, it's not located in the same directory as the > rest of the Python header files. [Nat] ? Sorry, I don't understand you at all. On my Windows system I installed Python 2.3 into the default directory, c:\Python23. Likewise Python 2.4 is installed in c:\Python24. The only pyconfig.h files on my system are in 'include' subdirectories of those two directories. They don't seem to be in compiler-dependent locations, and those 'include' subdirs ARE where 300+ other Python header files live. It's worth noting that we build the Boost libraries we use as MSVC 7.1 projects. Those projects (and others) look for a PYTHONDIR environment variable whose value used to be c:\Python23 and is now c:\Python24. > I've tried passing a ':'-separated path as PYTHON_INCLUDES, but that > doesn't work. Anyone have any thoughts on this? I suppose I /could/ > hack around this by using symlinks, but I'd rather find a less hacky > solution. [Nat] So, maybe the reason I don't understand the problem you're having is because you're on a different system with a different compiler.

2 2

[BGL] a.k.a. [Graph] -- bundled properties not compiling for me under MS Dev
by Goldman, Jon 08 Nov '05

08 Nov '05

Hello, I am using Microsoft Development Environment 2002. I am trying to compile a Graph and use bundled properties. The error I am getting: \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2676: binary '[' : 'SimpleGraph' does not define this operator or a conversion to a type acceptable to the predefined operator \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2228: left of '.i' must have class/struct/union type The code snippet below exhibits the problem: struct nodeProp { int i; }; struct edgeProp { int i; }; typedef adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, nodeProp, edgeProp> SimpleGraph; void someFunc() { SimpleGraph someGraph(3); Graph::vertex_descriptor v = *vertices(someGraph).first; someGraph[v].i = 7; // This line is where the error is occuring } Anybody familiar with this problem? Thanks for looking this over, -Jon

2 1

What is the way to sort graph vertices?
by Slava 08 Nov '05

08 Nov '05

Hi, I need to find Maxumum Common Subgraph (between two graphs). For that task i need to get all the vertices of the 2 graphs sorted with some property (like vertex label or id). regular std::sort seems not working with vertex iterators (vertices(graph)). What is the way to accomplish this? Thanks

2 1

Re: [Boost-users] [Boost][serialization] Serialization and DLLs
by Topi Mäenpää 08 Nov '05

08 Nov '05

>>> Could this be related to the fact that the low-level type_info pointer >>> for the classes is different in the dll and the exe? > > That sounds like it could explain this. > > >>> (This is also the >>> reason why dynamic_cast doesn't work across dynamic library >>> boundaries.) > > I've never heard of this before. If this is true it would be key indicator > that > something's wrong. Is this a known MSVC bug? That would be very > interesting to know. I'm not a pro on this matter, but at least gcc (and its Windows version, mingw) have similar "feature". I still need to double-check if I have forgotten to include rtti support somewhere, but I have seen a couple of different my::dynamic_cast implementations that try to work around this. The most well known one might be Qt:s qobject_cast. As far as I know, compilers use pointer equivalence to compare type_infos. It seems that the type_info pointer isn't exported from dynamically loaded modules, which makes dynamic type casting (and also certain exceptions) impossible across dll boundaries. I don't know the reason, but I have verified this with three different compilers, on Linux and Windows. > Is it possible to use the non-rtti versions with MSVC > >>> 7.1? > > > I have implemented non-rtti version which is documented and tested - > test_non_rtti. > The test verifies that types which are identified with different runtime > typing systems > can inter-operate. The library includes extended_type_info_no_rtti.cpp (a > mis-nomer > I see now). This runtime typing system uses the BOOST_CLASS_EXPORT key > as the type identifier. So to use this you'll have to fix the > "type_info_implementation" > trait for this type and besure its exported. This hasn't really been used > except in the > testing (as far as I know). As far as using it a derived class defined in a > DLL where > the base class is in some other library? Too bad I found the reason this late. You already had the feature there! > I reviewed the relevant code and have verified that the serialization system > presumes > that type_info returns the same value regardless of whether the type is > implemented > within a an executable, standard library or dll. I can't imagine why it > would be any > other way. I also don't have any other reports of this. Of course, this is > not > a common usage so that probably doesn't mean much. Double check that that > there aren't any differences in things like _cdecl etc. Maybe that might > explain > why the run-time type signatures vary depending up where the type is > implemented. > > I've started written my own test of this situation but its kind of hung up > in some > in trying to get it worked into bjam. So I haven't finished it. > > I'll do what I can. Thanks for a thorough inspection of the matter. I finally managed to work out a temporary hack that does the thing. Here is how: Change tkmap/ktmap multisets to sets. Modify extended_type_info so that it always compares keys literally. Re-export base classes from wherever subclasses are exported. This ensures that the correct key is recorded to extended_type_info even though there are multiple distinct instances. The downside is that one now always needs a key, but I'm assuming it is the only possible way of dealing with shared libs anyway. Phew! I like the design of the library and the ease of use a lot. Good luck this is (at least partially) resolved now, because it would have been a show stopper to me. I hope my findings have some use in developing an even better version of it :) Best regards, Topi (not so frustrated any more, I'm gonna meet the deadline ;)

1 0

Pyste question--how to exclude a constructor?
by Drumheller, Michael 08 Nov '05

08 Nov '05

I would like to be able to exclude a constructor. My situation is precisely analogous to this: http://mail.python.org/pipermail/c++-sig/2004-March/006952.html But the above thread did not seem to terminate with a solution. Does anyone know how to do this? Thanks, MD

1 0

Re: [Boost-users] [Boost][serialization] Serialization and DLLs
by Topi Mäenpää 08 Nov '05

08 Nov '05

> I have a suggestion, please comment. The problem _could_ be in that >> guid_initializer isn't exported. If I register my base class in a >> DLL, the DLL interface does not expose the >> guid_initializer::instance I have created. Since my exe now doesn't >> know about it, it creates a new definition. The same applies to >> other DLLs. (This would also explain why the same code works on >> Linux: all symbols are automatically exported.) What if we exposed >> the guid_initializer struct to the DLL interface? Would it help? At >> least it shouldn't do any harm to export it from the exe. > That might explain the behavior. We'll look into it. I'm having > problems making test which uses a dynamically loaded DLL that I can > run under bjam. No, it didn't work... I also exported the extended_type_info subclasses (_0 and _1) from my DLL, but I still encounter the same problems. The code lacks comments, and I find it difficult to study some some of the constructs. It seems that whenever I register a class, its superclasses get registered as well. The extended_type_info pointer for my common superclase is however different for each instantiation. The exe crashes due to an unhandled unregistered_cast exception thrown at oserializer.hpp:408. Thus, it seems that downcasting cannot succeed. I even modified the extended_type_info so that it always compares keys literally instead of pointers, but this has no effect. Furthermore, I changed the tkmap and ktmap multisets to sets. I assumed this could prevent multiple registrations, but it does not. Could someone point me out a way to work around this? Any temporary solution will do until the problem has been identified and fixed. Best regards, Topi

2 3

Re: [Boost-users] linker problem with regex library - resolved
by Oliver.Kowalke＠infineon.com 08 Nov '05

08 Nov '05

Hello, I could get the boost libraries linked against my application if I compile the boost libraries with -fpic (bjam "-sBUILD=release debug <cxxflags>-fpic" "-sTOOLS=gcc" install). I think you should use -fpic as default parameter in the boost build for gcc on (at least) HP/UX PA RISC 11.11. The -fPIC choice always works, but may produce larger code than -fpic. Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works. @John: would this be possible? With regards, Oliver >> I get the linker error (see below) if I try to compile my test app. >> What is the problem? >> >> /usr/ccs/bin/ld: Invalid loader fixup in text space needed in output >> file for symbol "__gxx_personality_sj0" in input file >> "/opt/boost/lib/libboost_regex-gcc. > >No idea, I did a quick google for this error message and it seems to be a >common error when people are building shared libraries, but with one of the >components not built with -fPIC. So for example if you tried to link a >static regex build into a shared lib. Does this sound familiar? > >John. > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] boost::python and Python 2.4
by Nat Goodspeed 07 Nov '05

07 Nov '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Noel Yap > Sent: Monday, November 07, 2005 3:47 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] boost::python and Python 2.4 > > Is there any work being done to get boost::python to work with Python > 2.4? Does anyone see any reasons it won't work (assuming the build is > able to work)? [Nat] I hope nobody sees any reasons it wouldn't work: we're using Python 2.4 now. But we're also using Boost 1.31. I tried to convert to 1.32 a couple months ago and ran into failures I didn't understand with other parts of Boost. I haven't yet charged with lowered spear at 1.33.

2 1