- Boost-users - lists.boost.org

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

[Wave] extracting preprocessing grammar and comments from sourcefile
by Andreas Sæbjørnsen 07 Nov '05

07 Nov '05

After looking at the documentation of Wave I believe it can be used to extract the preprocessor grammar and I am therefore looking for some tips on how to get started on my problem. I want to adapt wave into a mechanism for exptracting all preprocessor grammar from a source file without modifying the library itself, and I will try to explain what I want to use wave for. What I want to do is to *extracting the position and value of preprocessor tokens like #ifdef's, #defines, #warning etc. *evaluate the preprocessor conditionals *after evaluating the preprocessor conditional, extract the portion which was evaluated as false as a string #define positive #ifdef int positive #endif /*Extract this false part as string*/ int x; #endif *I am also interested in the value and position of unexpanded macros *extracting the C/C++ statement or expression that the unexpanded macro (and expanded) is a part of. *extract the value and position of all C and C++ comments Which work should I bace my work upon and which data structures should I reimplement and for what? I have looked at the documentation and the code, and it seems easy to do some parts but other are not obvious to me at this point. Thanks, Andreas Saebjoernsen

2 9

LNK2019: unresolved external symbol
by Hiba Tabbara 07 Nov '05

07 Nov '05

1 0

Compile problem with shared_ptr on unusual platform
by Allen Gooch 07 Nov '05

07 Nov '05

I'm trying to use shared_ptr<> from boost 1.33.0 on the Metrowerks CodeWarrior for PSP 1.2 (that's Playstation Portable) and am running into a problem, which I believe may be related to the boost config system and it not being prepared for my admittedly unusual toolchain. I have successfully used this on many other platforms in the past, and have thoroughly enjoyed the boost in productivity and safety through its use. Here's my problem, a simple "hello world" app using boost::shared_ptr< std::string > using the top-level <boost/shared_ptr.hpp> include yields the following link error: Link Error : Undefined : "boost::throw_exception(const std::exception&)" Referenced from "boost::detail::shared_count::!<std::basic_string<char, std::char_traits<char>, std::allocator<char>>>(std::basic_string<char, std::char_traits<char>, std::allocator<char>>*)" in main.cpp Link failed. Any insight into this problem, or the configuration system and how I might adapt it to this compiler, are greatly appreciated. -allen

4 3

Missing Files in Boost 1.33.0 Download
by Merrill Cornish 07 Nov '05

07 Nov '05

Bug? As nearly as I can tell, boost_1_33_0/doc/html/thread created by running the boost_1_33_0.exe download is supposed to contain the same files as http://www.boost.org/doc/html/thread.html, which you get to from libraries | documentation on the home page. However, in my download (and for 1.32.0 also) there are only the acknowledgements, build, and configuration HTML files. Could someone check to see if the other files are being dropped in the download packaging step? Merrill

1 0

Problem with dll and BOOST_STATIC_ASSERT
by Frank 07 Nov '05

07 Nov '05

I have the following code ( very simplified but compilable) // =========== start snip =============================== /// ======= in hpp ============ #include <boost/static_assert.hpp> template <typename T, unsigned short DIM=3> class Vector { public: Vector(void) {/*init code omitted*/} Vector(const Vector& v) {/* ctor code omitted */} //===================================================== // some ctors for small DIM's // will cause compile time errors if DIM != # of args //===================================================== #ifdef enable_small_dim_ctor explicit Vector( T x ) { BOOST_STATIC_ASSERT(DIM==1); data_[0]=x; } Vector( T x, T y ) { BOOST_STATIC_ASSERT(DIM==2); data_[0]=x; data_[1]=y; } Vector( T x, T y, T z ) { BOOST_STATIC_ASSERT(DIM==3); data_[0]=x; data_[1]=y; data_[2]=z; } #endif private: T data_[DIM]; }; template <typename T> class Vector3 : public Vector<T,3> { public: Vector3(){}; Vector3 Normal() const; }; //==================== in cpp ================= // provide implementation of Normal template <typename T> Vector3<T> Vector3<T>::Normal() const { Vector3 n; return n; } // explicit instantiation of the normal method #ifdef try_export // causes error STATIC_ASSERTION_FAILURE template class __declspec(dllexport) Vector3<double> Vector3<double>::Normal() const; #else //OK template class Vector3<double> Vector3<double>::Normal() const; #endif // ============== end snip =============================== I 'm trying to put the implementation into a dll and mark the explicit instantiation of Normal as exported with the following results: 1) With the small_dim_ctor's enabled I get the static assertion when marked for export 2) With the small_dim_ctor's enabled everything is ok when not marked for export 3) With the small_dim_ctor's disabled everything is ok regardless of export marking 4) If I comment out the BOOST_STATIC_ASSERT and build my app with export enabled I can use the resulting dll without any problems I'm thinking that marking for export is somewhow generating an implicit conversion somewhere but I don't know how. Using VStudio .Net 2003. Any help is appreciated. Thanks Frank

3 8

[iostreams] problem with gzip_compressor
by Tiago de Paula Peixoto 07 Nov '05

07 Nov '05

Hello. I've been experiencing the following problem with the gzip_compressor filter: It always writes data down the stream, regardless if any data has been written to the filtering_stream. Consider the following program: -------------------------------------------------------- #include <iostream> #include <fstream> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/gzip.hpp> using namespace std; using namespace boost; int main() { ofstream file; file.open("hello.gz", ios_base::out | ios_base::app | ios_base::binary); iostreams::filtering_stream<boost::iostreams::output> stream; stream.push(iostreams::gzip_compressor()); stream.push(file); return 0; } -------------------------------------------------------- If compiled as "test", the following behavior is observed: $ ./test; ls -l hello.gz -rw-r--r-- 1 count0 users 8 2005-10-30 19:51 hello.gz $ ./test; ls -l hello.gz -rw-r--r-- 1 count0 users 16 2005-10-30 19:51 hello.gz $ ./test; ls -l hello.gz -rw-r--r-- 1 count0 users 24 2005-10-30 19:51 hello.gz That is, it always adds 8 bytes to the file, despite the fact that nothing was written to the stream. To top things off, the data inside the file isn't even recognizable by gzip: $ gunzip hello.gz gunzip: hello.gz: not in gzip format When bzip2_compressor is used, this strange behavior doesn't happen, and the file remains with 0 bytes. I guess this is a bug, right? I'm using boost 1.33.0 with GCC 4.0.1 in a GNU/Linux system. Thanks for any help. -- Tiago de Paula Peixoto <tiago(a)forked.de>

2 6

linker problem with regex library
by Oliver.Kowalke＠infineon.com 07 Nov '05

07 Nov '05

Hello, 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. Best regards, Oliver

2 1