I am trying to compile my C++ code using clang++ but keep getting this error with the conflicting namespace. My main.cpp file is a simple Hello World program (for debugging).
I have a feeling the issue is with my version of GCC or clang that I compiled on my cluster. Any ideas as to how to trace this issue down? Or steps to troubleshoot?
[aebrenne#hpc src]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/data/apps/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --with-gmp=/data/apps/gmp/5.1.2 --with-mpfr=/data/apps/mpfr/3.1.2 --with-mpc=/data/apps/mpc-1.0.1 --enable-threads=posix --with-as=/data/apps/binutils/2.23.2/bin/as --mandir=/data/apps/gcc/4.8.1/man --pdfdir=/data/apps/gcc/4.8.1/pdf --htmldir=/data/apps/gcc/4.8.1/html --enable-languages=c,c++,fortran,ada,go,java,lto,objc,obj-c++ --prefix=/data/apps/gcc/4.8.1
Thread model: posix
gcc version 4.8.1 (GCC)
[aebrenne#hpc src]$ clang++ --version
clang version 3.4 (trunk 193367)
Target: x86_64-unknown-linux-gnu
Thread model: posix
[aebrenne#hpc src]$
[aebrenne#hpc src]$ cat main.cpp
#include <iostream>
int main() {
std::cout << "Starting test..." << std::endl;
return 0;
}
[aebrenne#hpc src]$ clang++ -std=c++11 -Wall -g -I/data/apps/gcc/4.8.1/include/c++/4.8.1 main.cpp
In file included from main.cpp:1:
In file included from /data/apps/gcc/4.8.1/include/c++/4.8.1/iostream:39:
In file included from /data/apps/gcc/4.8.1/include/c++/4.8.1/ostream:38:
In file included from /data/apps/gcc/4.8.1/include/c++/4.8.1/ios:38:
In file included from /data/apps/gcc/4.8.1/include/c++/4.8.1/iosfwd:39:
In file included from /data/apps/gcc/4.8.1/include/c++/4.8.1/bits/stringfwd.h:40:
/data/apps/gcc/4.8.1/include/c++/4.8.1/bits/memoryfwd.h:50:15: error: expected '{'
namespace std _GLIBCXX_VISIBILITY(default)
^
/data/apps/gcc/4.8.1/include/c++/4.8.1/bits/memoryfwd.h:50:15: error: C++ requires a type specifier for all declarations
namespace std _GLIBCXX_VISIBILITY(default)
^~~~~~~~~~~~~~~~~~~
/data/apps/gcc/4.8.1/include/c++/4.8.1/bits/memoryfwd.h:50:35: error: expected expression
namespace std _GLIBCXX_VISIBILITY(default)
^
/data/apps/gcc/4.8.1/include/c++/4.8.1/bits/memoryfwd.h:50:43: error: expected ';' after top level declarator
namespace std _GLIBCXX_VISIBILITY(default)
^
As this is the first result for searches along the lines of:
error: expected unqualified-id before 'namespace'
namespace std _GLIBCXX_VISIBILITY(default)
I'll confess that I got this error by missing a closing-brace in a header file included before the one mentioned in the backtrace.
Hopefully this helps someone.
I had the same issue.
The problem was that I had only the following as CPATH:
<gcc-install-path>/include/c++/<gcc-version>
After greping for _GLIBCXX_VISIBILITY in the same directory, it seems that the macro is defined in a sub-directory, specific for the host machine. In my case, this is x86_64-unknown-linux-gnu. Adding that to CPATH solved the problem. My new CPATH is:
<gcc-install-path>/include/c++/<gcc-version>:<gcc-install-path>/include/c++/<gcc-version>/<machine-specific-headers>
For my example machine this translates to:
export CPATH=~/f/i/gcc-4.8.4/include/c++/4.8.4:~/f/i/gcc-4.8.4/include/c++/4.8.4/x86_64-unknown-linux-gnu
I hope that helps someone.
I am using clang++ 4.2 and it worked for me, strange
clang++ -std=c++11 -Wall -g main.cpp
What if you just get rid of the -I/data/apps/gcc/4.8.1/include/c++/4.8.1
Doesn't it work by default?
for GCC define subject of attribute for function, namespaces passed arguments types, call protocol and so no. Macros _GLIBCXX_VISIBILITY(default) is redefinition of attribute( visibility_(default)) In Windows is not defined... in Linux is on! As to another OC I don't know. You must redefine this macros as empty and set them before all includes. So on error occurs. But it's strange... If you setup STL platform oriented the appropriate redefinition must be!!! You need it to manually. As to me I like attributes. They allow control some aspects not available any compiler and grantee correct behavior. For example control arguments type and number of vars passed in function printf according to format.And if you passed different type or not enough number args error occurs as a compile error!!! Nothing else gives such an opportunity!!! Use attributes on Linux. It's good an idea...
I hit the same issue.
I mix up gcc 4.8 headers and system headers(lower version,gcc 4.4.6, _GLIBCXX_VISIBILITY not defined).
use:
clang++ -std=c++11 -Wall -g -I/data/apps/gcc/4.8.1/include/c++/4.8.1 main.cpp -v -H
to see all the "include" details.
In my case:
. /include/c++/4.8.2/iostream
.. /usr/lib64/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/x86_64-redhat-linux/bits/c++config.h
... /include/bits/wordsize.h
... /usr/lib64/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/x86_64-redhat-linux/bits/os_defines.h
.... /include/features.h
..... /include/stdc-predef.h
..... /include/sys/cdefs.h
...... /include/bits/wordsize.h
..... /include/gnu/stubs.h
...... /include/gnu/stubs-64.h
... /usr/lib64/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/x86_64-redhat-linux/bits/cpu_defines.h
.. /include/c++/4.8.2/ostream
... /include/c++/4.8.2/ios
.... /include/c++/4.8.2/iosfwd
..... /include/c++/4.8.2/bits/stringfwd.h
...... /include/c++/4.8.2/bits/memoryfwd.h
In file included from test.cpp:1:
In file included from /include/c++/4.8.2/iostream:39:
In file included from /include/c++/4.8.2/ostream:38:
In file included from /include/c++/4.8.2/ios:38:
In file included from /include/c++/4.8.2/iosfwd:39:
In file included from /include/c++/4.8.2/bits/stringfwd.h:40:
/include/c++/4.8.2/bits/memoryfwd.h:50:15: error: expected '{'
namespace std _GLIBCXX_VISIBILITY(default)
Fixed with this:
clang++ -std=c++11 -isystem /include/c++/4.8.2/ -isystem /include/c++/4.8.2/x86_64-baidu-linux-gnu/ test.cpp -v -H
For that _GLIBCXX_VISIBILITY is defined in /include/c++/4.8.2/x86_64-baidu-linux-gnu/bits/c++_config.h
Related
In C++, I am trying to declare an unordered_set simply like this:
std::unordered_set<int> k;
But it is showing this error:
error: 'unordered_set' is not a member of 'std'
I am using g++ (GCC) 5.3.0 on windows using MinGW. Here are the things that I have already considered:
Adding the header file by #include <unordered_set>
Upgrading MinGW
Using the flag -std=gnu++11. (This is not generating any executable or error, not sure if it doing anything or not)
How to fix it and compile my code successfully?
Use -std=c++11 switch and specify output file.
g++ -std=c++11 your_file.cpp -o your_program
We are catching compiler errors when using sigemptyset on Cygwin under Newlib. The error occurs with a C++ compiler, but only when -std=XXX is used. Without a standard option, the test program compiles and executes as expected.
The test program is below, and the Cygwin header of interest follows. I don't see anything suspicious in the Cygwin header.
I've tried tricks like #define _GNU_SOURCE and #define _XOPEN_SOURCE 700. I've also tried tricks like using the global and std namespaces. Related, see What does -D_XOPEN_SOURCE do/mean? and Namespace issues in c++11?.
What is causing the compile failure and how do I fix it?
$ cat ~/test.cxx
#include <signal.h>
int main(int argc, char* argv[])
{
struct sigaction new_handler;
return sigemptyset(&new_handler.sa_mask);
}
Without a -std=XXX, it results in:
$ g++ -c test.cxx
$
With a -std=XXX, it results in:
$ g++ -std=c++03 -c test.cxx
test.cxx: In function int main(int, char**):
test.cxx:6:44: error: sigemptyset was not declared in this scope
return sigemptyset(&new_handler.sa_mask);
And when trying to use sigemptyset in the global namespace:
$ g++ -std=c++03 -c test.cxx
test.cxx: In function ‘int main(int, char**)’:
test.cxx:6:12: error: ‘::sigemptyset’ has not been declared
return ::sigemptyset(&new_handler.sa_mask);
^
Things get worse when using -std=gnu++03 and friends.
The function is an extension over the ISO C standard.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigemptyset.html
as such is protected on /usr/include/sys/signal.h by
__XSI_VISIBLE >= 4
see /usr/include/sys/features.h for details.
As defaults the largest definition set is used, but -std=XXX reduces the definition scope
The issue was worked through at Botan 2.1.0 does not compile under Cygwin 2.8.0 with g++ 5.4.0. Here are the two comments of interest.
First, from noloader:
Cygwin uses Newlib, not GNU's libstdc++. When there's no
-std=c++XX, current GCC defaults to -std=gnu++11 (GCC 6 changes
to gnu++14 by default). I
believe GNU sources ensures expected functions, like sigaction, are
available.
You might consider trying -D_XOPEN_SOURCE=600 or
-D_XOPEN_SOURCE=700.
Also see C++ and feature guards Warning
Question on the
Newlib mailing list.
Second, from SideChannel:
Thanks to #noloader. Until now -std=c++11 was set in Makefile. The
important info is in above mentioned thread on the Newlib mailing
list. Yaakov Selkowitz wrote:
G++ defines _GNU_SOURCE on glibc targets, meaning that -std=c++NN is, contrary to the documentation, not strict ISO C++:
So, applying the patch #987
AND setting -std=gnu++11 works for me. I
did not try the other -D options (I think the other fact is more
fundamental). Summarizing, #randombit please apply the PR #987 and set
-std=gnu++11 for gcc under Cygwin.
I have made an OpenGL project compilable with GCC (version 4.7.3 and newer) and runable on Linux. When trying to compile the same code under Windows using MSYS2 with GCC 4.9.2 installed, I get tons of error reports:
g++ -g --std=c++11 src/*.cpp -Iinclude -Isrc -lIL -lILU -lILUT -lGL -lGLU -lglut -lm -DWIN32 -I/mingw64/include windows/src/*.cpp -o "Achtung, die Kurve 3D!"
In file included from /usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/stringfwd.h:40:0,
from /usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/string:39,
from include/windows.h:1,
from /usr/include/w32api/GL/gl.h:13,
from /mingw64/include/GL/freeglut_std.h:143,
from /mingw64/include/GL/freeglut.h:17,
from src/controls.cpp:1:
/usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/memoryfwd.h:63:3: error: template with C linkage
template<typename>
^
/usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/memoryfwd.h:66:3: error: template specialization with C linkage
template<>
^
/usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/memoryfwd.h:70:3: error: template with C linkage
template<typename, typename>
^
...
In file included from /mingw64/include/GL/freeglut_std.h:143:0,
from /mingw64/include/GL/freeglut.h:17,
from src/controls.cpp:1:
/usr/include/w32api/GL/gl.h:684:1: error: ‘WINGDIAPI’ does not name a type
WINGDIAPI void APIENTRY glAccum(GLenum op,GLfloat value);
...
/usr/include/w32api/GL/gl.h:1037:24: error: expected ‘)’ before ‘*’ token
typedef void (APIENTRY *PFNGLGETCOLORTABLEPARAMETERFVEXTPROC)(GLenum target,GLenum pname,GLfloat *params);
^
In file included from /mingw64/include/GL/freeglut_std.h:144:0,
from /mingw64/include/GL/freeglut.h:17,
from src/controls.cpp:1:
/usr/include/w32api/GL/glu.h:24:25: error: expected initializer before ‘gluErrorString’
const GLubyte *APIENTRY gluErrorString(GLenum errCode);
^
/usr/include/w32api/GL/glu.h:25:25: error: expected initializer before ‘gluErrorUnicodeStringEXT’
const wchar_t *APIENTRY gluErrorUnicodeStringEXT(GLenum errCode);
^
...
This is taken from just a partial log consisting of 4500 lines of errors. These are the most frequent ones repeated many times.
I previously thought that the problem lied in old MSYS/MinGW (not the MSYS2 port) which I tried first with the same results. However, MSYS2 did not solve the problems which makes me completely clueless since my code is written in C++ and it only requires standard C and C++ header files along with some GL ones. I do not use any extern "C" mangling.
You are using msys2 GCC here, not mingw-w64 GCC.
Please read the MSYS2 wiki [1] where all of this is explained, but briefly:
Run mingw64_shell.bat, not msys2_shell.bat, install the mingw-w64 GCC toolchain package(s). This command installs both the 32-bit and 64-bit ones using the bash curly brace expansion feature:
pacman -S mingw-w64-{x86_64,i686}-toolchain
.. then see that gcc -dumpmachine reports x86_64-w64-mingw32 and not x86_64-pc-msys
[1] https://sourceforge.net/p/msys2/wiki/Home/
The problem turned out not to be related to OpenGL, neither to MSYS(2)/MinGW(-w64) or MS Visual Studio 2013.
For anyone who might be facing the same problems as I was, the vast majority of all the error reports was generated because there was a custom windows.h header file present in my project's include path. A header with the same name is present in standard Windows header library and is essential for proper functionality of other libraries.
Lesson learned: never try to name a file with system-specific code after the operating system.
Please take a look at the following C++11 snippet:
#include <boost/format.hpp>
int main(int argc, char** argv)
{
auto s = boost::format("");
return 0;
}
When I compile it with clang using the -std=c++11 I get the following error:
$ clang++ -std=c++11 -o main main.cpp
In file included from main.cpp:1:
In file included from /usr/include/boost/format.hpp:19:
In file included from /usr/include/boost/detail/workaround.hpp:41:
In file included from /usr/include/boost/config.hpp:40:
In file included from /usr/include/boost/config/select_stdlib_config.hpp:18:
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/cstddef:51:11: error:
no member named 'max_align_t' in the global namespace
using ::max_align_t;
~~^
1 error generated.
Without the -std=c++11 everything compiles fine, but clang prints a warning:
$ clang++ -o main main.cpp
main.cpp:5:3: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
auto s = boost::format("");
^
So, it looks like a valid workaround is to drop the C++11 flag, as the current version of clang seem to be in C++11 mode, anyway? The drawback is that you will get many warnings.
Is there a better workaround beside completely switching to gcc? Patching the source code of boost::format or gcc-libs is fine for me.
System information:
Platform: Arch Linux x86_64
Boost version: 1.55.0-6
gcc-libs: 4.9.0-1
clang++: 3.4 (tags/RELEASE_34/final)
The bug is closed now. It should be fixed in Arch with clang 3.4-2.
With this commit, Evangelos Foutras merged the following patch from upstream:
http://reviews.llvm.org/rL201729
GoogleTest 1.6 with Cygwin 1.7: 'fileno' was not declared in this scope
Error message when building a simple test on Factorial() function in Eclipse CDT:
Invoking: Cygwin C++ Compiler
g++ -std=c++0x -DGTEST_OS_CYGWIN=1 -I"E:\source\gtest-1.6.0\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/challenge.d" -MT"src/challenge.d" -o "src/challenge.o" "../src/challenge.cpp"
In file included from E:\source\gtest-1.6.0\include/gtest/internal/gtest-internal.h:40:0,
from E:\source\gtest-1.6.0\include/gtest/gtest.h:57,
from ../src/challenge.cpp:11:
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h: In function 'int testing::internal::posix::FileNo(FILE*)':
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1589:51: error: 'fileno' was not declared in this scope
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1595:57: error: 'strdup' was not declared in this scope
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1627:71: error: 'fdopen' was not declared in this scope
Eclipse CDT 8.1 running gcc 4.7.3 on Cygwin 1.7.22
gTest 1.6 succesfully built including demo tests, with cmake 2.8.9 on Cygwin 1.7.22
I've linked the built lib with full path, E:\lib\gtest-1.6.0\Cygwin\libgtest.a
The following command option was added manually, got same error without it.
-DGTEST_OS_CYGWIN=1
Seems the errors have nothing to do with my code. Anyone using gTest with Eclipse and Cygwin?
Thank you,
unsigned long Factorial(unsigned n) {
return n==0? 0 : n*Factorial(n-1);
}
// Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
EXPECT_EQ(1, Factorial(0));
}
// Tests factorial of positive numbers.
TEST(FactorialTest, HandlesPositiveInput) {
EXPECT_EQ(1, Factorial(1));
EXPECT_EQ(2, Factorial(2));
EXPECT_EQ(6, Factorial(3));
EXPECT_EQ(40320, Factorial(8));
}
Setting the C++ standard to -std=gnu++0x rather than -std=c++0x, worked for me. You can try the statement:
g++ -std=gnu++0x -DGTEST_OS_CYGWIN=1 -I"E:\source\gtest-1.6.0\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/challenge.d" -MT"src/challenge.d" -o "src/challenge.o" "../src/challenge.cpp"
Setting symbol (-DGTEST_OS_CYGWIN=1) has got nothing to do with this error.
Some functions go beyond the ANSI standard.
These are disabled when you use std=c++11 (or std=c++0x).
Among them are fdopen, fileno and strdup.
There are two possibilities to use them:
Use the GNU dialect (std=gnu++11).
If you want to compile without dialect and make a local exception, you can include stdio.h with the __STRICT_ANSI__ undefined. (see: Error "'fdopen' was not declared" found with g++ 4 that compiled with g++3)
I have tested both on Suse Linux Enterprise 11, MinGW and Cygwin.
Addition: Another (possibly better) way to access non-ANSI symbols would be to add
#define _POSIX_C_SOURCE 200809L
before the first #include in your file. This will give you access to most of the non-standard routines.
Some functions (e.g. realpath(...)) require
#define _BSD_SOURCE
to be inserted on top of your file.