Re: [boost] another way to (not) build the libraries

From: bwlee (bwlee.sky_at_[hidden])
Date: 2006-03-29 08:54:37

Really useful message, not drawn in the sea!

I have a similiar question, maybe just because I set something wrong, now I
compiling some code in vc++ 2005 express, I found a very strange linking
problem, it failed to find the class member unless I put those function
bodies into the header file(just copy & paste or include .cpp file at the
end of the header file).

It seems really stupid, and I wonder why it happens!

I am not sure if it is my own mistake because it is my first time using the
vc++ 2005 express.

I need to use boost and some other odbc libraries for windows applications,
any other solutions?

Thanks in advance!

On 3/29/06, Ulrich Eckhardt <doomster_at_[hidden]> wrote:
>
> Greetings!
>
> I think it was with boost 1.30 where we started using the threads library
> and
> at that time build support was not yet at the stage where we could really
> use
> it the way we wanted it to so we mostly invented our own. The first thing
> we
> did was to copy the required sourcefiles into the project where we needed
> them, i.e. the most primitive form of static linking. Later on, we
> replaced
> that with #including the sourcefiles (<lib/thread/src/...>) into a single
> file - the same thing only done in a way that we could switch to the next
> Boost version without changing our code. Well, at least we thought so,
> some
> files moved between Boost versions inside the source folder, another
> problem
> is that e.g. timeconv.inl provides things in an anonymous namespace and
> gets
> included by more than one sourcefile but doesn't have include guards.
>
> Anyhow, what I wonder is whether this is not a way that should be
> supported
> actively. In our case, it significantly reduced the adoption barrier for
> the
> threading lib, it also makes bjam use unnecessary (which I, even though I
> did
> quite some things with it already, still find unwieldy and don't
> completely
> understand), it avoids the problem of different compiler ABIs due to
> different compiler versions or settings and it reduces the additional
> required size of the final executable (example-prog[1] with above static
> linking weighs 52kB, the thread lib alone would have been 92kB already
> otherwise).
>
> I personally would be interested in documenting how to use Boost libs this
> way
> and also make it an officially supported way to do so.
>
> cheers
>
> Uli
>
>
> [1]: The example program below has been compiled with GCC using Boost 1.33
> ,
> the only patch necessary was to add include guards to timeconv.inl.
>
> #include <iostream>
> #include <ostream>
> #include <boost/thread/thread.hpp>
> #include <boost/thread/xtime.hpp>
>
> // for 'static' linking
> #include <libs/thread/src/thread.cpp>
> #include <libs/thread/src/xtime.cpp>
> #include <libs/thread/src/mutex.cpp>
> #include <libs/thread/src/exceptions.cpp>
> #include <libs/thread/src/condition.cpp>
>
> void thread()
> {
>     std::cout << "thread(): entering\n";
>
>     boost::xtime tm;
>     boost::xtime_get(&tm, boost::TIME_UTC);
>     tm.sec += 2;
>     boost::thread::sleep(tm);
>
>     std::cout << "thread(): leaving\n";
> }
>
> int main()
> {
>     std::cout << "main(): creating thread\n";
>     boost::thread th(&thread);
>     std::cout << "main(): waiting\n";
>     th.join();
>     std::cout << "main(): done\n";
> }
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

--
bwlee