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)
Related
I am using Visual Studio 2017 to build LucenePlusPlus which in turn uses boost/dynamic_bitset.
The following code in LucenePlusPlus
const uint64_t* BitSet::getBits() {
return bitSet.empty() ? NULL : static_cast<const uint64_t*>(&bitSet.m_bits[0]);
}
generates the following fatal compiler error:
1>g:\luceneplusplus\src\core\util\bitset.cpp(20): error C2248: 'boost::dynamic_bitset<uint64_t,std::allocator<Block>>::m_bits': cannot access private member declared in class 'boost::dynamic_bitset<uint64_t,std::allocator<Block>>'
1> with
1> [
1> Block=uint64_t
1> ]
Suggestions?
I have traced the code for my boost 1_75_0 and I see it has a define to conditionally reserve access to friends:
#if defined(BOOST_DYNAMIC_BITSET_DONT_USE_FRIENDS)
#define BOOST_DYNAMIC_BITSET_PRIVATE public
#else
#define BOOST_DYNAMIC_BITSET_PRIVATE private
#endif
So it looks like you should be able to add -DBOOST_DYNAMIC_BITSET_DONT_USE_FRIENDS to the compiler defines to fix this.
In fact, my LucenePlusPlus tree already contains it in
include/config_h/Config.h.in line 107:
#define BOOST_DYNAMIC_BITSET_DONT_USE_FRIENDS
Previously ("rebuilt cmake buildsystem") this apparently
came from include/Config.h.cmake, where it was always present, unconditionally all the way since 2010:
What Can You Do?
Maybe you are not including the required headers that include the config? Also check any interfering precompiled header settings.
If you have boost/dynamic_bitset.hpp included BEFORE including LucenePlusPlus headers at any point you will run with the wrong config.
This is especially bad if you don't detect it because that would violate the ODR rule
I'm looking to build a host program calling OpenCL code running on my GPU device. The cl source has the following form:
#include "skip_mwc.cl"
typedef struct{ uint x; uint c; } mwc64x_state_t;
//blah...
If I get rid of the #include directive and copy/paste the content of "skip_mwc.cl" directly into this source, I can partially "build" and at least get some errors, showing that my compiler (clang9 cl compiler) can at least recognize the kernels code. With the #include approach I get the following error:
Build log::
<program source>:9:10: fatal error: 'skip_mwc.cl' file not found
#include "skip_mwc.cl"
I have checked and the file is there in the search paths, so I'm inclined to believe that my Xcode IDE doesn't index .cl files properly to perform automatic file inclusion (as in .c or .cpp).
I really want to avoid having to copy/paste source from one file into the other. Any suggestions from someone familiar with Xcode, who has encountered this problem and managed to solve it, are very welcome and needed.
Thanks,
A
Two possible solutions:
Set the -I include_dir compiler option in clBuildProgram(), see also this answer.
Read both files from C++ with fstream and string-concatenate their content.
Also see the option of embedding the OpenCL code into the executable via stringification macro.
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.
I am pretty new user of Eigen and have run into a weird problem. I am adding to a C++ project that uses OpenMP (Visual Studio 2012 compiler, /openmp set). I get a compilation error:
include\eigen\src/Core/products/Parallelizer.h(34): error C3861:
'omp_get_max_threads': identifier not found
I have tried to google around for an answer, but have failed to find a solution. We have another project, not using openmp, where Eigen has been used successfully for a while. Adding /openmp to that project did not trigger the problem. I also tried to disable openmp in Eigen, using the EIGEN_DONT_PARALLELIZE preprocessor directive. The problem persists. All suggestions to solve the problem are more than welcome.
Long comment, not really an answer: Something appears to be broken in your project. I'm using Eigen 3.2.9 as a reference, as you haven't specified which version you're using. In Eigen/Core (133) we have
#if (defined _OPENMP) && (!defined EIGEN_DONT_PARALLELIZE)
#define EIGEN_HAS_OPENMP
#endif
#ifdef EIGEN_HAS_OPENMP
#include <omp.h>
#endif
So, if you properly defined EIGEN_DONT_PARALLELIZE in your project, EIGEN_HAS_OPENMP shouldn't be defined and omp.h shouldn't be included. Additionally, in Parallelizer.h(30):
#ifdef EIGEN_HAS_OPENMP
if(m_maxThreads>0)
*v = m_maxThreads;
else
*v = omp_get_max_threads();
#else
*v = 1;
#endif
So if you had properly defined EIGEN_DONT_PARALLELIZE, you would not be getting the error you are getting.
Regarding the C3861 error, it means that the compiler is not able to find a declaration for omp_get_max_threads (called in Parallelizer.h). As that code is called within a #ifdef EIGEN_HAS_OPENMP as is the line #include <omp.h> in Core, and omp_get_num_threads is only wrapped in an #if defined( __cplusplus) you could add a check in Core or omp.h to make sure that the code is active
// This is in Eigen/Core
#ifdef EIGEN_HAS_OPENMP
static_assert(0, "OMP FILE IS INCLUDED IN CORE...");
#include <omp.h>
#endif
and
// This is in omp.h
static_assert(0, "OMP FILE IS PROPERLY INCLUDED...");
_OMPIMP int _OMPAPI
omp_get_num_threads(
void
);
You should get both as errors if omp is loaded correctly.
I'm using 64-bit gcc-4.8.2 to generate a 32-bit target, and my machine is 64-bit. I'm using c++11 concurrency features such as thread, mutex, conditiona_variables and etc.
The linker gave the above error message when trying to link the executable. libMyLib is also part of the project.
libMyLib.so: undefined reference to '__gthrw___pthread_key_create(unsigned int*, void (*)(void*))
nm libMyLib.so | grep pthread_key_create shows:
U _ZL28__gthrw___pthread_key_createPjPFvPvE
w __pthread_key_create##GLIBC_2.0
where is the symbol 'ghtrw___pthread_key_create' from? I tried adding '-lpthread(-pthread)' as compiler flag, but it does not help.
More information. nm libMyLib.so | grep pthread shows other symbols such as _ZL20__gthread_mutex_lockP15pthread_mutex_t is defined
where is the symbol 'ghtrw___pthread_key_create' from?
It is defined in GCC's "gthreads" abstraction layer for thread primitives, in the gthr-posix.h header.
#if SUPPORTS_WEAK && GTHREAD_USE_WEAK
# ifndef __gthrw_pragma
# define __gthrw_pragma(pragma)
# endif
# define __gthrw2(name,name2,type) \
static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
__gthrw_pragma(weak type)
# define __gthrw_(name) __gthrw_ ## name
#else
# define __gthrw2(name,name2,type)
# define __gthrw_(name) name
#endif
/* Typically, __gthrw_foo is a weak reference to symbol foo. */
#define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
...
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
After preprocessing that expands to:
static __typeof(pthread_key_create) __gthrw___pthread_key_create __attribute__ ((__weakref__("__pthread_key_create")));
It is supposed to be a weak reference to __pthread_key_create, so it should never have a definition, because it is just a reference to glibc's internal __pthread_key_create symbol.
So it looks like something has gone wrong with how you build you library. You should not have an undefined weak symbol.
I recently stumbled into this error, and not because of a missing -pthread.
The situation happened in a somewhat unusual setup: I was compiling a software written in C++14 under Centos7. Since C++14 requires a recent version of GCC, I relied on devtoolset 6 for it.
Given the specific setup, I opened a thread on the Centos mailing list, so I'm directly referencing the relevant thread. See https://lists.centos.org/pipermail/centos-devel/2018-May/016701.html and https://lists.centos.org/pipermail/centos-devel/2018-June/016727.html
In short, it might be caused by some bug in the preprocessor macros, either of glibc or libgcc. It can be fixed by placing #include <thread> in the beginning of the source code which gives problems once compiled. Yes, even if you don't use std::thread in it.
I don't claim this will work for everyone, but it might do the job in some particular situations.