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

From: Ryan McGann (rmcgann_at_[hidden])
Date: 2005-12-19 18:48:04

(Re-posted with correct subject line)

On Dec 19, 2005, at 9:00 AM, boost-users-request_at_[hidden] wrote:
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).
Well our build system uses whichever archive is checked in. I imagine  
the PC folks downloaded the .zip version. I can check in a different  
version for the Unix folks.

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?
Hm in my boost/placeholders.hpp, I see
#if defined(__BORLANDC__)
...
#elif defined(BOOST_MSVC) || (defined(__DECCXX_VER) && __DECCXX_VER  
<= 60590031) || defined(__MWERKS__)
...
#else
...
#endif

I don't have a _GCC__ anywhere in there. This is from 1.33.1 (which I  
just newly expanded from the .tar.gz, not the .zip). If I add a  
defined(__GCC__) to the first or second set of #ifdefs, it works fine.

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).
I'm not sure why they're being included. I'm guessing it's because we  
pass -I<path to boost> to GCC, which causes it to search inside of  
that directory before the standard directories get searched. I'll  
have to investigate that further.

Thanks,
Ryan