Re: [Boost-users] Boost issues on Darwin (Mac OS X 10.4/gcc 4)

From: John Maddock (john_at_[hidden])
Date: 2005-12-19 05:43:15

> 1) The build.sh file for the boost bjam tool in the 1.33.0 and 1.33.1
> release seems to have DOS line endings. I know there are prebuilt
> binaries of bjam up on the Web, but our build system builds it
> manually, and it choked on Darwin because sh didn't like the DOS line
> endings. I resaved the file with Unix line endings and it built fine.

Did you download the tar.gz distribution?  That should have Unix line 
endings throughout where as the .zip file has DOS line endings throughout 
(intensionally).

> 2) I get errors for multiply defined symbols for the placeholder
> symbols declared in boost/bind/placeholders.hpp. Every file that
> #include <boost/bind.hpp> contains actual instances of _1, _2, etc.
> Changing the declarations of these in boost/bind.hpp to static (I
> added a __APPLE__ to the #ifdef in the middle of the file) fixes this
> issue, but then I get warnings for unused static symbols if I don't
> use the placeholder objects. This issue in particular is quite
> annoying.

What compiler are you using?  The first #if says:

#if defined(__BORLANDC__) || defined(__GNUC__)

isn't this the branch that gets taken?

> 3) The header in boost/compatibility/cpp_c_headers/cstdio
> does not match up with the cstdio file included with the Mac OS X dev
> tools.
> In particular it is missing a using ::snprintf, which causes problems
> because this cstdio file is being included BEFORE the Mac OS X
> version of the same file, and other C++ header files rely on
> std::snprtinf being declared. I fixed this at first by deleting the
> boost/compatibility/cpp_c_headers folder, but then ending up just
> deleting that single file so that OS X always used the built-in
> header file.

Why are those headers getting included?  They were intended for use only 
with certain broken compilers that didn't have the c-prefixed std lib 
headers.  They're known not to work with several std conforming compilers 
(but shouldn't be included for these anyway).

HTH, John.