I am trying to write some C++ code (using the C++ API) for Festival and am getting stuck while trying to compile. Here is how I invoke g++:
g++ -Wall -pedantic -I../ -I../speech_tools/include/ helloFestival.C -o h -L../festival/src/lib/libFestival.a -L../speech_tools/lib/libestools.a -L../speech_tools/lib/libestbase.a -L../speech_tools/lib/libeststrings.a |& tee festival.runLog
The error I get is:
In file included from ../speech_tools/include/EST.h:48,
from ../festival/src/include/festival.h:47,
from helloFestival.C:4:
../speech_tools/include/EST_String.h:50: error: declaration of ‘void abort()’ throws different exceptions
/usr/include/stdlib.h:513: error: from previous declaration ‘void abort() throw ()’
The offending line in EST_String.h would be:
extern "C" void abort(void);
The main() function I have used can be found here: festvox.org/docs/manual-1.4.3/festival_28.html#SEC133
The compilation and linking instructions given here are the ones I have used.
I have looked this problem on the net and some of the solutions suggest that it maybe because of backward compatibility, or calling an abort() from within a destructor etc. My questions are:
How do I get rid of this?
Why do I see this error?
You see this error because the abort() function in speech_tools conflicts with the standard-mandated abort() function. There's probably no really good, clean way to fix this. If you have written EST_String.h yourself, name the function differently.
If not, don't include stdlib.h and EST_String.h in the same file. Yes, that's limiting and bad, but you are in a crappy situation here.
It is a very basic c error. The two definition for abort are conflicting I would try to remove the line in EST_String.h and maybe add a #include <stdlib.h> and see if it compiles after that.
I don't suppose including the stdlib header is the problem. However, you might get better mileage from including either <cstdlib> or <stdlib.h> as the very first header in your translation units
Rationale: just in case the definition in <cstdlib> adds the no-throw declspec.
So I really suggest to ... just fiddle with that. If it doesn't work either way (make sure you don't have conflicting includes or stale precompiled headers), I suggest just removing the offending declarion in EST_String.h
This is still a problem today. As a workaround, i'm using this piece of code.
It's ugly and hacky, but gets it working:
extern "C" void abort_est() { abort(); }
#define abort abort_est
#include <festival.h>
#undef abort
Related
I am trying to compile an application from source, FlyWithLua, which includes the sol2 library.
I am following the instructions but when I run cmake --build ./build I get the following error:
In file included from /home/jon/src/FlyWithLua/src/FloatingWindows
/FLWIntegration.cpp:10:
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp: In lambda function:
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp:7194:59:
error: ‘numeric_limits’ is not a member of ‘std’
7194 | std::size_t space = (std::numeric_limits<std::size_t>::max)();
There are several other errors on the same line after this, but I guess they might just go away if I can solve this one.
there are several similar issues with the solution to add the following includes to the .hpp file
#include <stdexcept>
#include <limits>
the sol.hpp file includes the following imports:
#include <stddef.h>
#include <limits.h>
https://sol2.readthedocs.io/en/latest/errors.html gives some hints about the why the compiler might not recognize these includes:
Compiler Errors / Warnings
A myriad of compiler errors can occur when something goes wrong. Here
is some basic advice about working with these types:
If there are a myriad of errors relating to std::index_sequence, type traits,
and other std:: members, it is likely you have not turned on your C++14 switch for
your compiler. Visual Studio 2015 turns these on by default, but g++ and clang++
do not have them as defaults and you should pass the flag --std=c++1y or
--std=c++14, or similar for your compiler.
the src/CMakeList.txt file has the following line:
set(CMAKE_CXX_STANDARD 17)
I'm only faintly familiar with C/C++ and this all seems very complicated to me, but I'm hoping that there might be an easily recognizable cause and solution to this to someone more skilled.
cat /etc/*-release gives
DISTRIB_RELEASE=21.10
DISTRIB_CODENAME=impish
DISTRIB_DESCRIPTION="Ubuntu 21.10"
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp:7194:59:
error: ‘numeric_limits’ is not a member of ‘std’
7194 | std::size_t space = (std::numeric_limits<std::size_t>::max)();
This error message implies that src/third_party/sol2/./upstream/sol.hpp header uses std::numeric_limits, but also that std::numeric_limits hasn't been defined. The simplest explanation for that is that the header that defines std::numeric_limits hasn't been included. In such case, the solution is to include the header that defines std::numeric_limits.
the sol.hpp file includes the following imports:
#include <stddef.h>
#include <limits.h>
This confirms the problem. Neither of those headers define std::numeric_limits.
https://sol2.readthedocs.io/en/latest/errors.html gives some hints about the why the compiler might not recognize these includes:
Those hints may apply to some other cases, but not this one. std::numeric_limits has been part of the C++ standard since the beginning, so language version has no effect on its existence.
Conclusion: According to the quoted error message, sol.hpp uses std::numeric_limits which is defined in the header <limits>, but according to you, it doesn't include that header. If this is the case, then this is a bug in the sol.hpp file. Correct solution would be to fix the sol.hpp file by including <limits> in that file before using std::numeric_limits.
I have two short files located in the same directory. The contents of each are shown below.
File test.cpp contains:
int main()
{
#include <test.h>
}
File test.h contains:
syntax_error
Upon compiling test.cpp with either g++ or clang++, I get an error which is expected.
test.cpp:3:11: error: 'test.h' file not found with <angled> include; use
"quotes" instead
#include <test.h>
^~~~~~~~
"test.h"
However, I also get a second error which seems to contradict the first error.
In file included from test.cpp:3:
./test.h:1:1: error: use of undeclared identifier 'syntax_error'
syntax_error
^
Essentially, the first error reports that the compiler cannot find the file test.h, and the second reports a syntax error in the file that the compiler reported it could not find.
These are the only two errors generated.
I understand why the compiler reports the first error and that I should use quotes with #include in this case. Why, though, does the compiler say it cannot find the file when it clearly has found it? And, why would it continue to report errors in the "unfound" file?
This is a feature, not a bug.
The idea is that if the error is trivial (like a missing semicolon), then the compiler will try to continue compiling as if you had already fixed the error. This enables you to fix multiple errors in one go. This is especially useful when compiling your code takes a long time.
Imagine fixing a missing semicolon, recompiling for five hours, just so that the compiler finds another missing semicolon. And then you have to recompile again. That would be very frustrating, no?
Basically, the compiler will try to recover from any errors as far as it is able to, to be able to report as much errors as possible. Most compilers have a flag for this.
Why, though, does the compiler say it cannot find the file when it clearly has found it?
The compiler found the file yes, that's why it gave you a hint to use "" instead of <>. If it hadn't, it might not have given you the hint. Still, the compiler is not allowed to compile your code correctly, because your code is ill-formed.
As an analogy, just because the compiler found a missing semicolon, that doesn't mean that it can just compile the code with that missing character (if it tries to be Standards compliant). It will however recover and try to find other errors, if any.
I'm trying to use shared_ptr from std:: in c++ 11 so I'm including which apparently uses typeinfo. The problem is that I'm getting the error bellow.
In file included from /usr/include/c++/4.8/memory:71:0,
from /home/dev/openclTest/modules/Quant.cpp:10:
/usr/include/c++/4.8/typeinfo:39:37: error: expected ‘}’ before end of line
#pragma GCC visibility push(default)
From what it sounds like, this is a known bug listed here:
https://lists.debian.org/debian-gcc/2007/09/msg00497.html
Anyway, I was hoping I didn't have to use boosts library, so if there's a quick fix anyone knows about, please let me know. I'm using cmake and g++ to build the project.
Thanks!
I just had a similar issue with GCC 4.9.2. It seems to be the common error message in case you forget some braces in a file included prior to typeinfo.
I did not find the code to exactly reproduce the message but got something very similar using this minimal test:
test.cpp:
{
#include <typeinfo>
int main() {}
I guess it is likely the same error as yours as it happens in very different GCC versions. In case it really is the same issue, check your other includes.
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.
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.