#pragma pack won't compile? - c++

I'm trying to compile some downloaded source which contains lots of:
142 #ifdef __cplusplus
143 #pragma pack(1)
144 #endif
but I get the following error and it won't compile:
src/globals.h:143:16: error: expected declaration before end of line
mingw32-make: *** [obj/main.o] Error 1
I'm using a makefile downloaded with the rest of the source to compile it.
what do I need to do to get this to compile?
EDIT:
The source code is the code for KeeperFX available from google code.

As I know #pragma directives belongs to the Microsoft C++ Compiler. GCC supports some of these directives, but MinGW does not.

You could use GCC __attribute__((packed)) extension.

While I have absolutely no idea why GCC picked on pragma pack to highlight it's issue the actual problem was that it was trying to compile a Version.h resource (Version resource information) as code. The compile was failing and just decided to spit out a completely irrelevant error.

Related

Turn warnings into error only within supplied diff

At a company I used to work at, the build system was set up to turn warnings into errors only within changed code. It worked by supplying generating a diff (typically between the branch you were trying to merge and master and then supplying that diff to some compilation tool, and the tool would produce warnings only within the supplied diff.
This was great as it allowed you to e.g. deprecate some function, and have the build system prevent people from introducing new uses of that function, and then remove old usages of that function later.
Unfortunately, I didn't look at the setup closely enough before I left the company, and don't know how to replicate it. My question: How can I replicate this setup?
Question is tagged Clang but I would also be interested in answers that use tooling from other compilers.
If I had to implement that, my first idea would be:
Get merged file.
Analyze diff to figure out which regions were changed.
Generate a new file and inject #pragma directives1 that locally enable/disable warnings around the changed regions.
Also inject #line directives to make it look like warnings/errors are coming from the original file.
Compile modified file and save compiler warnings/errors.
Delete modified file.
Present compiler diagnostics to the user.
1 E.g. https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas for GCC.
Clang supports GCC's #pragma diagnostic.
For example:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
// ... changed code here ...
#pragma GCC diagnostic pop
MSVC also has something similar:
#pragma warning(push, 3)
// ... changed code here ...
#pragma warning(pop)

How to compile Boost with an older std of C++? (C++03 in particular)

I am working in a project dependent of Boost (http://kratos-wiki.cimne.upc.edu/index.php/Main_Page), this project currently only supports C++03. With the last update of gcc++ (v.5) the C++11 has become the default std, technically I solved the problem modifying the CXX_FLAGS adding:
-std=c++03
The problem comes with the Boost library, which I am not able to compile with the C++03 std (I think, I don't know how to check with which std I have compiled). I tried employing the following command to compile Boost:
./b2 install stage --with-python --with-serialization cxxflags="-std=c++03"
I have tried too modify the Jamroot file, adding the following lines:
<toolset>gcc:<cxxflags>-std=gnu++03
<toolset>clang:<cxxflags>-std=c++03
But the problem persist, when I compile the whole project I obtain the following kind of warning (several times):
/usr/local/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated
# pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
That's why I suspect that my changes do not take effect.
Thank you very much for your help
I think you can safely ignore those warnings for now. I am compiling boost 1_60_0 with gcc 5.2.1 and std=c++11, and I get the same warnings. There is a ticket on it, but meanwhile it hasn't caused me any problems at this time. I commented out the two [#pragma warning] lines in the boost code, so I don't get a lot of distracting output in my build:
boost/type_traits/detail/template_arity_spec.hpp line 13:
// noisy: # pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
boost/type_traits/detail/bool_trait_def.hpp line 18:
// noisy: # pragma message ("NOTE: Use of this header (bool_trait_def.hpp) is deprecated")
UPDATE The problem still exists in boost 1.61.0. I used the same exact fix again.

How to add predefine macro for nvcc?

I am currently compiling a Qt project which integrates OpenMesh and CUDA together. Since I have to use nvcc to compile the project, I found an error from the OpenMesh:
J:\OpenMesh2.4\include\OpenMesh/Core/System/compiler.hh(109) : fatal error C1189:
#error : "You have to define _USE_MATH_DEFINES in the compiler settings!"
Since the compiler is nvcc not vc compiler, even I add the macro in the "preprocessor definitions", the error still appears. I just wonder if there is a way to add this macro for the nvcc?
I also tried to manually add this macro in one of my header which include the open mesh headers. The above error is gone but the compile gives another strange error about the source code of openmesh.
Found the solution: add -D followed by the macro in the nvcc flag...

compilation error with nvcc and BOOST library

nvcc throws
/usr/include/boost/concept/detail/has_constraints.hpp:29: error: ‘&’ cannot appear in a constant-expression
/usr/include/boost/concept/detail/has_constraints.hpp:29: error: template argument 2 is invalid
the has_constraints.hpp already has some suspicious code in it:
#if BOOST_WORKAROUND(__SUNPRO_CC, <= 0x580)
// Work around the following bogus error in Sun Studio 11, by
// turning off the has_constraints function entirely:
// Error: complex expression not allowed in dependent template
// argument expression
inline no has_constraints_(...);
#else
template <class Model>
inline yes has_constraints_(Model*, wrap_constraints<Model,&Model::constraints>* = 0);
inline no has_constraints_(...);
#endif
Question: Is this a nvcc - boost incompatibility, or could there be something wrong with my code?
Why do you have the "&" before "Model::constraints"? I would think that's the problem. (// it's not apparently)
EDIT:
http://forums.nvidia.com/index.php?showtopic=182890 talk about this issue and have some hack work arounds
http://forums.nvidia.com/index.php?showtopic=150025
EDIT2:
Well, after running around this for a while, this is what I'm sticking with:
http://forums.nvidia.com/index.php?showtopic=215470 "There is a known compatibility issue with boost and nvcc. A work around is to split the sources such that you compile the cuda code with nvcc and the boost code with the host compiler." by Justin Luitjens in the Group: NVIDIA Employees
Try it out, but if you can't make it work, compile separately, and then link them.
I have a patch here http://code.google.com/p/asadchev/source/browse/trunk/projects/boost/boost-1.46.0.nvcc.patch
Perhaps you can see what is changed and fix your code likewise
Be aware that the source is seen by both, gcc-like and egg-like compiler parts.
What we did at the end was to turn has_constraints_ off as in the example quoted in the question for Sun Studio 11

C++ Disabling warnings on a specific include

I'm wondering if there's a way to disable all warnings on a specific file (for example, using a preprocessor directive).
I'm using CImg.h and I want to get rid of the warnings involving that code.
I'm compiling both with VS (the version for Windows) and gcc (the Linux one), so I would like to have a generic way...
Thanks!
You can do it using #pragma in Microsoft compiler:
http://msdn.microsoft.com/en-us/library/2c8f766e%28VS.80%29.aspx
Something like this:
#pragma warning (push, 0)
//....header file
#pragma warning (pop)
Can't help you with gcc compiler, some info here: Selectively disable GCC warnings for only part of a translation unit?
EDIT EDIT Try push, 0.
Look into #pragma warning.