I am having peculiar problems compiling a macro when I try to use “tuple” or “array” as function names.
The example is truly strange, without #includes but with the macro just named “tuple”:
// tuple.C:
int tuple(){return 0;}
root [0] .L tuple.C+
Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/jfcaron/Projects/Proto2BeamTest2/code_test/./tuple_C.so
/Users/jfcaron/Projects/Proto2BeamTest2/code_test/tuple_C_ACLiC_dict.cxx:80:38: error:
reference to 'tuple' is ambiguous
G__letint(result7, 105, (long) tuple());
^
/Users/jfcaron/Projects/Proto2BeamTest2/code_test/./tuple.C:1:5: note: candidate found
by name lookup is 'tuple'
int tuple(){return 0;}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/tuple:488:29: note:
candidate found by name lookup is 'std::__1::tuple'
class _LIBCPP_TYPE_VIS_ONLY tuple
^
1 error generated.
clang: error: no such file or directory: '/Users/jfcaron/Projects/Proto2BeamTest2/code_test/tuple_C_ACLiC_dict.o'
Error in <ACLiC>: Compilation failed!
Is this a bug in libc++? Why should the name of a macro matter?
Some info that might be useful:
root [2] gSystem->GetMakeSharedLib()
(const char* 0x7fba72510ff0)"cd $BuildDir ; clang++ -c $Opt -m64 -pipe -Wshadow -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -DR__HAVE_CONFIG -std=c++11 -stdlib=libc++ -pthread $IncludePath $SourceFiles ; clang++ $ObjectFiles -dynamiclib -single_module -Wl,-dead_strip_dylibs -O2 -m64 -mmacosx-version-min=10.9 -stdlib=libc++ $LinkedLibs -o $SharedLib"
clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
The same thing happens for “array”. By the way, the headers and are very handy, and it’s a shame that there are difficulties with trying to .L macros.C+ that try to use them (even if they are not exposed to CINT). Will ROOT6 be able to use these out-of-the-box?
Jean-François