In system:
Fedora 21
Ruby 2.1.7
GCC 4.9.2
I follow the instructions for installing simstring but afer
$ruby extconf.rb
when trying to make and make install, I got an error:
cc1plus: some warnings being treated as errors
Makefile:217: recipe for target 'export_wrap.o' failed
make: *** [export_wrap.o] Error 1
And the entire log of this error is bellow
Error Log
I searched about this error but all of replies are about how to disable Werrors and configure with ignoring werrors.
Is there any solution?I think something not mentioned but i don't know what..
I searched about this error
That's not an error. It's a notification. It notifies that some warnings have been treated as errors.
I searched about this error but all of replies are about how to disable Werrors and configure with ignoring werrors. Is there any solution?
You answered your own question. If the source code of the program generates warnings, and if the compiler is asked to treat warnings as errors, then the compiler will refuse to compile the program. Complete list of possible solutions are:
Fix the source code to not generate warnings. This is a very good idea.
Stop asking the compiler to treat warnings as errors (this is the solution that you already found). You should still fix the code to not generate a warning.
Ask the compiler to ignore the warnings entirely. This is usually a bad idea unless you understand the warning and know what you're doing.
Related
When I compile a project using cross compiler,I come across the following error:
internal compiler error: in decode_addr_const, at varasm.c:2632
Where can I find the varasm.c file?I searched the project directory and cross compiler directory,but I didn't find it.
Thanks for helpping,Light
The compiler maker has that file, and probably won't give it to you.
But as it seems to be an error in the compiler, you can either contact them / file a bug report, or try to avoid the error by changing your code a bit (which is a guessing game, as you don't know how you made it run into the error). Or use another compiler, if there are choices.
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!
I am currently trying to use the ZXing Library for an iOS Project. However I can't even get the sample Projects to work.
The ScanTest Project, as well as the ones that I created myself throw the following error in the BinaryBitmap.cpp file.
In file included from /Volumes/Macintosh HD/Users/Tim/Downloads/zxing-2.1/iphone/ZXingWidget/../../cpp/core/src/zxing/BinaryBitmap.cpp:20:
../../cpp/core/src/zxing/BinaryBitmap.h:33:7: error: private field 'cached_y_' is not used [-Werror,-Wunused-private-field]
int cached_y_;
^
1 error generated.
I searched on Google and Stackoverflow, but have not found a solution for the problem.
I have tried it with both the current stable release of XCode and the beta.
I don't know if anybody else has got this problem too, but any help would be greatly appreciated.
This is clang, right? You can read about the relevant compiler options here.
The error message is telling you which compiler flags are relevant.
-Wunused-private-field means you get warnings about private member fields of classes (or structs, ...) that are not used anywhere. The warning is because you probably did mean to use them. This would not normally stop the compilation, but...
-Werror turns warnings into errors. A lot of people use this option to force themselves to write very clean code. Taking this one out should be enough.
I am attempting to compile a qt project using the following sequence of commands
> qmake -project
> qmake
> make
In the make process I keep getting the following error popping up.
{standard input}: Assembler messages:
{standard input}:21385: Fatal error: can't close Transfer.o: Input/output error make: *** [Transfer.o] Error 1
The same error is coming up for multiple classes, Originally I thought it was qt related because it first appeared in when the compiler tried to make a moc file. But now it seems to be popping up in other classes in my project.
I don't really know where to look for problems because I don't understand the error, Could anybody point me in the right direction? I'm happy to post code as needed.
I think this is related to some part of the code that assembler is not able to decode it.
I am trying to compile a c++ program in Linux, using the command in the shell
$ g++ -Wall *.cpp -o prog
and for some reason it keeps on giving me a weird error:
g++: Internal error: Bus error (program cc1plus) Please submit a full
bug report. See for
instructions.
I searched the net for this bus error, and it says that it has to do with something about accessing illegal memory.
Can someone maybe clarify things a bit more for me?
This error message is telling you that there's a bug in the g++ compiler itself.
Try to narrow it down by removing bits and pieces of your source file until the problem goes away. You're not trying to fix your program, you're just trying to find the part that is breaking the compiler. Once you've found it, you can either give a better bug description or you can change your code to work around it.
Or just download the latest version of the g++ compiler and hope that it's already fixed.
Your problem is not in your code, is the compiler (g++) that is crashing and producing that Bus Error, it's possible you have an outdated version of such compiler and need to update, or you're lucky and found a real bug in g++.
I would try compiling each source file separately, to check what part of the source code triggers the error.