How to run program written for old compiler? - c++

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.

Related

‘numeric_limits’ is not a member of ‘std’

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.

Error using Clang tool to parse a C++ standard header file

I am using clang tool to parse standard header file located in /usr/lib/gcc/x86_64-linux-gnu/4.7/string. But I get the following error.
In file included from ~/PrototypeWork/user/header.hpp:3:
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/string:41:
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/char_traits.h:41:
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/postypes.h:41:
/usr/include/c++/4.7/tr1/cwchar:42:14: error: no member named 'wcstof' in namespace 'std'
using std::wcstof;
~~~~~^
/usr/include/c++/4.7/tr1/cwchar:45:14: error: no member named 'vfwscanf' in namespace 'std'
using std::vfwscanf;
~~~~~^
The problem seemed to be that clang is reading string header as a C header instead of c++ header and so it could not parse "using" keyword.
So I went ahead an added the -TP command line options that says to treat all source files as C++ but that did not help.
I get the following warning after using -TP command line option
warning: argument unused during compilation: '-T P'
Can anyone help me with this issue?
Clang command line options: http://clang.llvm.org/docs/UsersManual.html#id5
Code
My main function has these:
int main() {
std::vector<std::string> cmdLine = boost::assign::list_of
("-TP")
("-I/usr/include")
("-I/usr/include/c++/4.7/tr1/");
clang::tooling::FixedCompilationDatabase db(".",cmdLine);
// Provide clang with the header file that needs to be parsed
// Run the clang tool .
}
Sorry if this is a "Thank you, Captain Obvious" answer, but: is it possible that the code being parsed is simply failing to #include <cwchar>? clang is a bit more stringent by default than gcc, so you'll see an error like this if you've failed to include the header that declares the function.

G++ not finding symbols from regex system header

I am trying to use the GNU C library regex functionality in my C++ project, particularly I'm trying to use the regex_t regcomp, regexec, regfree functions. Upon compilation I get errors stating that these symbols are undefined:
me> g++ -I/me/myheaders/ -c RootGenerator.cpp -o RootGenerator.o -std=gnu++0x -Wall
RootGenerator.cpp: In function ‘std::string findFirstFileInCurrentDirectory(std::string)’:
RootGenerator.cpp:1072: error: ‘regex_t’ was not declared in this scope
RootGenerator.cpp:1072: error: expected ‘;’ before ‘re’
RootGenerator.cpp:1073: error: ‘re’ was not declared in this scope
RootGenerator.cpp:1073: error: ‘REG_EXTENDED’ was not declared in this scope
RootGenerator.cpp:1073: error: ‘REG_NOSUB’ was not declared in this scope
RootGenerator.cpp:1073: error: ‘regcomp’ was not declared in this scope
RootGenerator.cpp:1074: error: expected ‘;’ before ‘int’
RootGenerator.cpp:1084: error: ‘status’ was not declared in this scope
RootGenerator.cpp:1084: error: ‘regexec’ was not declared in this scope
RootGenerator.cpp:1092: error: ‘REG_NOMATCH’ was not declared in this scope
RootGenerator.cpp:1108: error: ‘regfree’ was not declared in this scope
I realize that the regex header is a TR1 implementation and is therefore experimental for my version of GCC. I added the -std=gnu++0x compiler option according to the compiler warning recieved when first trying to compile but this doesn't seem to fix the issue. Is this an issue of the system not recognizing and adding paths to "experimental" headers? Are there additional include paths or compiler options that I need to specify?
As an additional note, I noticed in Eclipse/CDT that under the "includes" tab in the Project Explorer view, it shows a list of the system header paths. It lists many header files under the /user/include/c++/4.4.4 path tab, but It doesn't list the regex header. I think this is also reaffirming that there is a setting issue.
Found the problem:
#include <regex>
should be
#include <regex.h>
The regex.h header is the GNU C library implementation of regex, containing the functions I was trying to use in my source. The regex header is the TR1 (and incomplete) regex implemntation. So #Oli, I wasn't referencing the relevant header after all!

Visual Studio C++/OpenCL project using Boost not compiling with g++ on Linux

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.

size_t can not be found by g++-4.1 or others on Ubuntu 8.1

This has happened before to me, but I can't remember how I fixed it.
I can't compile some programs here on a new Ubuntu install... Something is awry with my headers.
I have tried g++-4.1 and 4.3 to no avail.
g++ -g -frepo -DIZ_LINUX -I/usr/include/linux -I/usr/include -I/include -c qlisttest.cpp
/usr/include/libio.h:332: error: ‘size_t’ does not name a type
/usr/include/libio.h:336: error: ‘size_t’ was not declared in this scope
/usr/include/libio.h:364: error: ‘size_t’ has not been declared
/usr/include/libio.h:373: error: ‘size_t’ has not been declared
/usr/include/libio.h:493: error: ‘size_t’ does not name a type
/usr/include/stdio.h:294: error: ‘size_t’ has not been declared
...
the file...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
...
#ubuntu:~/work/zpk/src$ cat /usr/include/linux/types.h | grep size_t
typedef __kernel_size_t size_t;
typedef __kernel_ssize_t ssize_t;
types.h is definitely in the path, and is getting picked up. I verified by changing the file name and get an error its missing...
Does anyone have any ideas...? I would really appreciate the help...
Start by removing -I/usr/include/linux and -I/usr/include. Adding system directories to include paths manually either has no effect, or breaks things. Also, remove -frepo for extra safety.
Generally, you shouldn't be using C .h files for C++. While you may find an easy way to get away with it, and while a lot of this was allowed in previous versions of g++ and in other compilers, the C++ standard defines size_t to be in cstddef (see section 18.2/table 17). g++ has been only getting more strict.
Remove all the includes paths you've added to your command (they are redundant), and add to the top of your source code if not included:
#include <cstddef>
using namespace std;
It's hard to say what the issue is without seeing your complete source. The best way to debug issues like this is to use g++'s "-E" parameter to produce pre-processor output, and then look at that to figure out what's going on in your includes. Here's what the g++ info page says about "-E":
-E Stop after the preprocessing stage; do not run the compiler proper.
The output is in the form of preprocessed source code, which is
sent to the standard output.
Also, why not just include sys/types.h at the top of the file?
Addendum:
On my system, I've created a short file called foo.cc that contains only:
#include <time.h>
And then I've run:
g++ -E /tmp/foo.cc > /tmp/foo.pp
Looking at this output in much detail is very important. For example, I learned that /usr/include/bits/types.h has a typedef for __time_t, and that /usr/include/types.h then uses that typedef to say "typedef __time_t time_t". But, there are interesting other macros surrounding that definiton. Pay special attention to things like the macro "__BEGIN_NAMESPACE_STD" in /usr/include/time.h, which on my system seems to be an empty define. But, I can imagine that some other systems may have a different value for this macro, forcing the definition of time_t into some other namespace.
Read the Cpp info page, section "9 Preprocessor Output" that defines the format of the lines of the file. Of particular note is the section on:
Source file name and line number information is conveyed by lines of the form
# LINENUM FILENAME FLAGS
And then goes on to describe "FLAGS" which are of interest for this level of debugging.
Have you installed the build-essential package?
sudo apt-get install build-essential
Forgot to follow up on this. It turns out that /usr/include cannot be included with /usr/include/linux on this particular distro. size_t seems to be get wiped out by the second includes.
My includes are now merely /usr/include and it works great.
-I/usr/include -I/usr/include/ace -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0...
Pulling out all the includes and playing with them fixed it.
It should be in stddef.h or cstddef. types.h is not a standard library, and I believe it refers to types the OS needs.