Re: [vrjuggler-info] Could not compile the VRJuggler

[Patrick H. <pa...@in...>]

Kristopher J. Blom wrote:
>=20
> Hello Stefanie,
>=20
> I am guessing that you are using SuSE linux.  This is a classic problem=

> on SuSE installations,
> as VR Juggler requires the multi-threaded version of the filesystem
> boost libraries.  Unfortunately,
> the SuSE installation doesn't include it.  We have found two solutions
> to this problem.  One is to
> compile your own version of the libraries.  Unfortunately, classes
> between versions of boost can
> occur, so compiling the exact version that your SuSE uses should work
> best.  Also the un-install
> of the boost package is difficult to to dependencies from other
> packages. The second solution, and
> the one we use the most, is to simply link
> libboost_filesystem-gcc-mt-1_33.so to
> libboost_filesystem-gcc-1_33.so.  Naturally, this is a very bad thing,
> but it hasn't created any
> problems for us yet (but we haven't really tested extensively).=20

Using the --with-boost-fs-lib option is highly recommended over making
symlinks or otherwise trying to fake out the Juggler build. My philosophy=

has always been that the Juggler build should adapt to variations in
operating systems and dependencies, not the other way around.

> Allen, Patrick, et.al.  Is there an actual need of having the mt versio=
n
> of that library?

It would seem not since people don't complain about crashes when using th=
e
single-threaded variant of Boost.Filesystem. However, the Boost libraries=
 do
have some thread-safe bits, and I would expect that this trend would expa=
nd.
Generally, I feel more confident using the multi-threaded versions of Boo=
st
libraries with VR Juggler since it is multi-threaded. (Indeed, this is a
requirement on Windows to get the C runtime libraries to match up.) So fa=
r,
though, the only requirement that I know of is that _PTHREADS has to be
defined when building multi-threaded software against Boost or else share=
d
pointer accesses will deadlock.

> Doesn't only
> one thread access files anyway?

No. Boost.Filesystem is for interacting with the file system. Reading fil=
es
and things like that are done separately by the C or C++ I/O facilities. =
Any
thread could use Boost.Filesystem to access the file system, and multiple=

threads could perform file system accesses simultaneously. Simultaneous f=
ile
system accesses have to be managed by the kernel rather than by user-spac=
e
code, so thread safety in Boost.Filesystem would be for protecting access=
 to
internal data structures. I have not looked into whether Boost.Filesystem=

has explicit thread safety built in or if it even needs it. Nevertheless,=
 I
consider it a bug that the multi-threaded versions of the Boost libraries=

are explicitly stripped out of some vendor-supplied Boost packages. It se=
ems
quite pointless IMHO to take that extra step, but that issue is off topic=

for this list.

> If not, could the error message be
> changed, you know already
> at that point that boost is there (already compiled against it a couple=

> times), just the linking fails
> against the mt library...

No. Knowing that boost/version.hpp can be found does not imply that
Boost.Filesystem is available. The Boost build allows users to build
whichever libraries they want--including none and only installing headers=
=2E
Not being able to detect the compiled Boost.Filesystem library means that=

the Juggler build is mis-configured. It is not strictly related to the
multi-threaded version not being available.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3          | http://www.infiscape.com/