[serialization] linking
I am using bjam with Boost Build v2 to compile and link an executable that calls the boost serialization library using MSVC++ 8.0. For some reason, it tries to link to a library named "libboost..." but the actual library is called "boost...." (no "lib" prefix). Why is this happening and how do I fix it? It doesn't happen when I compile the same executable in Linux.
Deane Yang wrote:
I am using bjam with Boost Build v2 to compile and link an executable that calls the boost serialization library using MSVC++ 8.0. For some reason, it tries to link to a library named "libboost..." but the actual library is called "boost...." (no "lib" prefix).
What's "actual library"? The library file that is eventually produced by the compiler? Then it's a bug in compiler Or the library name as specified in Jamfile? Then note that the "lib" prefix is automatically added for all libraries on Linux, and for static libraries on Windows. Or the library you already have built? Then how did you built it and how do you link to it, and what's your Jamfile, and what's your command line, and what version of Boost and what version of Boost.Build and of Boost.Jam? - Volodya
Volodya, Thanks for responding! When I run bjam (using Boost Build v2) to compile an executable that uses the serialization library, it appears to look for either the wrong version of the library or the right library in the wrong directory. Here's what I see: I've tried to set up my projects to always use the default settings. So I do not have any explicit setting of either the <link> or <runtime-link> flags anywhere. So all of object files get compiled in the directory bin/msvc-8.0express/debug/threading-multi I am therefore guessing that bjam then looks unsuccessfully for a statically linked serialization library in $(BOOST_ROOT)/bin.v2/msvc-8.0express/debug/threading-multi That directory contains only a dynamically linked version (so the name does not have the prefix "lib"). Of course, the directory $(BOOST_ROOT)/bin.v2/msvc-8.0express/debug/link-static/threading-multi seems to have the desired library. I'm not sure what's going on.
Deane Yang wrote:
Volodya,
Thanks for responding!
When I run bjam (using Boost Build v2) to compile an executable that uses the serialization library, it appears to look for either the wrong version of the library or the right library in the wrong directory.
Here's what I see: I've tried to set up my projects to always use the default settings. So I do not have any explicit setting of either the <link> or <runtime-link> flags anywhere. So all of object files get compiled in the directory
bin/msvc-8.0express/debug/threading-multi
I am therefore guessing that bjam then looks unsuccessfully for a statically linked serialization library in
$(BOOST_ROOT)/bin.v2/msvc-8.0express/debug/threading-multi
That directory contains only a dynamically linked version (so the name does not have the prefix "lib").
Of course, the directory
$(BOOST_ROOT)/bin.v2/msvc-8.0express/debug/link-static/threading-multi
seems to have the desired library.
I'm not sure what's going on.
Let's try again. In the last email I've asked some questions, quoting: Or the library you already have built? Then how did you built it and how do you link to it, and what's your Jamfile, and what's your command line, and what version of Boost and what version of Boost.Build and of Boost.Jam? I'd need the following information to have any chance to diagnose the problem: 1. You havent't told what's in your Jamfile -- ideal would be an archive containing a minimal project. 2. You haven't told how you've built the serialization library. 3. Version of Boost/Boost.Build/Boost.Jam is a mistery to me still. I can *assume* it's RC 1_34_0, but there still people using 1-year-old Boost.Build releases. 4. You did not say what command line was. 5. You did not say what *error* you've got. 6. I also want to see the content of your user-config.jam. - Volodya
Vladimir Prus wrote:
Deane Yang wrote:
Volodya,
Thanks for responding!
When I run bjam (using Boost Build v2) to compile an executable that uses the serialization library, it appears to look for either the wrong version of the library or the right library in the wrong directory.
Here's what I see: I've tried to set up my projects to always use the default settings. So I do not have any explicit setting of either the <link> or <runtime-link> flags anywhere. So all of object files get compiled in the directory
bin/msvc-8.0express/debug/threading-multi
I am therefore guessing that bjam then looks unsuccessfully for a statically linked serialization library in
$(BOOST_ROOT)/bin.v2/msvc-8.0express/debug/threading-multi
That directory contains only a dynamically linked version (so the name does not have the prefix "lib").
Of course, the directory
$(BOOST_ROOT)/bin.v2/msvc-8.0express/debug/link-static/threading-multi
seems to have the desired library.
I'm not sure what's going on.
Let's try again. In the last email I've asked some questions, quoting:
Or the library you already have built? Then how did you built it and how do you link to it, and what's your Jamfile, and what's your command line, and what version of Boost and what version of Boost.Build and of Boost.Jam?
I built the boost serialization libraries by going into the boost directory and doing bjam --v2 serialization In a Jamroot file higher up, I have project : requirements <threading>multi ; In my Jamfile I have something like: exe myprogram : myprogram.cpp ../../vendor/boost//serialization ; I call it by just doing "bjam". I am using whatever I got using cvs, as described in the "Getting Started" page of www.boost.org. I did this within the last week.
I'd need the following information to have any chance to diagnose the problem:
1. You havent't told what's in your Jamfile -- ideal would be an archive containing a minimal project.
I'll try to do that
2. You haven't told how you've built the serialization library.
See above
3. Version of Boost/Boost.Build/Boost.Jam is a mistery to me still. I can *assume* it's RC 1_34_0, but there still people using 1-year-old Boost.Build releases.
See above
4. You did not say what command line was.
See above
5. You did not say what *error* you've got.
The linking of my executable failed, because the serialization library was not found. Unfortunately, I can't reproduce the exact error message right now. I would note that if I insert something like "<runtime-link>static" into the project, then everything works OK.
6. I also want to see the content of your user-config.jam.
using msvc : all ;
- Volodya
Hi,
I'm trying to serialize an object of class X that has a member
boost::weak_ptr< X >. The weak pointer may as well be empty and the
object is still in valid state - at least in this context. The
serialization code, however, tries to make a shared_ptr out of the
weak_ptr, which throws a bad_weak_ptr when the weak_ptr is empty. Should
the weak_ptr be checked for expired() before trying to make a shared_ptr
of it?
Using boost 1.33.1 on Fedora Core 6, gcc 4.1.1, glibc 2.5, though the
platform should not matter here.
An example code demonstrating the problem follows:
#include <iostream>
#include <fstream>
#include
Mikko Vainio wrote:
Hi,
I'm trying to serialize an object of class X that has a member boost::weak_ptr< X >. The weak pointer may as well be empty and the object is still in valid state - at least in this context. The serialization code, however, tries to make a shared_ptr out of the weak_ptr, which throws a bad_weak_ptr when the weak_ptr is empty. Should the weak_ptr be checked for expired() before trying to make a shared_ptr of it?
The line const boost::shared_ptr<T> sp(t); should be const boost::shared_ptr<T> sp = t.lock();
Very good. I'll make this tweak and check it in. Robert Ramey Peter Dimov wrote:
Mikko Vainio wrote:
Hi,
I'm trying to serialize an object of class X that has a member boost::weak_ptr< X >. The weak pointer may as well be empty and the object is still in valid state - at least in this context. The serialization code, however, tries to make a shared_ptr out of the weak_ptr, which throws a bad_weak_ptr when the weak_ptr is empty. Should the weak_ptr be checked for expired() before trying to make a shared_ptr of it?
The line
const boost::shared_ptr<T> sp(t);
should be
const boost::shared_ptr<T> sp = t.lock();
But now that I look at this, I'm wondering: Will t.lock() succeed if t is in an an "expired" state? Robert Ramey Robert Ramey wrote:
Very good. I'll make this tweak and check it in.
Robert Ramey
Peter Dimov wrote:
Mikko Vainio wrote:
Hi,
I'm trying to serialize an object of class X that has a member boost::weak_ptr< X >. The weak pointer may as well be empty and the object is still in valid state - at least in this context. The serialization code, however, tries to make a shared_ptr out of the weak_ptr, which throws a bad_weak_ptr when the weak_ptr is empty. Should the weak_ptr be checked for expired() before trying to make a shared_ptr of it?
The line
const boost::shared_ptr<T> sp(t);
should be
const boost::shared_ptr<T> sp = t.lock();
Its clear you've looked at the implementation of serialization for shared_ptr. What would I have to do to convince you to take over testing and maintainence of it? Its no a huge job - now that I have it factored they way I want in the HEAD. But I'm sure you could do a better job on this than I can. Robert Ramey Peter Dimov wrote:
Robert Ramey wrote:
But now that I look at this, I'm wondering:
Will t.lock() succeed if t is in an an "expired" state?
Yes, it returns an empty shared_ptr when t is expired.
participants (5)
-
Deane Yang -
Mikko Vainio -
Peter Dimov -
Robert Ramey -
Vladimir Prus