Re: [Boost-users] Boost-users Digest, Vol 760, Issue 2

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

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