I am trying to build node.js under eclipse. ( I want to use an IDE to step through the internals of node, so I can answer some questions). I am getting a compilation error I don't understand. Below are the 2 relevant lines from the source:
static uint64_t counter_gc_start_time;
counter_gc_start_time = NODE_COUNT_GET_GC_RAWTIME();
I replaced it with the (manually expanded) macro, thus;
counter_gc_start_time = (do { } while (false));
But I still get a compilation error:
/Users/concunningham/Documents/Node/node/src/node_counters.cc:81:30: error: expected expression
counter_gc_start_time = (do { } while (false));
I am compiling under OS/X, 10.13.4, using compiler flag -std=c++11.
Can anyone tell me what this line of code is supposed to do ?
If you look at node_counters.h
#ifdef HAVE_PERFCTR
#include "node_win32_perfctr_provider.h"
#else
...
#define NODE_COUNT_GET_GC_RAWTIME() do { } while (false)
#endif
When HAVE_PERFCTR is defined, node_win32_perfctr_provider.h is included instead of that define that will fail to compile. The definition for NODE_COUNT_GET_GC_RAWTIME(); is in node_win32_perfctr_provider.cc
I don't know this library, it is just what I see by looking at the files. Where and when HAVE_PERFCTR gets defined is beyond what I searched. But if you have the lib on your machine, the answer is there. I'd have to download it to know more. As jbp points out, this looks like some kind of windows thing.
Related
Trying to build Tink library (https://github.com/google/tink) with Bazel. Bazel installed, gcc version 7.2.0, Windows 10 x64. Visual C++ 2017.
At first, there were errors like "C++ compilation of rule '#boringssl//:crypto' failed" - I commented these lines (with compilation flags I think) in boringssl/BUILD file (sections boringssl_copts, boringssl_copts_c11) and they disappeared.
But after that, bazel said, that error is in errors.h file (https://github.com/google/tink/blob/master/cc/util/errors.h)
// from #include "absl/base/port.h"
#define PRINTF_ATTRIBUTE(string_index, first_to_check) \
__attribute__((__format__ (__printf__, string_index, first_to_check)))
// Constructs a Status object given a printf-style va list.
crypto::tink::util::Status ToStatusF(
crypto::tink::util::error::Code code, const char* format, ...)
PRINTF_ATTRIBUTE(2, 3);
} // namespace tink
} // namespace crypto
enter code here
Error C3646: unknown override specifier on line 32 (line with "PRINTF_ATTRIBUTE(2, 3);"). The most frightening thing is that in another files the same code (defining same attribute) is working.
There are another errors in this file, but mentioned is the first (and another are about the same line, so they are consequences of the first I guess).
I'm nearly a total newbie in cpp, but only cpp should be used, not java-version of library.
Thank you for your help, and sorry for possible misformatting and broken english - this is my first question here.
Unfortunately, we don't support Windows for now. It's something that we plan to support next year, please see our feature roadmap.
I hope this is an interesting question. I'm trying to find the source of an unresolved external symbol. I have debug code that uses a global file pointer if debugging is turned on. All of this debugging code is supposed to be protected by #ifdef, like:
#ifdef DO_XLL_DEBUG
fprintf(debugPointer, "hello\n);
...
#endif
When I define DO_XLL_DEBUG, all is well. If I undef DO_XLL_DEBUG, everything compiles (I do a rebuild all just in case), but it fails at the link step, not finding debugPointer.
So, the question is, is there an easy way to find where I failed to #ifdef around the debug code? I can think of several not so easy ways.
I'm using Visual Studio 2005. This is a C++ project.
Thanks!
[EDIT]
Thanks for all the suggestions. Turns out the problem was in someone else's code that is not part the corresponding project I'm working on in Linux (where I do most of my work), so no wonder I didn't find it right away.
Just define some incompatible debugPointer and let the compiler point you at all the places where it's accidentially used or redefined. Maybe like this:
#ifndef DO_XLL_DEBUG
#define debugPointer static_assert(false,"damn it!");
#endif
(given that you don't have other variables, parameters, etc. which are called debugPointer)
I encounter this error when I am trying to compile a c++ code via a Makefile.
error: expected initializer before ':' token
I have checked the compatibility of the compiler of my system
I also checked the paths etc. I also did some test; such as adding a semicolon after the 2nd declaration of class but didnt work. I have little to no experience with c++, the script is not even written by me; it is part of vtk library (Visualisation toolkit). Part of the script from where
the error generates is:
#ifndef __vtkProcessObject_h
#define __vtkProcessObject_h
#include "vtkAlgorithm.h"
class vtkDataObject;
class VTK_FILTERING_EXPORT vtkProcessObject : public vtkAlgorithm
{
public:
vtkTypeRevisionMacro(vtkProcessObject,vtkAlgorithm);
void PrintSelf(ostream& os, vtkIndent indent);
I get the error in line 8.
Probably it is something really straightforward, but as I said I have no clue how this language works.
The VTK_FILTERING_EXPORT macro is defined in a header, and is largely there for Windows and/or GCC symbol visibility. You don't mention what version of VTK you are compiling, but using CMake to generate the Makefiles would ensure the correct include paths are set up. If this is Linux, and the GCC visibility functionality has not been activated you could define the macro to nothing, but I suspect you would hit many other issues once you got past this point in the compilation.
I have the following very simple application that compiles and runs fine:
EDIT: changed the example to be simpilar to end confusion of the real issue
int main() {
return 0;
}
As soon as I add #include <string> (and not even reference std::string), it fails to compile and I get the following error:
/usr/include/c++/4.1.2/bits/allocator.h:82 error: expected template-name before '<' token
Along with about 456 other, similar errors.
Any ideas? Thanks!
UPDATE:
Line 82 of /usr/include/c++/4.1.2/bits/allocator.h references the template __glibcxx_base_allocator at the location of the error. That template is defined in bits/c++allocator.h. When I search the system for that file, I get 3 hits, but none of them are in /usr/include/c++/4.1.2/bits/ as one would expect.
I have version 3.1.6, 4.1.1, and 4.3.2, but not 4.1.2 as the rest of the includes I am using. I am not sure which one is being used (if any, however, I don't get any error for an unknown file), but it seems the problem may stem from this.
The problem appears to be the installed development packages are not correct or incomplete (not to be confused with corrupt). Forcing g++ to use different include versions corrects that:
g++ -nostdic++ hello.cc -o hello -I/usr/include/c++/3.4.6
All the alternative directories (4.1.1, 4.1.2 and 4.3.2) are incomplete causing inappropriate files to be included causing the unusually errors. For example:
/usr/include/c++/4.1.2/bits/allocator.h requires __glibcxx_base_allocator located in bits/c++allocator.h which is being included from either /usr/include/c++/4.1.1 or /usr/include/c++/4.3.2 and appear to be incompatible. Forcing the compiler to use the only complete set of includes rectifies this.
Almost certainly g++ is detecting .cc as a C source file, not C++ and passes it through to gcc instead of compiling as C++. You can easily test by renaming your file to hello.C. There's also a language parameter to g++ you can use.
EDIT: This seems to work fine in g++ 4.2 with a .cc extension so that might not be it. Do you have any other headers included you aren't showing us? They could be interfering with <string>.
EDIT2: Alternatively your headers might not be set up right. Does this work:
#include <string>
int main()
{
return 0;
}
Errors like this have been heard of to occur when the C++ standard library headers are corrupted/not fully installed – maybe there is even a message referring to a missing include among your 456 other errors.
In any case, make sure that libstdc++-devel, resp. the package containing the C++ standard library header files of your distribution, is properly installed.
Check your include path. The paths can be specified as environment variables or specified on the command line. You could be using an include file from a different compiler or different version of the same compiler.
Also, try using <cstdio> rather than <stdio.h>.
Another suggestion: change <> to "".
This could be error caused at preprocess stage. Just preprocess your cpp file by passing flag -E to gcc and Look at the place the compiler complains.
I have a CPP source file that uses #if / #endif to compile out completely in certain builds. However, this generates the following warning.
warning LNK4221: no public symbols found; archive member will be inaccessible
I was thinking about creating a macro to generate a dummy variable or function that wouldn't actually be used so this error would go away but I want to make sure that it doesn't cause problems such as using the macro in multiple files causing the linker to bomb on multiply defined symbols.
What is the best way to get rid of this warning (without simply suppressing the warning on the linker command line) ?
FWIW, I would be interested in knowing how to do it by suppressing the warning on the linker command line as well but all my attempts there appear to be simply ignored by the linker and still generate the error.
One other requirement: The fix must be able to stand up to individual file builds or unity build (combine CPP file builds) since one of our build configurations is a bulk build (like a unity build but groups of bulk files rather than a single master unity file).
Use an anonymous namespace:
namespace { char dummy; };
Symbols within such namespace have external linkage, so there will be something in the export table. On the other hand, the namespace name itself will be distinct (you can think of it as "randomly generated") for every translation unit, so no clashes.
OK, the fix I am going to use is Pavel's suggestion with a minor tweak. The reason I’m using this fix is it’s an easy macro to drop in and it will work in bulk-builds / unity-builds as well as normal builds:
Shared Header:
// The following macro "NoEmptyFile()" can be put into a file
// in order suppress the MS Visual C++ Linker warning 4221
//
// warning LNK4221: no public symbols found; archive member will be inaccessible
//
// This warning occurs on PC and XBOX when a file compiles out completely
// has no externally visible symbols which may be dependant on configuration
// #defines and options.
#define NoEmptyFile() namespace { char NoEmptyFileDummy##__LINE__; }
File that may compile out completely:
NoEmptyFile()
#if DEBUG_OPTION
// code
#endif // DEBUG_OPTION
(Though the discussion is already old and I cannot comment directly #Adisak's answer), I guess some additional macro expansion magic is needed for this to work:
#define TOKENPASTE(x, y) x ## y
#define TOKENPASTE2(x, y) TOKENPASTE(x, y)
#define NONEMPTY_TRANSLATION_UNIT char TOKENPASTE2(NoEmptyFileDummy, __LINE__);