I downloaded zthreads (found here: http://zthread.sourceforge.net/) and tried to compile but I get this error from make:
MutexImpl.h:156: error: there are no arguments to 'ownerAcquired' that depend on a template parameter, so a declaration of 'ownerAcquired' must be available
MutexImpl.h:156: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
and then after that for every function in that source file I get this kind of error:
MutexImpl.h:167: error: there are no arguments to 'function' that depend on a template parameter, so a declaration of 'function' must be available
So I'm guessing it's a makefile error but I'm not for sure how to tell make to tell g++ to compile the files with -fpermissive. Does anyone know how to put that into the makefile (if that is the problem)?
CXXFLAGS += -fpermissive
Standard gmake convention is to use the CXXFLAGS variable to pass options to the C++ compiler. You can take advantage of that fact as well as a feature called "command-line overrides" to get your extra flag tacked onto the flags passed to g++ by invoking gmake this way:
make CXXFLAGS+=-fpermissive
I downloaded the source myself to verify that this works and found that it does, although there are still a bunch of other warnings emitted. You may wish to log a bug for these issues if you intend to continue using the library.
Hope this helps,
Eric Melski
I got rid of all these errors changing the code: for each line with that mistake, add this-> to the function that provokes the error. In the line you quote:
ownerAcquired must be changed by this->ownerAcquired
I hope this helps
Related
I am using clang-tidy as a "linter" tool in development. I started to integrate 3rd party software into my code and when I include their header files using:
-I/path/to/include
tons of errors are generated, I haven't even #include the headers yet.
error: too many errors emitted, stopping now [clang-diagnostic-error]
...
/path/to/include/wchar.h:81:1: error: unknown type name 'wint_t' [clang-diagnostic-error]
wint_t fgetwc(FILE *__stream);
^
/path/to/include/wchar.h:81:15: error: unknown type name 'FILE' [clang-diagnostic-error]
wint_t fgetwc(FILE *__stream);
^
...
I compile my program using:
/usr/bin/clang-tidy-4.0 /path/to/main.cpp -checks=-*,cppcoreguidelines* -- -lang-c++ -I/path/to/include -std=gnu++11 -Wall -Werror -O0 -g -D<define variables>
It seems that these "clang-diagnostic-errors" do not stop compilation, as it continues to compile and runs fine. Is there a flag to turn this error off/suppress it? I do not want to see it since I did not write these header files.
If I get rid of the argument -I/path/to/include everything compiles fine with no errors.
There is no way to ignore clang-diagnostic-error since it's basically a compiler error.
For clang-tidy to work the analyzed code needs to be compile-able by the clang backend to generate an AST(Abstract syntax tree).
The problem is you are including headers that cannot be compiled by clang (I'm guessing windows headers intended for MSVC).
I'm not sure if this would not break something later, so just at your own risk. I managed to "solve" this (because it was just a matter of having an error on the Problems list) on VSCode:
"C_Cpp.codeAnalysis.clangTidy.args": [
"--extra-arg=-ferror-limit=1"
]
This makes clang-tidy tell the compiler to throw just one error and give up. So clang-tidy will parse whatever is left.
I know was for VSCode, but the argument can be used in other IDEs.
It's a simple question really, and refers to Linux (as opposed to Windows or Mac).
How do you generate a warning message from the C or C++ compiler that must have the word 'suspicious' in it, and must refer to (-Wmain).
(update)
Thanks Boann - I got some of those Warnings, but I also got Error - error: ‘::main’ must return ‘int’.
The reason I'm asking this question is that a week ago my compiler (GCC 4.8.1) came out with this warning saying 'suspicious' and that it was caused by Wmain. So I put -Wno-main and the warning went away and it compiled fine. Just recently it has started complaining making it an actual Error and not compiling. So I'm kind of worried that somehow the mother ship has covertly updated my compiler over the internet, without me knowing, and changed it to treat it as error. (I was probably using 'int4' as the return type which I forever have typedef'd as signed long int.
I note there's -Wmain referenced in g++ man page so it must be for something, but what warning is there that isn't overruled by an error??
At offset 557284 (decimal) of the g++ executable I found "Warn about suspicious declarations of "main".
For what it's worth,
struct suspicious {};
int main(suspicious) {}
Output with g++ -Wall, GCC 4.8.2:
warning: first argument of 'int main(suspicious)' should be 'int' [-Wmain]
If you refer to the -Wmain parameter of GCC, you get the warning by giving main odd arguments, an odd return type, or giving it static linkage. This will do it:
static float main(float x) {
return 0;
}
Compiled with gcc -Wmain, it displays these warnings; they do not actually contain the word 'suspicious' though:
warning: return type of 'main' is not 'int'
warning: first argument of 'main' should be 'int'
warning: 'main' takes only zero or two arguments
warning: 'main' is normally a non-static function
I just downloaded the sources for gcc 4.8.1 and searched all relevant files for the word "suspicious".
There are a number of occurrences, but as far as I can tell, there's no way an error message for a C or C++ source file can contain the word "suspicious". It's possible but unlikely that there was a local modification.
Is it possible that you're mistaken about what the error message said? If you have a log containing the error message, please update your question to show the exact message your received.
If you're concerned that your compiler may have been updated without your knowledge, you might check the timestamp of the compiler executable and of any programs it invokes (use gcc -v to check that). But gcc itself doesn't automatically update itself. If you're using it on a system administered by someone else, automatic updates are to be expected. If you administer the system yourself, you may have configured it to update software without manual intervention; if so, that's not a gcc issue. I don't know what "mother ship" you're referring to.
I'm on Ubuntu 13.04 32 platform. I'm trying to compile awn with latest vala. I get following error message.
vala-utils.cc: In function 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)':
vala-utils.cc:358:6: error: no previous declaration for 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)' [-Werror=missing-declarations]
cc1plus: some warnings being treated as errors
How can I fix that error?
At the top of vala-utils.cc insert the function prototype:
void vala_array_destroy(gpointer array, gint array_length, GDestroyNotify destroy_func);
This will silence the warning which is causing the build to fail due to -Werror defined in the Makefile. Consider raising a pull request for the benefit of the maintainers.
Alternatively modify ln.89 in configure.ac and remove the -Werror to stop the warning failing the build.
This actually a warning, and a rather pedantic one at that.
It's saying that the global function awn::vala_array_destroy has not been declared beforehand. Usually this is a sign of a programmer's mistake, but from the source it seems to me that:
this function is only supposed to be used by awn::vala_array_free directly below it (in which case it should really have been given internal linkage), or
a declaration is available in some header elsewhere (in which case it's probably in the wrong header, as it ought to be in vala-utils.h).
The long and short of it is that the code is probably fine, if a little strangely designed. This case is being treated as an error because you have -Werror turned on for this warning, turning it into an error.
I don't know how you're building the library, but you could adjust the compiler flags to avoid this; by default, GCC does not emit this warning, nor turn it into an error. Alternatively, you could add the function declaration into vala-utils.h yourself. You should also take up the issue with the library's maintainers.
Update: I found the culprit on line 89 of AWN's configure.ac. You should definitely take this up with the library maintainers. I'd be amazed if this had not already been reported as a bug; I believe it was introduced in this revision.
For some reason gcc does not like when template parameter is a global namespace symbol, i.e.
TemplateClass<::GlobalSymbol>
It works when I do
TemplateClass< ::GlobalSymbol>
That is, gcc does not like to see <::
Is it possible to prevent without modifying sources (which are autogenerated)?
UPD: I don't want to modify sources. I found that -fpermissive seems to change this to a warning instead of error, but haven't found yet how to enable it from code (using pragmas for example).
UPD: Well, I found that
#pragma GCC diagnostic ignored "-fpermissive"
does the trick, anyway I accept the answer that helped me to find this out.
<: is a digraph which is equivalent to [, thus the error. Since you don't want to modify the code a workaround is to use -fpermissive command-line argument or pragma to G++ (it actually gives you a hint):
test.cpp:9:16: note: (if you use ‘-fpermissive’ G++ will accept your code)
With gcc 4.6 I get the following error:
graphs.cpp: In function ‘int main()’:
graphs.cpp:9:15: error: ‘<::’ cannot begin a template-argument list [-fpermissive]
graphs.cpp:9:15: note: ‘<:’ is an alternate spelling for ‘[’. Insert whitespace between ‘<’ and ‘::’
graphs.cpp:9:15: note: (if you use ‘-fpermissive’ G++ will accept your code)
So, -fpermissive is the way to go. [EDIT: I see now that you added that you already found this]
Else, since you mentioned that the sources are auto-generated, you could add a post processing step. For example using sed
sed -i 's,<::,< ::,g' filename.cpp
or something similar in e.g. python. But only if you are sure you never use <:: for something else.
When I compile a program using just
gcc code.c
There are no messages, and an output file is generated successfully. The outputted file works. However, when I try to the same cygwin installation's gcc compiler in an IDE (I've tried Netbeans and Dev-C++), I get the following errors
main.cpp:27: error: `exit' undeclared (first use this function)
main.cpp:27: error: (Each undeclared identifier is reported only once for each function it appears in.)
main.cpp:77: error: `write' undeclared (first use this function)
main.cpp:78: error: `close' undeclared (first use this function)
I don't see what's different. Why does it not compile?
OK, the issue was that in the IDE, the file had a .cpp extension, whereas when I was compiling from a terminal, it had a .c extension. So, my new question is why does it not compile when it's treated as a c++ file. Isn't C a subset of C++?
C++ is stricter then C. Where C allows you to call a function without a prototype, C++ does not allow this.
To solve the problem, you want to add:
#include <stdlib.h>
Also, when compiling at the command line. Make sure to use the -Wall flag so you'll get important warnings:
gcc -Wall code.c
The IDE is using fussier options to the compiler. You need to include some headers:
#include <stdlib.h> // exit()
#include <unistd.h> // close(), write()
The default options allow almost anything that might be C to compile. By the looks of it, the IDE sets '-Wmissing-prototypes' as one of the compiler options.
If you compile code with a C++ compiler, you must ensure that all functions are declared before use. C is sloppier (or can be sloppier) about that - it is recommended practice to ensure all functions are declared before being defined or referenced, but it is not mandatory. In C++ it is not optional.
There is a subset of C that is also a subset of C++; there are bits of C that are not C++, and there are many bits of C++ that are not C. In particular, an arbitrary C program is not, in general, a C++ program. For example, a C program may not declare 'exit()' and yet it can both use it and still compile. A C++ program must declare 'exit()' before it can user it and compile.
You will have to use g++ for compiling .cpp files.
One possible reason may be that the IDE is unable to access the include files, the cygwin gcc compiler may be expecting it in /usr/include(not sure), and the dev-cpp may not be able to access it.