Date: Thu, 25 Aug 2016 12:19:48 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Dimitry Andric <dimitry@andric.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: name conflict after upgrade to HEAD. Message-ID: <861853e6-4749-8b80-c1f0-05998f13ab78@digiware.nl> In-Reply-To: <098B0C71-3287-49B6-A80F-25A63087134F@andric.com> References: <0777433b-66fd-7a16-c8b5-25f6fee7ad31@digiware.nl> <2783A1E7-853F-4361-88BF-362B6C5F4764@andric.com> <8892da81-7aa6-20cf-3edd-106d85cd5aef@digiware.nl> <098B0C71-3287-49B6-A80F-25A63087134F@andric.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25-8-2016 09:06, Dimitry Andric wrote:
> On 24 Aug 2016, at 16:30, Willem Jan Withagen <wjw@digiware.nl> wrote:
>>
>> On 24-8-2016 15:23, Dimitry Andric wrote:
> ...
>>> Can you show the full command line used to build the offending source
>>> file? Usually this is caused by an incorrect include directory search
>>> order. And most often, that is caused by build systems inserting
>>> -isystem into compile command lines.
>>
>> This is the full output of the failing compile
>>
>> --WjW
>>
>> [ 3%] Building CXX object
>> src/CMakeFiles/common.dir/common/perf_counters.cc.o
>> cd /home/wjw/ceph/build/src && /usr/bin/CC
>> -DCEPH_LIBDIR=\"/usr/local/lib\"
>> -DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\"
>> -I/home/wjw/ceph/build/src/include -I/home/wjw/ceph/src
>> -I/usr/local/include -I/home/wjw/ceph/build/include
>> -I/home/wjw/ceph/src/xxHash -Wall -Wtype-limits -Wignored-qualifiers
>> -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing
>> -fsigned-char -Wno-inconsistent-missing-override -Wno-mismatched-tags
>> -Wno-unused-function -Wno-unused-local-typedef
>> -Wno-inconsistent-missing-override -Wno-unused-private-field
>> -Wno-varargs -Wno-gnu-designator -Wno-mismatched-tags
>> -Wno-missing-braces -Wno-parentheses -Wno-deprecated-register
>> -ftemplate-depth-1024 -Wno-invalid-offsetof -Wnon-virtual-dtor
>> -Wno-overloaded-virtual -fdiagnostics-color=auto
>> -I/usr/local/include/nss/nss -I/usr/local/include/nspr
>> -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc
>> -fno-builtin-free -O0 -g -fPIC -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT
>> -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++11 -o
>> CMakeFiles/common.dir/common/perf_counters.cc.o -c
>> /home/wjw/ceph/src/common/perf_counters.cc
>> In file included from /home/wjw/ceph/src/common/perf_counters.cc:17:
>> In file included from /home/wjw/ceph/src/common/perf_counters.h:21:
>> In file included from /home/wjw/ceph/src/include/utime.h:18:
>> /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous
>> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);}
>> ^
>> /usr/include/c++/v1/math.h:845:1: note: candidate found by name lookup
>> is 'log'
>> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);}
>> ^
>> /usr/include/c++/v1/math.h:839:46: note: candidate found by name lookup
>> is 'log'
>> inline _LIBCPP_INLINE_VISIBILITY long double log(long double __lcpp_x)
>> _NOEXCEPT {return logl(__lcpp_x);}
>> ^
>> /usr/include/c++/v1/math.h:838:46: note: candidate found by name lookup
>> is 'log'
>> inline _LIBCPP_INLINE_VISIBILITY float log(float __lcpp_x)
>> _NOEXCEPT {return logf(__lcpp_x);}
>> ^
>> /usr/include/math.h:247:8: note: candidate found by name lookup is 'log'
>> double log(double);
>> ^
>> /home/wjw/ceph/src/common/ceph_context.h:44:13: note: candidate found by
>> name lookup is 'ceph::log'
>> namespace log {
>> ^
>
>
> Okay, no -isystem options there. So that's not it. Now I'm assuming
> this is because the original .cc file includes <math.h>, which imports a
> global "log" symbol. Can you try changing that include to <cmath>?
> However, this could require prefixing some math function calls with
> std::.
That did not work either.
Same stack of errors, only now "includes/utimes.h" calls <cmath> calls
math.h on the next include.
Problem is still with the inclusion of the std math stuff.
And yes,
namespace ceph{
namespace log{ ... }
}
is included before this.
But I'd expect the ceph::log not to conflict with {std::}log.
Compiler however thinks otherwise.
Needless to say that GCC does not complain and "does the expected".
(I'm not going to say: ther right thing)
--WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?861853e6-4749-8b80-c1f0-05998f13ab78>