Boost logo

Boost-Build :

Subject: Re: [Boost-build] building boost on interix
From: Robert Oeffner (robert_at_[hidden])
Date: 2009-07-23 03:46:08

OK. Having done some more tests it does seem like there's a problem with my
GCC. I'm still investigating.


From: "Vladimir Prus" <ghost_at_[hidden]>
Sent: Wednesday, July 22, 2009 4:07 PM
To: "Boost.Build developer's and user's list" <boost-build_at_[hidden]>
Subject: Re: [Boost-build] building boost on interix

> On Wednesday 22 July 2009 Robert Oeffner wrote:
>> Hi,
>> I'm trying to build Boost1.39.0 on interix which is a UNIX subsystem
>> running on top of the NT kernel for Windows. MS provides interix as an
>> optional add-on.
>> The particular software I'm trying to compile is the Crystallographic
>> Toolbox, CCTBX, and although it compiles it is with several warnings
>> virtually all of the form:
>> boost/python/detail/signature.hpp:77: warning: sorry: semantics of inline
>> function static data 'const boost::python::detail::signature_element
>> result [10]' are wrong (you'll wind up with multiple copies)
>> A problem with GCC on interix is that binutils do not support weak
>> symbols. From what I've read I believe that the above warning is due to
>> the compilers lack of support for weak symbols. A small test example on
>> illustrates the problem. Indeed when I compile this piece of code on
>> interix I get:
>> ~/tmp/weakboost>
>> ~/tmp/weakboost> g++ -I/E/Users/oeffner/Interix/Boost/boost_1_39_0
>> weak1.cpp
>> In file included from weak1.cpp:2:
>> /E/Users/oeffner/Interix/Boost/boost_1_39_0/boost/crc.hpp: In static
>> member function 'static void boost::detail::crc_table_t<Bits, TruncPoly,
>> Reflect>::init_table() [with unsigned int Bits = 32u, typename
>> boost::uint_t<Bits>::fast TruncPoly = 79764919u, bool Reflect = true]':
>> /E/Users/oeffner/Interix/Boost/boost_1_39_0/boost/crc.hpp:838:
>> instantiated from 'boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor,
>> ReflectIn, ReflectRem>::crc_optimal(typename
>> boost::detail::mask_uint_t<Bits>::fast) [with unsigned int Bits = 32u,
>> typename boost::uint_t<Bits>::fast TruncPoly = 79764919u, typename
>> boost::uint_t<Bits>::fast InitRem = -1u, typename
>> boost::uint_t<Bits>::fast FinalXor = -1u, bool ReflectIn = true, bool
>> ReflectRem = true]'
>> weak1.cpp:6: instantiated from here
>> /E/Users/oeffner/Interix/Boost/boost_1_39_0/boost/crc.hpp:492: warning:
>> sorry: semantics of inline function static data 'bool did_init' are wrong
>> (you'll wind up with multiple copies)
>> /E/Users/oeffner/Interix/Boost/boost_1_39_0/boost/crc.hpp:492: warning:
>> you can work around this by removing the initializer
>> /tmp/ccCxFr4u.o(.text+0xf0):weak1.cpp: undefined reference to
>> `boost::detail::crc_table_t<32u, 79764919u, true>::table_'
>> collect2: ld returned 1 exit status
>> ~/tmp/weakboost>
>> The compiled binaries from the CCTBX also have problems. It is at present
>> not possible to load boost-python modules from CCTBX in python on interix
>> as it produces a core dump. I think that the lack of support for weak
>> symbols used by the boost library templates is what causes this.
>> However, Boost compiles well on platforms without weak symbol support,
>> such as win32 (the cited example compiles fine with VC2005 as does the
>> CCTBX). I would like to know what flags I can tweak a compilation of
>> Boost with on interix to specify that I do not want GCC attempting to use
>> weak symbols. If anyone has got any suggestions that would be great.
> Robert,
> unfortunately, I cannot be very helpful here. It does not seem like your
> problem is that
> Boost requires weak symbols support in general -- it is not. Rather, it
> seems like your
> gcc/ld are broken. Technically, gcc has a -fno-weak option, that you can
> add by
> cxxflags=-fno-weak
> option to Boost.Build. However, I never used that personally, and it might
> break more
> than it fix. I suggest you either contract Interix support, or use other
> gcc,
> like mingw/cygwin, or use native windows compiler.
> - Volodya

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at