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

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

heh, similar issue, but not boost's fault, sorry for the noise.

but this gave me the hint how to fix it, thanks.

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);
	  ...

As you probably know, upstream boost has renamed the symbol: s/TIME_UTC/TIME_UTC_/

Yes, that will be brought in with update to 1.50, which contains this fix.

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

(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?

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 ~]#

(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.

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

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.