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