I am building gcc 9.10 and it works great with c threads but im doing something wrong with g++ and libstdc++-v3 I just dont know what.
I compile gcc/g++, glibc, and libstdc++-v3
I see that the file at include/c++/9.1.0/threads
When I go to compile a simple test program I get
error: ‘thread’ is not a member of ‘std’
C pthread test program compiles
#include <pthread.h>
int main(){
tpthread_t t;
}
C test program compiles
#include <threads.h>
int main(){
thrd_t t;
}
Cxx test program does not compile
#include <thread>
int main(){
std::thread t;
}
Gets error
error: ‘thread’ is not a member of ‘std’
Looking into the header include/c++/9.1.0/threads
#if defined(_GLIBCXX_HAS_GTHREADS)
it looks like it skips everything if that is not defined
how can I check to see if thats the case and then why?
I made this little test and it compiles indicating to me that _GLIBCXX_HAS_GTHREADS is not defined
int main(){
#if defined(_GLIBCXX_HAS_GTHREADS)
123 here error
#endif
}
when compiling libstdc++-v3 I use
../libstdc++-v3/configure -v --enable-libstdcxx-threads=yes
even though I would think threads should be enabled by default on a linux x64 system
The other question doesnt help my situation it was from a long time ago and gcc has changed. One comment looks like it touches on my issue but doesnt go any deeper
If you look in the thread header, it appears that the class only exists #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1). I'm not sure though, what you'd have to do to have those defined
Thats the issue im having but theres no solution
The answer was to configure with --enable-threads=yes I dont know why that was so hard to find and why thats not default
Related
I am trying to make the following code work on both Linux and FreeBSD based system, Is it a valid usage of macros __GLIBC__ and __USE_XOPEN2K8?
#include <stdio.h>
#include <langinfo.h>
#include <locale.h>
#include <xlocale.h>
int main(void) {
//#if defined(__GLIBC__) && defined (__USE_XOPEN2K8)
locale_t loc;
char *locale_messages = "en-US.utf-8";
loc = newlocale(LC_ALL_MASK, locale_messages, (locale_t)0);
if (loc != NULL)
{
char result[256];
sprintf(result, "%s_%s.%s",
nl_langinfo_l(_NL_IDENTIFICATION_LANGUAGE, loc),
nl_langinfo_l(_NL_IDENTIFICATION_TERRITORY, loc),
nl_langinfo_l(CODESET, loc));
}
//#endif
}
If I don't use those directives, I get the following error on mac OS. I want to disable that code to avoid the following errors.
error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
nl_langinfo_l(_NL_IDENTIFICATION_LANGUAGE, loc),
^
error: use of undeclared identifier '_NL_IDENTIFICATION_TERRITORY'
nl_langinfo_l(_NL_IDENTIFICATION_TERRITORY, loc),
I have found one thread recommending use _GNU_SOURCE and _XOPEN_SOURCE, but as result above code is disabled on my linux system too. It seems I need to define _GNU_SOURCE before using it, but before proceding with this idea, can we work with __GLIBC__ and __USE_XOPEN2K8.
You can use
#indef __FreeBSD__
#endif
preprocessor directives to ignore the code that shouldn't be built on FreeBSD. However man nl_langinfo_l on FreeBSD says that this function is present on FreeBSD, so you shouldn't have any problems with it.
The best way is to use a build system to detect if that option is available and then conditionally enable that part of code depending of the detection result. This is how autotools project came to be - to detect differences between operating systems.
In cmake you could:
include(CheckCSourceCompiles)
check_c_source_compiles("
#define _GNU_SOURCE
#define _SOMETHING_READ_FEATURE_TEST_MACROS
#include <something something that is needed.h>
int main() { return _NL_IDENTIFICATION_TERRITORY; }
" WE_HAVE_NL_IDENTIFICATION_TERRITORY)
if(WE_HAVE_NL_IDENTIFICATION_TERRITORY)
target_add_definitions(your_target PUBLIC LIB_HAS_NL_IDENTIFICATION_TERRITORY)
endif()
and then use your own LIB_HAS_NL_IDENTIFICATION_TERRITORY macro that detect if that option is available or not. Such solution is stable, easy to port and dynamically reacts to environment changes.
Im learning to use intrinsics instead of asm-inlining. Yesterday, they were working but I always get error today. Changed nothing.
#include <iostream>
#include <intrin.h> // immintrin.h, smmintrin.h ... tried all, never worked
using namespace std;
int main()
{
_m256_zeroupper(); // __mm256_zeroupper(); does not work too
_mm128 x; // __mm128 x; does not work too
_mm256 y; // __mm256 y; does not work too
_m256_zeroupper(); // __mm256_zeroupper(); does not work too
cout << "Hello world!" << endl;
return 0;
}
Here are the errors. I tried all header files for different intrinsics but errors were same. Also reinstalled gcc but did not work.
Where am I wrong? What do I need to add to actually declare these intrinsic variables and functions?
C:\indirmeDenemesi\hello_intrin\main.cpp||In function 'int main()':|
C:\indirmeDenemesi\hello_intrin\main.cpp|8|error: '_mm256_zeroupper' was not declared in this scope|
C:\indirmeDenemesi\hello_intrin\main.cpp|9|error: '_mm128' was not declared in this scope|
C:\indirmeDenemesi\hello_intrin\main.cpp|9|error: expected ';' before 'x'|
C:\indirmeDenemesi\hello_intrin\main.cpp|10|error: '_mm256' was not declared in this scope|
C:\indirmeDenemesi\hello_intrin\main.cpp|10|error: expected ';' before 'y'|
||=== Build finished: 5 errors, 0 warnings (0 minutes, 0 seconds) ===|
Using 64-bit latest version of gcc on 64bit cpu with 64 bit windows.
CPU is FX8150.
Tried -march=bdver1 -mtune=bdver1 and it produced hundreds of junk error.
Does all these mean my CPU is dying?
Edit: some other projects are working now, but I did not change anything. This must be a project-specific thing.
Using code::blocks and when I right-click on a header and select "open", it gives error "could not find" but does not give any error when compiling related to that, just error for intrinsinc commands. Same for working projects(they compile everything and work, but does not find header files when right click and click open). Maybe some other windows services were interfering? I dont know but compiler errors are vanishing and coming again, time to time. Reinstalling also codeblocks did not solve. Only some projects can use intrinsics while other projects cannot(even if all projects have same headers.)
This code below does not work too.
#include <iostream>
#include <immintrin.h>
using namespace std;
int main()
{
_m256_zeroupper();
__mm128 x;
__mm256 y;
_m256_zeroupper();
cout << "Hello world!" << endl;
return 0;
}
Three things should make your code work:
Make sure you're using the -mavx compile flag.
Your variable should be declared as __m256 not _mm256.
Make sure you're including immintrin.h
I'm experiencing some sort of issue trying to compile a perfectly (windows+linux tested) mpi+openmp software I wrote my own.
I've managed to install and set to work the omp-adapted version of clang, and it works flawlessly in a simple omp "hello world" I've prepared.
As well I've installed open-mpi via homebrew, and the mpi "hello world" is working as well.
Now there come the issue.
Firstly, not so much confident in clang and openmp working together, I've created a version of my software without openmp calls. This version (MPI-only) of the code has been compiled with no issue.
Now comes my real dilemma.
I've reverted back the omp sections of my code, and tried to compile it with both MPI and openMP flags (mpic++ wrapper with ompclang forced in and -fopenmp flag added). The output of the compiler verbose mode is here below.
[...]
/usr/local/Cellar/open-mpi/1.8.4/include/openmpi/ompi/mpi/cxx/mpicxx.h:39:10:
fatal error: 'utility' file not found
#include <utility>
^
[...]
/usr/local/Cellar/open-mpi/1.8.4/include/openmpi/ompi/mpi/cxx/mpicxx.h:39:10:
fatal error: 'utility' file not found
#include <map>
^
[...]
After this output I tried to compile something like this:
#include <iostream>
#include <map>
#include <utility>
int main(int argc,char* argv[]){
std::cout<<"Hello World!!!!"<<std::endl;
return 0;
}
And the output keeps me saying the compiler can't find map, utility AND iostream as well.
It appears to me the problem is the compiler doesn't know where to find the standard c++ libraries.
Can anyone of you tell me how to solve this? Thanks in advance
Have fun,
gf
EDIT:
I've found a good suggestion from this site:
http://lists.cs.uiuc.edu/pipermail/cfe-users/2013-November/000293.html
That helped me to solve the issue.
I post the OMP+MPI hello world if anyone ever needs to test them together.
#include <mpi.h>
#include "omp.h"
int main(int argc, char** argv) {
// Initialize the MPI environment
MPI_Init(NULL, NULL);
// Get the number of processes
int world_size;
MPI_Comm_size(MPI_COMM_WORLD, &world_size);
// Get the rank of the process
int world_rank;
MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
// Get the name of the processor
char processor_name[MPI_MAX_PROCESSOR_NAME];
int name_len;
MPI_Get_processor_name(processor_name, &name_len);
// Print off a hello world message
#pragma omp parallel
printf("Hello from thread %d, nthreads %d,from processor %s, rank %d out of %d processors\n", omp_get_thread_num(), omp_get_num_threads(),processor_name, world_rank, world_size);
// Finalize the MPI environment.
MPI_Finalize();
}
Have fun
gf
I'm not able to compile clang(3.3) using MinGW 4.8.1. The following error always pops-up when 70% build is complete:
clang/lib/Basic/FileManager.cpp includes sys/stat.h, which defines #define stat _stat64i32 (actually there are a few other defines in between, but you get the idea ;)
clang/include/clang/Basic/FileManager.h does not include sys/stat.h; instead only has a forward-declaration.
Hence, while parsing the header, the forward declaration is used (struct stat)
But when it finally arrives at the implementation, the preprocessor will kick in and replace struct stat with struct stat64i32. Hence the mismatch.
The best solution would be to change the forward declaration in the header to instead include sys/stat.h. (I didn't actually test if it will compile then)
The current trunk does not contain the code anymore.
Update: regarding off64_t. This is defined in _mingw_off_t.h these days as:
#ifndef _OFF64_T_DEFINED
#define _OFF64_T_DEFINED
__MINGW_EXTENSION typedef long long _off64_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
__MINGW_EXTENSION typedef long long off64_t;
#endif
#endif /*_OFF64_T_DEFINED */
So you probably want to define _POSIX before including io.h (or stdio.h)
I've been trying to implement PIMPL using the g++ compiler on my local CygWin install and I'm beginning to think it may be the fact that I'm running g++ 4.3.4, inasmuch as its C++11 support is less than perfect.
With the very baseline code (from MSDN here):
my_class.h:
#include <memory>
class my_class {
public:
my_class();
private:
class impl; unique_ptr<impl> pimpl(new impl);
};
my_class.cpp:
#include "my_class.h"
class my_class::impl { int my_int; };
my_class::my_class(): pimpl( new impl ) {};
I try to compile with g++ -std=c++0x -o my_class.o my_class.cpp and end up with:
In file included from my_class.cpp:1:
my_class.h:8: error: ISO C++ forbids declaration of 'unique_ptr' with no type
my_class.h:8: error: invalid use of '::'
my_class.h:8: error: expected ';' before '<' token
my_class.cpp: In constructor 'my_class::my_class()':
my_class.cpp:5: error: class 'my_class' does not have any field named 'pimpl'
I also get that if I substitute -std=gnu++0x.
In fact, when I try to compile even the simplest file, lifted from another SO answer:
#include <iostream>
#include <memory>
int main() {
std::unique_ptr<int> up( new int( 30 ) );
}
it complains that unique_ptr is not in the std namespace.
The gcc c++11 support page has no entry for unique_ptr but, from looking at the net, it's been around for quite a while, at least since 4.4.
So my question is, firstly, at what version of gcc was support for unique_ptr added?
And, secondly, am I just making some bonehead mistake in my code, using it the wrong way?
In your first example, the std:: qualifier is missing on unique_ptr. The second example is correct C++11.
According to the GCC 4.4 release notes, unique_ptr was not in GCC's standard C++ library before 4.4:
Improved experimental support for the upcoming ISO C++ standard, C++0x, including:
...
unique_ptr, <algorithm> additions, exception propagation, and support for the new character types in <string> and <limits>.