On Dec 19, 2005, at 9:00 AM, boost-users-request@lists.boost.org 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