I am building a C program with no problem on CentOS using provided Makefiles in its distro package. However I need to modify source files and I need to use iqxmlrpc and boost libraries for that purpose. I have changed Makefiles respectively but when I want to build the package I get following error:
../src/libiqxmlrpc/libiqxmlrpc/except.h:9:21: error: stdexcept: No such file or directory
../src/libiqxmlrpc/libiqxmlrpc/except.h:10:18: error: string: No such file or directory
In file included from ../src/libiqxmlrpc/libiqxmlrpc/libiqxmlrpc.h:17,
from redir.c:2617:
../src/libiqxmlrpc/libiqxmlrpc/except.h:14: error: expected '=', ',', ';', 'asm' or 'attribute' before 'iqxmlrpc'
... followed by many other errors ...
I believe above error is because iqxmlpc is written in c++ and gcc is treating it as C so I tried followings:
1) Use g++
2) Use gcc -x c++
Doing above, error changes to a lot of following in many header files:
error: expected ‘,’ or ‘...’ before ‘this’
All the lines that compiler is complaining somehow have this or delete keywords as parameter. See below:
int net_route(struct in_addr *dst, int delete);
or
extern int gad_new(struct gad_t **this)
Do you have any idea how can I fix this? Frankly, I have no idea what using 'this' or 'delete' mean as parameters. Are these only parameter names that gcc ignores the rule that we can not use keywords?
------------------------------
BTW, original programmer have used nested functions all across his code which were compiled fine using gcc. when I switch to g++, compiler complains about function-definition not being allowed in another function. Is there any way I can tell g++ to ignore this error?
Those weren't keywords in C, they are in C++.
You will have to rename those parameters before the code will compile in C++.
You may run into other porting issues related to C++'s stricter type checking before you are done.
Another option is to keep the C and C++ code in separate files, and use extern "C" in the C++ code for every function call that must cross the boundary. Since your C code extensively uses nested functions and other features not permitted in C++, this is probably your quickest approach.
this and delete are reserved keywords in C++ (not in C though) . You cannot use these as variable names when compiling with g++.
Its better to use different variable names in parameters and then compile with g++.
Related
I have to compile generated C code that #includes C++ headers and it get it to work on Linux, OS X and Windows. I put the #includes myself to be able to interact with C++ code from it.
The C code however is such that a strict compiler would catch errors that could be treated as warnings. I want to pass these off as warnings as most of this is generated code which I don't have control over.
Here are my attempts to compile it (I use CMake, btw):
(I use these flags: -Wno-write-strings -Wno-error -fpermissive)
Treat the entire project as C++ code: works on Linux (with g++) but on OS X I get:
With Clang:
error: assigning to 'char *' from incompatible type 'const char *'
With g++:
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:18:no such instruction: `vmovdqa LC0(%rip), %xmm3'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:19:no such instruction: `vmovdqa LC1(%rip), %xmm2'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:20:no such instruction: `vmovdqu (%rsi), %xmm7'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:21:no such instruction: `vmovdqu 16(%rsi), %xmm8'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:22:no such instruction: `vmovdqa LC2(%rip), %xmm1'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:23:no such instruction: `vpshufb %xmm3, %xmm7,%xmm6'
Treat C code as C code:
Doesn't find <atomic>
fatal error: atomic: No such file or directory
#include <atomic>
Use -Wa -q flags as per this answer:
https://stackoverflow.com/a/19339870/3684931 (I made a mistake there. It should have been -Wa, -q)
Flag becomes invalid.
clang: error: unknown argument: '-q'
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
Use -Wa,-q flags as per this answer:
https://stackoverflow.com/a/19339870/3684931
Flag is still invalid.
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
clang: error: unsupported argument '-q' to option 'Wa,'
How do I go about building this?
You seem to be solving this problem backwards, to me. Every conforming C++ implementation seems to have a compatible C ABI, so C++ projects can use C libraries. Use that to your advantage.
Create C libraries containing your C code, and compile them as C code (e.g. cc -c your_filename.c will produce a your_filename.o object file).
Create a C++ project (where you should be able to include all of your C headers, if you design them carefully), and use your linker to link to the your_filename.o object files you produced in step 1, when compiling that project.
I put the #includes myself to be able to interact with C++ code from it.
This is where you went wrong. #includeing a C++ header from a .c file will never work.
Instead, you need to make header files which are compatible with both C and C++. These files should only contain code in the common subset of C and C++ ; and they should also contain:
#ifdef __cplusplus
extern "C" {
#endif
// main header code here
#ifdef __cpluscplus
}
#endif
so that the C++ units including this header create calls using the C ABI.
In this header , you can declare some functions that will do the interacting with the C++ code which your C files require. And you can implement those functions in a new C++ source file which you write.
I've been trying to learn unit testing on my own following along a book.
Code in the book use the C++11 standard and have a line like this:
auto variable = function(parameter);
When I first compiled it I got this warning:
warning: 'auto' changes meaning in C++11; please remove it [-Wc++0x-compat]
No biggie, I could fix that by checking the following box in the Project->Build options... menu:
[ ] Have g++ follow the C++ 11 ISO C++ language standard [-std=c++11]
Now, however, I get new errors related to Google Mock in the gtest-port.h :
| | In function 'int testing::internal::posix::StrCaseCmp(const char*, const char*)':
|1719| error: '_stricmp' was not declared in this scope
| | In function 'char* testing::internal::posix::StrDup(const char*)':
|1721| error: '_strdup' was not declared in this scope
| | In function 'FILE* testing::internal::posix::FDOpen(int, const char*)':|
|1779| error: 'fdopen' was not declared in this scope
Searching for this problem yielded little for me but I did try and define the target OS as it was a suggested solution in case it was not correctly identified automatically. Adding GTEST_OS_WINDOWS=1 and/or GTEST_OS_WINDOWS_DESKTOP=1 in the projects defines changed nothing.
I realize this is easily fixed in this instance by just providing the correct type instead of using auto but I'd like to find a solution for this if possible. Replacing auto and not having the -std=c++11 option checked makes the code work as intended so the library works.
I'm using Code::Blocks 13.12 , MinGW/g++ 4.8.1-4 and Google Mock 1.7 in Windows.
Thanks for reading =)
The answer here lies in the functions which are missing declarations: _stricmp, _strdup and fdopen. The first two are Microsoft versions of the POSIX functions stricmp and strdup. Note that you are specifying the use of the C++11 ISO standard which does not contain items in the POSIX standard. By specifying --std=gnu++11 you are telling the compiler to accept a hybrid of C++11 and POSIX along with GNU extensions.
Interestingly I cannot replicate this with GCC 4.8.2 on Linux so there is the possibility that something else is going on in the Google Mock headers when compiling on Windows.
Answering for anyone still facing the same issue:
The source of this issue might be in your CMakeLists file.
Set your compiler flags to -std=gnu++ instead of -std=c++
One way to do it would be to include
set(CMAKE_CXX_FLAGS "-std=gnu++0x")
to your CMakeLists file.
First some background - I have three VS2010 C++/OpenCL projects that compile and run fine on Windows 7 64-bit. I've been trying to compile and run each of them on Linux 64-bit (Ubuntu/Debian). The first two are compiling and running on linux and don't really use any external libraries. The third uses only Boost 1.50.0 and isn't compiling using the same method as the first two. So first let me go through what I did to get the first two to work.
I extracted only the source from the myriad of folders.
I ported windows specific code to linux specific code.
I wrote a bash script to generate the g++ command with all sources to compile them.
I ran the compile script to generate an output target file.
The bash script is as follows.
#!/bin/bash
SOURCE=""
for i in `ls *.h *.cpp *.hpp`; do
SOURCE+="${i} "
done
COMMAND="g++ -I/home/junkie/downloads/boost_1_51_0 -o out ${SOURCE} -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive"
echo -e "\n"
echo -e "${COMMAND}"
echo -e "\n"
$COMMAND
exit $?
And it generates and runs a command similar to following.
g++ -I/home/junkie/downloads/boost_1_51_0 -o out blah.cpp blah.h foo.hpp baz.cpp etc.cpp -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive
I compile using the following command.
./compile.sh &> log; echo $?; grep -ci error log; wc -l log
Now you may be wondering why I've adopted such unconventional and redundant means of getting a C++ project to compile and run on linux. Well because I'm new to the linux c and c++ toolchain and this was the quickest and simplest route I could figure out to get the job done and it did get the first two projects up and running. However, the third uses boost and this method isn't working and I need your help in figuring out what all these strange errors are.
The errors I'm getting are not actually from the project code but instead from Boost and AMD's opencl libraries code which is strange because the other projects were using opencl too and those worked fine.
Some examples of boost errors are below.
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
In file included from main.cpp:4:
foo2.hpp:1610:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void /home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp: At global scope:
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected unqualified-id at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
Some examples of opencl errors are below.
In file included from /opt/AMDAPP/include/CL/cl_platform.h:35,
from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/usr/include/stdint.h:49: error: expected ‘;’ before ‘typedef’
In file included from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/opt/AMDAPP/include/CL/cl_platform.h:41: error: expected unqualified-id before string constant
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected unqualified-id at end of input
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected ‘}’ at end of input
The boost includes I'm Using are as follows.
#include <boost/preprocessor/punctuation/paren.hpp>
#include <boost/preprocessor/punctuation/comma.hpp>
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
#include <boost/type_traits/is_base_of.hpp>
#include <boost/mpl/not.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/logical.hpp>
#include <boost/mpl/eval_if.hpp>
#include <boost/mpl/identity.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/array.hpp>
So, finally, my questions are as follows.
1) What is the root cause of these errors in light of the building method I'm using and how do I resolve this problem? Does order of files or library inclusion matter? I'm using a local source download of boost as part of my g++ command as instructed by boost documentation rather than prebuilt binaries as I'm not using anything that requires prebuilt binaries.
2) I realise that my way of building things is pretty primitive. I'm learning make and I've seen some recommendations to use cmake and kdevelop which I need to look into. The primary problem with using make is that these projects weren't written with make in mind so I'm not aware of the dependency graph between source files to create the makefile (if I'm thinking correctly; I'm still fairly new to it). If you have any recommendations of how to do things better please do enlighten me.
Thanks.
I finally managed to overcome this problem and here I provide a brief account of how. To be clear I don't know what the root cause of the original problem was. In other words - I don't know why the problem occurred. All I'm saying is that my workaround allowed me to resolve the issue and move onto other problems (compile time errors).
Essentially, to reiterate, the problem was that for whatever reason a project using boost wasn't compiling on Linux because all instances of the use of the BOOST_PP_CAT() function produced the following error.
error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
For whatever reason the compiler wasn't able to correctly process the use of this function but was able to process the use of other boost functions such as BOOST_PP_LPAREN(), BOOST_PP_RPAREN() and BOOST_PP_COMMA. The problem looked almost certainly related to the preprocessing stage where the combined use of the aforementioned boost functions was resulting in an unterminated argument list.
To elaborate on the nature of the relevant code (which was not written by me thankfully) the prior developers had essentially used boost preprocessor functions to create a DSL that they could then re-use multiple times to generate a list of functions. It would have seemed a lot easier to me to simply write the functions directly but anyway that's another concern.
My work around was to change the relevant section of code so that it didn't use any BOOST_PP_CAT() functions but ultimately defined the exact same functions as before. I did this by substituting the use of BOOST_PP_CAT() with the code that was being generated by it. This overcame all instances of the error quoted above but left me with hundreds of other compile time errors in my efforts to migrate this project from windows to linux.
Although this was a very specific and unusual question with an equally specific and unusual answer I wanted to feed this back to dispel the mystery behind this problem. As to why this particular function was failing to preprocess/compile on linux but passing on Windows I don't know but would very much like to know. I can only assume it is a fundamental difference in the way VC++ performs preprocessing as opposed to g++ and clang or more specifically perhaps a difference in the order of resolution of nested functions in preprocessor directives. Who knows. Anyway, thanks for your help guys.
The unterminated argument list invoking macro error suggests a lacking closing parenthesis. Use your editor's parenthesis matcher to check it. Be sure that your source files are in Unix format, not in DOS format (e.g. with \n à la Unix, not with\r\n à la MSDOS, at each end-of-line). Use dos2unix if needed.
Otherwise, don't forget that you can run g++ -Wall -C -E -H -I/home/junkie/downloads/boost_1_51_0 yoursourcecode.cc to get the preprocessed form of yoursourcecode.cc, and, by redirecting that command, you can inspect that preprocessed form with the editor of your choice (like emacs).
As I commented, learn to use Gnu make (and if in trouble debugging your Makefile, which you should edit with a good editor like emacs, use remake -x to debug it).
And the -I/home/junkie/downloads/boost_1_51_0 looks very suspicious: even if Boost is often a header only library, it has, as far as I remember, an installation procedure on Unix (and Linux distributions often package Boost libs). You should install your Boost libraries as documented (and after having configured them), and likewise for OpenCL.
I'm looking for an implementation of Hybrid Tree(not important), and find an "old" one here.
The author said they have tried this code on the SUN Sparc platform (running Solaris 2.6) and with gcc-2.8.1 compiler. And my environment is gcc version 4.4.3 (Ubuntu 10.10).
The problem is:
I run "make" with the makefile he provides, but it gives me lots of error message as follows:
g++ -c Node.C
g++ -c DataNode.C
In file included from DataNode.h:18,
from DataNode.C:17:
Query.h:9:20: error: vector.h: No such file or directory
Query.h:10:19: error: stack.h: No such file or directory
Query.h:13:22: error: function.h: No such file or directory
Query.h:14:22: error: iostream.h: No such file or directory
DataNode.C:283:8: warning: extra tokens at end of #endif directive
In file included from DataNode.h:18,
from DataNode.C:17:
Query.h:29: warning: ‘typedef’ was ignored in this declaration
Query.h:44: warning: ‘typedef’ was ignored in this declaration
Query.h:86: error: expected initializer before ‘<’ token
Query.h:118: error: ISO C++ forbids declaration of ‘PQ’ with no type
Query.h:118: error: expected ‘;’ before ‘*’ token
Query.h:122: error: ISO C++ forbids declaration of ‘PQ’ with no type
Query.h:122: error: expected ‘;’ before ‘*’ token
Query.h:126: error: ISO C++ forbids declaration of ‘PQ’ with no type
Query.h:126: error: expected ‘;’ before ‘*’ token
Query.h:135: error: expected initializer before ‘<’ token
DataNode.C: In member function ‘void DataNode::DisconnectBranch(int)’:
DataNode.C:80: error: ‘memmove’ was not declared in this scope
make: *** [DataNode.o] Error 1
I know I need to modify the souce code so as to agree with the morden compiler, such as change vector.h to vector. But I find it's just endless.
So my question is: is there any convienent method to run this program, no matter automatically converting this code to "modern-style" or using a standalone "old-style" compiler ?
Any suggestions?
===Update:===
Thank you all, I installed gcc2.8.1 in a different dir using --prefix=/usr/local/gcc-2.8.1 and modify the "makefile" to use this old-version gcc(/usr/local/gcc-2.8.1/bin/gcc). But when I run "make", it still gives me errors of not finding the headers:
/usr/local/gcc-2.8.1/bin/gcc -c DataNode.C
In file included from DataNode.h:18,
from DataNode.C:17:
Query.h:9: vector.h: No such file or directory
Query.h:10: stack.h: No such file or directory
Query.h:11: deque: No such file or directory
Query.h:12: algorithm: No such file or directory
Query.h:13: function.h: No such file or directory
Query.h:14: iostream.h: No such file or directory
make: *** [DataNode.o] Error 1
Then I tried to find these heads in /usr/local/gcc-2.8.1 using find /usr/local/gcc-2.8.1 -name "*vector*", but got nothing.
So where are these heads for the old-version gcc?
You can make a vertor.h yourself which includes vector. This way you can fix the incompatibilities noninvasively.
Edit:
You may also need to add a
using namespace std;
in the header file(s). This is
generally a bad idea but this is one situation where i'd do it anyway.
Once you get it working i would reccomend rewriting it to use the new style header files and namespaces.
Debian Lenny (oldstable) has gcc 3.4. This might have a better backward compatibility. Try to make compatibility headers for the rest of the issues and include them via an extra -I directory, e.g. a vector.h header file that includes vector.
Do yourself the favor and try not to touch the old code. It is easy to break legacy code in unforeseen ways.
You could try running the program on QEMU which supports Solaris 2.6. The only problem might be hunting for the install disc/image. Also, there are people that sells old Solaris boxes on eBay for cheap, you might be able to grab one.
GCC provides download for very old versions, you might be able to get better chance if you try older version of the compiler.
gcc has -fpermissive option: try it and see whether at least some errors disappear. Also: try making a single header file that will include all requisite headers with using directives. For example, make stdinc.h containing:
#include <vector>
#include <iostream>
#include <stack>
...
using std::vector;
using std::fstream;
...
Replace all mentions of legacy C++ header files with a single include of stdinc.h. Old C++ didn't have namespaces, so even if you replace individual directives with just using namespace std;, clashes are unlikely.
If the only thing is
#include <vector.h>
to
#include <vector>
using namespace std;
Why not try sed?
grep for all includes to see if there are other includes than the c++ headers. If not your lucky.
Another thing that is more tricky is that there is old code that relies on accessing data through iterators in a non-standard way. I saw that in a Doom map editor for linux. Then you may need to do manual stuff.
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.