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.
Related
According to cppreference [[deprecated("message string")]] we should be able to use the symbol but in VS results in error instead.
For example I wan't to issue a warning for ANSI methods in UNICODE builds and vice versa:
#ifdef UNICODE
[[deprecated("This method does not work well in UNICODE builds")]]
#endif // UNICODE
void f() {}
compiler doesn't let me compile, but standard says the attribute should allow usage but issue a warning message.
How to resolve this?, btw. my project is set to maximum conformance with the standard.
What ever the reason for VS going against the standard, is there a better way to issue a warning for above case?
Very much late to the party, but this cost me a couple of hours this morning.
By default, Visual Studio and the sdl (Security Development Lifecycle) compile flag treat
[[deprecated]] as an error. Whether or not you agree with this or not, that's how they do it.
To fix this go to Configuration Properties -> C/C++ -> Command Line and add /sdl /w34996
The /wX part represents the severity of the warning, and the rest is the error you want to report as a warning.
I hope this saves people some time.
I was able to get the compiler to treat [[deprecated]] as a warning by adding
/w34996
to the compiler options, as suggested in the responses in following link
https://developercommunity.visualstudio.com/content/problem/786502/cant-treat-deprecated-warning-as-warning-with-wx.html
is there a better way to issue a warning for above case?
There's no other way of warning about usage of a function than deprecation attribute in standard C++ at least that I know of.
Msvc has other alternatives such as #pragma deprecated(f), but those are not better.
How to resolve this?
Assuming you haven't configured your compiler to treat warnings as errors, you could proceed with writing a bug report to the maintainers.
I haven't tested it with Visual Studio, but in my case the following helped and probably is more generic:
On that error usually warnings are treated as errors with the compiler flag -Werror, that is automatically set in Visual Studio. That is the reason way a class or function marked with [[deprecated]] results in an error. To avoid explicitly that error and output it just as a warning, the compiler flag -Werror -Wno-error=deprecated-declarations can be set. In CMake it would look like:
add_compile_options(-Werror -Wno-error=deprecated-declarations)
The same case from the strikethrough case down here. I have a deprecated function call, and it gives an error. I want to ignore it for now. I can use #undef but I prefer using a "-Wno-deprecated" compilation flag, but for some reason I stil get the same error.
I have two modules with calls to the depracted functoin:
SSH_DEPRECATED LIBSSH_API int ssh_get_pubkey_hash(ssh_session session, unsigned char **hash);
// SSH_DEPRECATED == __attribute__ ((deprecated))
// as can be seen from:
// #define SSH_DEPRECATED __attribute__ ((deprecated))
Module A (the errornous module) ouputs a "is depracted" warning made error. I assumed the reason I saw only one error was because the compilation flags of A included -Werror. However, both of the modules include the same flag.
However, module B has something different. A includes libssh.h from arm-buidroot-linux-gnueabi where B includes that libssh.h and another copy of libssh.h (I assume the 2nd copy is a copy-paste of an older version of libssh.h).
I assumed that the SSH_DEPRECATED does not appear on the 2nd libssh.h, but I was wrong, so now I'm not what could be the reason.
Currently I got it to work by removing the -Werror in A, but this is bad since:
I don't know what is the root cause (i.e. how come it works in B)
I do want that flag [-Werror] (this can be solved by adding -Wno-deprecated
and then returning the -Werror, but I don't think of it as a good solution. More like a hack)
My question: What in A can cause this deprecated warning that does not apply in B?
Using powerpc-linux-gnu-g++ (Sourcery G++ Lite 4.3-74) 4.3.2
Note: I know that deprecated Indicates that the name or entity declared with this attribute is deprecated, that is, the use is allowed, but discouraged for some reason.
I have a __forceinline function that cannot be inlined when compiled as CLI (probably due to the specific restrictions to inlining that apply with .NET).
In debug, it is a warning and does not prevent me from building. But in release, it comes up as an error:
error C4714: function '...' marked as __forceinline not inlined
In the project configuration, Treat Warnings As Errors is set to No (/WX-), Treat Specific Warnings As Errors is empty (no value and no inherited value) and there is no /We option in the Command Line of the C/C++ section.
Thus, I don't understand why this warning comes up as an error.
And as it is an error it prevents me from building the project in release.
Do you have any clue on why this comes up as an error?
Any idea of how I could get rid of it, considering I cannot change the function nor its use (it comes from a library I'm using and I'd like not to alter)?
Thank you very much!
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 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