I'm trying to compile a program with openmpi, my code does not give any errors but instead one of the mpi headers does:
/usr/include/openmpi-x86_64/openmpi/ompi/mpi/cxx/mpicxx.h:168: error: expected identifier before numeric constant
/usr/include/openmpi-x86_64/openmpi/ompi/mpi/cxx/mpicxx.h:168: error: expected unqualified id before numeric constant
The relevant line of code in the header simply reads:
namespace MPI {
I am using the mpiCC compiler. Am I doing something wrong? or is this a bug in openmpi?
Thanks in advance.
Though I am not able to reproduce the problem you encountered, the following comments can be found in mpi.h, from which mpicxx.h is included:
/*
* Conditional MPI 2 C++ bindings support. Include if:
* - The user does not explicitly request us to skip it (when a C++ compiler
* is used to compile C code).
* - We want C++ bindings support
* - We are not building OMPI itself
* - We are using a C++ compiler
*/
#if !defined(OMPI_SKIP_MPICXX) && OMPI_WANT_CXX_BINDINGS && !OMPI_BUILDING
#if defined(__cplusplus) || defined(c_plusplus)
#include "openmpi/ompi/mpi/cxx/mpicxx.h"
#endif
#endif
If you are not using the deprecated C++ bindings, then a possible workaround is to add
-DOMPI_SKIP_MPICXX
to your CXXFLAGS. Hope this may help.
Related
We are compiling fmt with the Intel C compiler on Windows 32bit and 64 bit. On 32 bit we get a strange error. Maybe we are doing something wrong but the issue is what? Here is the error message:
../master/extern/fmt/8.0.1/include/fmt/format-inl.h(1126): error: expression must have a constant value
static constexpr const uint128_wrapper pow10_significands[] = {
^
Any suggestions for a fix? We could potentially build with MSVC.
Update: format-inl.h (=inline format) is only supposed to be used in a header only mode as far I understand and that is not what I want and has not turned on. So I have to figure why this happens.
PS: fmt is great.
The expression in question is constant so this looks like a bug in the compiler or possibly incomplete implementation of constexpr. The error message is misleading but you might be able to workaround the issue by removing constexpr or some other way.
Have you tried building with a C++17 compiler? constexpr isn’t a C keyword afaik.
So here is the preprocessed output of a struct:
typedef struct RPT_Item
{
wchar_t *fullPath;
RPT_ItemFlags_t itemFlags;
int isComposite;
const void *reserved;
} RPT_Item_t;
Visual Studio complains because wchar_t is not defined, its own cryptic way:
error C2016: C requires that a struct or union has at least one member
I looked at the project files and also at the particular C file where the error appears and I can confirm that "Treat wchar_t as built-in type is set to YES".
If I define the type using a typedef it compiles fine.
I used the preprocessor output so I can exclude that some nasty preprocessor #define trick play the main role.
This project contains many low-level hacks, for example the CRT is not linked (/NODEFAULTLIB).
Most of the code is not written by me, and I'm tasked to remove reference to wchar.h from a public header that uses wchar_t, because VS treats it as a built in type default. (This particular module is built only on Windows.)
I totally ran out of ideas. Is there a compiler option or a pragma that can interfere? Or could it be even a compiler bug?
Microsoft didn't explicitly document this until VS 2013, but the docs for /Zc:wchar_t says
The wchar_t type is not supported when you compile C code.
It seems that including nearly any header from the runtime or from the SDK will typedef wchar_t tounsigned short using the following sequence:
#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif
you might want to do something similar in your file that uses wchar_t.
Note that when compiling a C++ file, if /Zc:wchar_t is in effect then the compiler pre-defines _WCHAR_T_DEFINED. If /Zc:wchar_t- is in effect it doesn't - so the above snippet should work nicely with C++ as well (for MSVC anyway - I don't know how other compilers might deal with this if you're looking for something portable).
The _WCHAR_T_DEFINED macro is documented:
MSVC Predefined Macros
I am using MS-Windows XP SP3 and Visual C++ compiler. Now when I define one macro as-
#define APPVERSION(n) ((int32)0 + n)
and used it as -
if(APPVERSION(2)>= APPVERSION(1)) it is giving me an error as
fatal error C1012: unmatched parenthesis : missing ')'
but when I use that macro as -
#define APPVERSION(n) (0L + n)
It works without any error.
What is exact problem?
Your question is very hard to answer without you providing the complete error message, but I'm guessing it includes something like this as the first line in the error message:
error C2065: 'int32' : undeclared identifier
You have to make sure that the type-alias int32 exists, either by including the correct header where it's defined or define it yourself. And by "define" I mean there should be either a preprocessor #define directive or a typedef.
I'm using bison & flex (downloaded via cygwin) with vc++. When I compile the program I got an error:
...: fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
The corresponding code in the flex-generated file is:
#ifndef YY_NO_UNISTD_H
/* Special case for "unistd.h", since it is non-ANSI. We include it way
* down here because we want the user's section 1 to have been scanned first.
* The user has a chance to override it with an option.
*/
/* %if-c-only */
#include <unistd.h>
/* %endif */
/* %if-c++-only */
/* %endif */
#endif
If I define YY_NO_UNISTD_H in the flex file(.l) this error will disappear, but I get several other errors:
...: error C2447: '{' : missing function header (old-style formal list?)
...: warning C4018: '<' : signed/unsigned mismatch
...: error C3861: 'isatty': identifier not found
How can I fix this problem?
All these errors occur in the flex-generated scanner.
I know it's because unistd.h doesn't exist in windows. Do I have to write my own unistd.h? If so how to write it in order to eliminate those errors?
isatty is used by the lexer to determine if the input stream is a terminal or a pipe/file. The lexer uses this information to change its caching behavior (the lexer reads large chunks of the input when it is not a terminal). If you know that your program will never be used in an interactive kind, you can add %option never-interactive to you lexer. When the program is run with user input, use %option interactive. When both uses are desired, you can either generate an interactive lexer, which gives a performance loss when used in batch mode, or provide your own isatty function.
Use %option nounistd in your .l file to remove the dependence on unistd.h.
just in case somebody's still this problem, Flex comes with unistd.h within its devel files. I found this here:
http://sourceforge.net/tracker/index.php?func=detail&aid=931222&group_id=23617&atid=379173
to put it short, just make sure your compiler can reach it. in my case it's just adding "C:\GnuWin32\include" to the additional inclusion directories
use win_flex.exe with option --wincompat and you dont need to hack your lex file
unistd.h is a UNIX header, so it's not present in VC++; your best bet is probably to compile it using g++ in Cygwin (or mingw/msys). You could also look at this question for other suggestions.
I'm using flex 2.5.4 that comes from the GnuWin32 project, which doesn't check for YY_NO_UNISTD_H.
In my version, Flex looks for unistd.h only when being compiled as C++, so you can save yourself all this trouble if your yylval doesn't use any C++ constructs.
I had to use the STL in yylval (using a pointer to make it a POD type), so in order to make flex compile in C++ I created this simple unistd.h:
#include <io.h>
That's all it takes (actually, I could copy the unistd.h file that comes with GnuWin32, like flyontheweb suggests).
P.S. To wrap things up: in Bison I put yylval's required STL header files in %code requires {} and added the current directory to the INCLUDE paths in my makefile.
I am too late but anyway I will share my findings to save someone still looking for answer.
In my case having an empty unistd.h file in the location where compiler looks for headers works for me.
Well this post is old but I face the same problem and here is something that should work.
WinFlexBison
I ran into this problem recently after upgrading to Angular 14.
npm install -g latest-version
resolved my issue.
With the Visual Studio 2005 C++ compiler, I get the following warning when my code uses the fopen() and such calls:
1>foo.cpp(5) : warning C4996: 'fopen' was declared deprecated
1> c:\program files\microsoft visual studio 8\vc\include\stdio.h(234) : see declaration of 'fopen'
1> Message: 'This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
How do I prevent this?
It looks like Microsoft has deprecated lots of calls which use buffers to improve code security. However, the solutions they're providing aren't portable. Anyway, if you aren't interested in using the secure version of their calls (like fopen_s), you need to place a definition of _CRT_SECURE_NO_DEPRECATE before your included header files. For example:
#define _CRT_SECURE_NO_DEPRECATE
#include <stdio.h>
The preprocessor directive can also be added to your project settings to effect it on all the files under the project. To do this add _CRT_SECURE_NO_DEPRECATE to Project Properties -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions.
Well you could add a:
#pragma warning (disable : 4996)
before you use fopen, but have you considered using fopen_s as the warning suggests? It returns an error code allowing you to check the result of the function call.
The problem with just disabling deprecated function warnings is that Microsoft may remove the function in question in a later version of the CRT, breaking your code (as stated below in the comments, this won't happen in this instance with fopen because it's part of the C & C++ ISO standards).
This is just Microsoft being cheeky. "Deprecated" implies a language feature that may not be provided in future versions of the standard language / standard libraries, as decreed by the standards committee. It does not, or should not mean, "we, unilaterally, don't think you should use it", no matter how well-founded that advice is.
If you code is intended for a different OS (like Mac OS X, Linux) you may use following:
#ifdef _WIN32
#define _CRT_SECURE_NO_DEPRECATE
#endif
I'am using VisualStdio 2008.
In this case I often set Preprocessor Definitions
Menu \ Project \ [ProjectName] Properties... Alt+F7
If click this menu or press Alt + F7 in project window, you can see "Property Pages" window.
Then see menu on left of window.
Configuration Properties \ C/C++ \ Preprocessor
Then add _CRT_SECURE_NO_WARNINGS to \ Preprocessor Definitions.
Consider using a portability library like glib or the apache portable runtime. These usually provide safe, portable alternatives to calls like these. It's a good thing too, because these insecure calls are deprecated in most modern environments.
If you want it to be used on many platforms, you could as commented use defines like:
#if defined(_MSC_VER) || defined(WIN32) || defined(_WIN32) || defined(__WIN32__) \
|| defined(WIN64) || defined(_WIN64) || defined(__WIN64__)
errno_t err = fopen_s(&stream,name, "w");
#endif
#if defined(unix) || defined(__unix) || defined(__unix__) \
|| defined(linux) || defined(__linux) || defined(__linux__) \
|| defined(sun) || defined(__sun) \
|| defined(BSD) || defined(__OpenBSD__) || defined(__NetBSD__) \
|| defined(__FreeBSD__) || defined __DragonFly__ \
|| defined(sgi) || defined(__sgi) \
|| defined(__MACOSX__) || defined(__APPLE__) \
|| defined(__CYGWIN__)
stream = fopen(name, "w");
#endif
For those who are using Visual Studio 2017 version, it seems like the preprocessor definition required to run unsafe operations has changed. Use instead:
#define _CRT_SECURE_NO_WARNINGS
It will compile then.
Many of Microsoft's secure functions, including fopen_s(), are part of C11, so they should be portable now. You should realize that the secure functions differ in exception behaviors and sometimes in return values. Additionally you need to be aware that while these functions are standardized, it's an optional part of the standard (Annex K) that at least glibc (default on Linux) and FreeBSD's libc don't implement.
However, I fought this problem for a few years. I posted a larger set of conversion macros here., For your immediate problem, put the following code in an include file, and include it in your source code:
#pragma once
#if !defined(FCN_S_MACROS_H)
#define FCN_S_MACROS_H
#include <cstdio>
#include <string> // Need this for _stricmp
using namespace std;
// _MSC_VER = 1400 is MSVC 2005. _MSC_VER = 1600 (MSVC 2010) was the current
// value when I wrote (some of) these macros.
#if (defined(_MSC_VER) && (_MSC_VER >= 1400) )
inline extern
FILE* fcnSMacro_fopen_s(char *fname, char *mode)
{ FILE *fptr;
fopen_s(&fptr, fname, mode);
return fptr;
}
#define fopen(fname, mode) fcnSMacro_fopen_s((fname), (mode))
#else
#define fopen_s(fp, fmt, mode) *(fp)=fopen( (fmt), (mode))
#endif //_MSC_VER
#endif // FCN_S_MACROS_H
Of course this approach does not implement the expected exception behavior.
I also got the same problem. When I try to add the opencv library
#include <opencv\cv.h>
I got not a warning but an error.
error C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:\program files (x86)\opencv\build\include\opencv2\flann\logger.h
I also used the preprocessor directives as mentioned. But that didn't solve the problem.
I solved it by doing as follows:
Go to Properties -> C/C++ -> Precompiled Headers -> Choose Not Using Precompiled Headers in Precompiled Header.