[pkg-boost-devel] Bug#701377: Bug#701377: boost1.49: ftbfs with GCC-4.8

[Dmitrijs Ledkovs]

On 1 March 2013 16:56, Daniel Hartwig <mandyke at gmail.com> wrote:
> On 1 March 2013 23:55, Dmitrijs Ledkovs <xnox at debian.org> wrote:
>> On 1 March 2013 14:17, Daniel Hartwig <mandyke at gmail.com> wrote:
>>> On 1 March 2013 21:14, Dmitrijs Ledkovs <xnox at debian.org> wrote:
>>>> In Ubuntu, instead of applying the full patch against 1.49, we went
>>>> for a minimalistic hack/patch to workaround TIME_UTC in eglibc-2.16.
>>>> Simply undef TIME_UTC if defined.
>>>
>>> Is that expected to work for a program that uses both libboost-thread
>>> and C11 date and time?
>>
>> yes, as both have always evaluated to the same constant value on linux.
>
> On glibc, rather.  An unsafe assumption, given that C11 does not
> define the value any more than a non-zero, positive integer.  Boost
> does not even specify that much.
>
> These are different APIs, it is not precise to overload a single
> macro.  The boost macro exists in a distinct namespace and the Ubuntu
> patch does not appear to have the feature you claim.  From the
> attached test case:
>
> $ g++ -o test -lboost_thread test.cc
> test.cc: In function ‘int main(int, const char**)’:
> test.cc:8:11: error: ‘TIME_UTC’ was not declared in this scope
>    int x = TIME_UTC;
>            ^
> --
>
> Further, #undef is placed outside of the BOOST_XTIME_WEK070601_HPP
> header guard; a second include of this header would undefine and not
> subsequently redefine the macro.
>

Thank you for explaining your point. You are right.

>>> Is that expected to work for a program that uses both libboost-thread
>>> and C11 date and time?

existing code that uses libboost-thread does work with both old/new
glibc. At the time that was what I tested and was important to keep.
Indeed one doesn't get access to C11 date and time while using
libbost-thread as patched in boost1.49 in ubuntu.
Meh. I see little point of fixing this in ubuntu as C11 in gcc-4.7 is
still not stable and is not encouraged to be used.

Regards,

Dmitrijs.