[boost] Re: Some problems with shmem vs. thread jam building

From: Francis ANDRE (francis.andre_at_[hidden])
Date: 2004-11-15 05:25:23

 > the linker complains that it can find thread library dlls (I suppose
> due to auto_link headers). I don't know if linking a dependant library
You must build the boost::thread libraries before using it as dependent
components
in your own dll libs

bjam "-sTOOLS=vc-7_1" --with-thread install

Moreover, if you are building a library as a dll, you must setup the project
properties
so that /MD or /MDd are active when compiling you library.

Francis

-- 
A good friend will come bail you out of jail..........
but, a true friend....will be sitting next to you saying:
 "...that was fun."
"ION_G_M" <ION_G_M_at_[hidden]> a écrit dans le message de
news:75dbd7274e.7274e75dbd_at_teleline.es...
Hello to all,
  I keep on working on a shared memory boost library proposal. I've
followed Boost.Build guidelines to write the jam file, and auto_link
header, but when writing and executing the jam file I have the
following errors (I'm new to jam and dll building, so forgive me if you
find any question too simple):
1) DLL-s
I wanted to reuse detail::thread::lock class for process shared mutexes
in order to follow the same structure as thread::mutex, but when
building my library dll-s from boost root using
bjam "-sTOOLS=vc-7_1" stage/install
 the linker complains that it can find thread library dlls (I suppose
due to auto_link headers). I don't know if linking a dependant library
is needed when building a dll (in my embedded world, i never design dll-
s so I don't know that). If the library is needed, should I specify a
<library-path> for that in dll building rule? If not needed, do I have
to define a symbol to disable auto_link feature for boost::thread in my
dll rule?
2) boost::thread config
 Apart from this, when building static libraries, I can't compile
boost::detail::thread::scoped_lock if I use it as main locking scheme
for process shared mutexes when building single threaded shared memory
static library, since thread headers check for correct multithread
configuration (I suppose looking for _MT defines).
- - - - - - - - - - - -
 For the moment I've decided to copy thread scoped_lock to my library
changing the namespaces so that I can compile my library and continue
integration. I would like to know if it is convenient to reuse thread
scoped_locks for process shared mutexes.
 For a simple proposal that can be easily rejected, I'm not requesting
any change, but I would like to point out that maybe scoped_locks
should be reused for both thread and process shared mutexes in the
future.
 But my main concern is the linker error when building a dll for a
boost library that depends on other boost library.
 Best regards,
Ion Gaztañaga
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost