On May 21, 2008, at 11:04 AM, Black wrote:
On May 21, 2008, at 10:57 AM, Carsten Neumann wrote:Hello Black, Black wrote:I'm trying get OpenSG 2.0 to compile under Leopard, and I'm hitting The problem comes when scons looks for the filesystem module of boost. This is the output I get: Loading initial settings for boost BoostBaseDir specified or cached. [/usr/local]. Boost, autofinding toolset... toolset: [darwin] Searching for correct boost include dir... found: /usr/local/ include/boost-1_35 boost include path: /usr/local/include/boost-1_35 boost version: 1.35.0 Checking for C++ library boost_filesystem-1_35... no Checking for C++ library boost_filesystem-1_35... no Checking for C++ library boost_filesystem-1_35... no Checking for C++ library boost_filesystem... no Unable to find library: filesystem tried: ['boost_filesystem-1_35','boost_filesystem-1_35', 'boost_filesystem-1_35', 'boost_filesystem']Option error: Check required failed: Unable to find library: filesystem tried: ['boost_filesystem-1_35', 'boost_filesystem-1_35', 'boost_filesystem-1_35', 'boost_filesystem']I don't know scons at all, so I'm not sure exactly what it is lookingfor our how to help it find it. In /usr/local/lib, I have a libboost_filesystem-mt-1_35.dylib, which I also symlinked to a libboost_filesystem.dylib in hopes that it was just getting confused by the name.basically the problem is that the boost libraries don't have a unique name across platforms (or even linux distros :-/). So normally the scons-addons package that we use for the build attempts a couple of popular names, but it seems that on your machine it tries just one, repeatedly... (?) Anyway, from the output my guess would be that a symlink libboost_filesystem-1_35.dylib to libboost_filesystem-mt-1_35.dylib might satisfy the search (note the version number in the symlink name).It looks like it is actually trying two names, the one with the version numbers three times and then once without. I know have symlinked versions of the library as both libboost_filesystem.dylib and libboost_filesystem-1_35.dylib and still no joy - I get exactly the same result.
If you look at sconf.log_darwin_g++, you will see the errors reported by the compiler or the linker when trying to find Boost.Filesystem. My guess is that the new dependency on Boost.System introduced in Boost 1.35 is the source of the problem. Some part of the OpenSG build (either the SConstruct file or something in SConsAddons) needs to be updated to know that -lboost_system-1_35 must be included when testing for the availability of Boost.Filesystem.
-Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
