Bug 825039 - xtime.hpp(23): TIME_UTC conflicts with glibc definition from time.h
xtime.hpp(23): TIME_UTC conflicts with glibc definition from time.h
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-24 17:50 EDT by Jaroslav Škarvada
Modified: 2015-05-04 21:36 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-13 13:53:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jaroslav Škarvada 2012-05-24 17:50:34 EDT
Description of problem:
In glibc-2.15.90-2.fc18 the macro TIME_UTC is defined in time.h, that causes conflicts with enum definition from xtime.hpp (line 23). This causes build failure of uhd package.

Version-Release number of selected component (if applicable):
boost-devel-1.48.0-13.fc18

How reproducible:
Always

Steps to Reproduce:
1. Visually or try to rebuild uhd-3.4.2-1.fc18
  
Actual results:
The uhd rebuild fails

Expected results:
The uhd rebuilts

Additional info:
Comment 1 Petr Machata 2012-05-24 18:28:22 EDT
I'm just spinning a build that drops that enum completely and simply uses TIME_UTC right away.  Since it's a macro (and has to be, due to C11), there's just no way to avoid the conflict (short of avoiding inclusion of that header, but we need it).

It seems from the build failure message that uhd just includes a header that drags the xtime stuff in transitively, so the build should get fixed naturally after the updated boost hits the build roots.  If it uses boost::TIME_UTC explicitly, it will just have to drop the boost:: qualifier.

Upstream ticket https://svn.boost.org/trac/boost/ticket/6940
Comment 2 Rex Dieter 2012-06-10 16:22:46 EDT
I think I'm seeing FTBFS in kstars similarly too, which includes an enum that includes TIME_UTC

In file included from /builddir/build/BUILD/kstars-4.8.90/kstars/indi/devicemanager.h:17:0,
                 from /builddir/build/BUILD/kstars-4.8.90/kstars/indi/devicemanager.cpp:14:
/builddir/build/BUILD/kstars-4.8.90/kstars/indi/indielement.h:48:47: error: expected identifier before numeric constant
/builddir/build/BUILD/kstars-4.8.90/kstars/indi/indielement.h:48:47: error: expected '}' before numeric constant
/builddir/build/BUILD/kstars-4.8.90/kstars/indi/indielement.h:48:47: error: expected unqualified-id before numeric constant
/builddir/build/BUILD/kstars-4.8.90/kstars/indi/indielement.h:56:33: error: expected declaration before '}' token
Comment 3 Rex Dieter 2012-06-10 16:31:40 EDT
heh, similar issue, but not boost's fault, sorry for the noise.

but this gave me the hint how to fix it, thanks.
Comment 4 Jim Meyering 2012-07-23 10:14:49 EDT
This causes iwhd's configure test for existence/usability
of mongo/client/dbclient.h to fail:

configure:30040: g++ -c -g -O2  conftest.cpp >&5
In file included from /usr/include/mongo/client/../util/goodies.h:22:0,
                 from /usr/include/mongo/client/../pch.h:162,
                 from /usr/include/mongo/client/dbclient.h:23,
                 from conftest.cpp:235:
/usr/include/mongo/client/../util/concurrency/mutex.h: In function
  'boost::xtime mongo::incxtimemillis(long long int)':
/usr/include/mongo/client/../util/concurrency/mutex.h:32:38: error: \
  expected unqualified-id before numeric constant

since mongo uses the offending symbol:

/usr/include/mongo/util/concurrency/mutex.h:

  namespace mongo {

      void printStackTrace( ostream &o );

      class mutex;

      inline boost::xtime incxtimemillis( long long s ) {
	  boost::xtime xt;
	  boost::xtime_get(&xt, boost::TIME_UTC);
	  ...
Comment 5 Jim Meyering 2012-07-23 10:15:32 EDT
As you probably know, upstream boost has renamed the symbol: s/TIME_UTC/TIME_UTC_/
Comment 6 Petr Machata 2012-07-24 05:43:45 EDT
Yes, that will be brought in with update to 1.50, which contains this fix.
Comment 7 neal 2012-08-02 03:47:52 EDT
if have the samy problem 
boost_1_50_0
js  1.8.0-rc1
mongodb-src-r2.0.1
mongodb-src-r2.0.6
pcre-8.13
scons-2.1.0
help
Comment 8 Petr Machata 2012-08-02 05:48:06 EDT
(In reply to comment #7)
> if have the samy problem 
> boost_1_50_0

Wait, you have this problem with 1.50?  Can you show output from "rpm -q boost"?  What are you trying to do that triggers this problem?
Comment 9 neal 2012-08-22 23:27:12 EDT
Checking for C library wpcap... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
g++ -o pch.o -c -Wnon-virtual-dtor -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -fno-builtin-memcmp -O3 -D_SCONS -DMONGO_EXPOSE_MACROS -D_FILE_OFFSET_BITS=64 -DXP_UNIX -Ithird_party/js-1.7 -Ithird_party/pcre-7.4 -I. pch.cpp
In file included from /usr/local/include/boost/filesystem/operations.hpp:24,
                 from /usr/local/include/boost/filesystem/convenience.hpp:22,
                 from pch.h:83,
                 from pch.cpp:18:
/usr/local/include/boost/filesystem/config.hpp:16:5: error: #error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3
In file included from util/goodies.h:22,
                 from pch.h:161,
                 from pch.cpp:18:
util/concurrency/mutex.h: In function 'boost::xtime mongo::incxtimemillis(long long int)':
util/concurrency/mutex.h:32: error: 'TIME_UTC' is not a member of 'boost'
scons: *** [pch.o] Error 1
scons: building terminated because of errors.
this is the error out.
i has  Compiled the boost boost_1_50_0   
[root@neal ~]# lsb_release -a
LSB Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.2 (Final)
Release:        6.2
Codename:       Final
[root@neal ~]#
Comment 10 Petr Machata 2012-08-27 18:56:17 EDT
(In reply to comment #4)
> This causes iwhd's configure test for existence/usability
> of mongo/client/dbclient.h to fail
> 
> 	  boost::xtime_get(&xt, boost::TIME_UTC);
> 	  ...

Ah, I see.  TIME_UTC is a C11 macro.  This code expands to boost::1.  This is not really a boost-related error, just a silly C macro namespace collision.  In Boost 1.50, this constant was renamed to TIME_UTC_, so you could update the code to use that instead.

(In reply to comment #9)
> util/concurrency/mutex.h: In function 'boost::xtime
> mongo::incxtimemillis(long long int)':
> util/concurrency/mutex.h:32: error: 'TIME_UTC' is not a member of 'boost'

Same issue.  Sorry I was slow noticing what the problem is.
Comment 11 Fedora End Of Life 2013-04-03 13:05:51 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 12 Fedora End Of Life 2015-01-09 12:09:57 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.