Posted: 5/6/2012 9:19:51 AM EDT
|
SO I've spent several hours working on google and building GCC and G++ 4.1.3 (which is required for my software Im building. Modern version of GCC/G++ are incompatible.) I've built the GCC and G++, and changed the syslinks to point the new (old) versions to gcc and g++ for the duration of my project. However, I am now running into an issue when building my application: gcc: act.comm.cpp: C++ compiler not installed on this system I am pretty much a noob to Linux, and running Debian 6.0.4. Any ideas? |
|
Quoted:
SO I've spent several hours working on google and building GCC and G++ 4.1.3 (which is required for my software Im building. Modern version of GCC/G++ are incompatible.) I've built the GCC and G++, and changed the syslinks to point the new (old) versions to gcc and g++ for the duration of my project. However, I am now running into an issue when building my application: gcc: act.comm.cpp: C++ compiler not installed on this systemg++ -DDEBUG -Dlinux -Wno-deprecated -I /usr/local/include/ -ggdb -c -o act.comm.o act.comm.cppact.comm.cpp:15:20: error: iostream: No such file or directorylist.h: In member function ‘bool List<T>::Add(T, const char*, int)’:list.h:230: error: ‘cerr’ was not declared in this scopelist.h:231: error: ‘endl’ was not declared in this scopemake: *** [act.comm.o] Error 1 I am pretty much a noob to Linux, and running Debian 6.0.4. Any ideas? Why not install the package? |
|
Your toolchain looks busted ...
$ apt-get install build-essential Then fix your source code to compile on a modern GCC.
ETA: Also, did you *really* install a new toolchain outside the package manager and then symlink system toolchain bits into your custom toolchain?
Trying to cheat the package manager will burn you down the road. Keep local builds in local directories, adjust CC and perhaps PATH environment variables as-necessary. For example, you can avoid touching any system directory at all by installing to 'toolchain' or some similarly-named directory in your $HOME, then shove your custom toolchain at the beginning of your $PATH to instruct your shell to find your custom tools first. Honestly seems like a lot of BSing around for code that can't *really* be right if newer (stricter) GCC croaks out |
|
Quoted: Your toolchain looks busted ... $ apt-get install build-essential Then fix your source code to compile on a modern GCC. ![]() ETA: Also, did you *really* install a new toolchain outside the package manager and then symlink system toolchain bits into your custom toolchain? ![]() Trying to cheat the package manager will burn you down the road. Keep local builds in local directories, adjust CC and perhaps PATH environment variables as-necessary. For example, you can avoid touching any system directory at all by installing to 'toolchain' or some similarly-named directory in your $HOME, then shove your custom toolchain at the beginning of your $PATH to instruct your shell to find your custom tools first. Honestly seems like a lot of BSing around for code that can't *really* be right if newer (stricter) GCC croaks out This. Messing with the OS installed gcc libs is bad. Installing in /usr/local and changing your path variable is what you want to do. |
I tried installing via apt-get package and it failed, giving me this message:
So I did the custom build...and no, at this point, rewriting the several thousand lines of code isn't something I have time for. I understand the argument, and once I get it built and evaluated, if I decide to progress with it, I will clean the code up. I know the original coder has last proven it on 4.1.2. What version of Debian used 4.1.2 natively? i have no problems installing the correct version of debian if its easier. I am just trying to put together a baseline VM under Windows 7. |
|
Quoted:
I tried installing via apt-get package and it failed, giving me this message: jrsteensen@mudhost:~/sol_dev/src$ sudo apt-get install gcc-4.1 gcc-4.1-base libstdc++6-4.1-dev Reading package lists... Done Building dependency tree Reading state information... Done Package libstdc++6-4.1-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libstdc++6-4.1-dev' has no installation candidate So I did the custom build...and no, at this point, rewriting the several thousand lines of code isn't something I have time for. I understand the argument, and once I get it built and evaluated, if I decide to progress with it, I will clean the code up. I know the original coder has last proven it on 4.1.2. What version of Debian used 4.1.2 natively? i have no problems installing the correct version of debian if its easier. I am just trying to put together a baseline VM under Windows 7. apt-get update? Are you running stable? does "sol_dev" imply solaris? |
|
Quoted: SO I've spent several hours working on google and building GCC and G++ 4.1.3 (which is required for my software Im building. Modern version of GCC/G++ are incompatible.) I've built the GCC and G++, and changed the syslinks to point the new (old) versions to gcc and g++ for the duration of my project. However, I am now running into an issue when building my application: gcc: act.comm.cpp: C++ compiler not installed on this systemg++ -DDEBUG -Dlinux -Wno-deprecated -I /usr/local/include/ -ggdb -c -o act.comm.o act.comm.cppact.comm.cpp:15:20: error: iostream: No such file or directorylist.h: In member function ‘bool List<T>::Add(T, const char*, int)’:list.h:230: error: ‘cerr’ was not declared in this scopelist.h:231: error: ‘endl’ was not declared in this scopemake: *** [act.comm.o] Error 1 I am pretty much a noob to Linux, and running Debian 6.0.4. Any ideas? As far as iostream goes, make sure you're using "#include <iostream>" not "iostream.h" Have you knocked together a smaller test program using iostream? Might be useful. |
|
Quoted: Quoted: Your toolchain looks busted ... $ apt-get install build-essential Then fix your source code to compile on a modern GCC. ![]() ETA: Also, did you *really* install a new toolchain outside the package manager and then symlink system toolchain bits into your custom toolchain? ![]() Trying to cheat the package manager will burn you down the road. Keep local builds in local directories, adjust CC and perhaps PATH environment variables as-necessary. For example, you can avoid touching any system directory at all by installing to 'toolchain' or some similarly-named directory in your $HOME, then shove your custom toolchain at the beginning of your $PATH to instruct your shell to find your custom tools first. Honestly seems like a lot of BSing around for code that can't *really* be right if newer (stricter) GCC croaks out This. Messing with the OS installed gcc libs is bad. Installing in /usr/local and changing your path variable is what you want to do. Makes sense. the GCC/G++ build is confusing the dog piss outta me though. I've never dealt with installing applications outside of using apt-get before. Makes perfect sense. Would you happen to have a tutorial handy for how to do this? |
|
Quoted:
Makes sense. the GCC/G++ build is confusing the dog piss outta me though. I've never dealt with installing applications outside of using apt-get before. Makes perfect sense. Would you happen to have a tutorial handy for how to do this? I don't, but let me give you the basic run-down here: The shell environment variable $PATH defines where your shell will look for commands to call. You can tweak it for the running shell instance any time you like. Check it out: sh$ echo $PATH sh$ mkdir ~/bin sh$ echo -e '#!/bin/sh\necho hi!' > ~/bin/my_test_cmd sh$ chmod +x ~/bin/my_test_cmd sh$ my_test_cmd ## Should be a command not found error. sh$ PATH="$HOME/bin:$PATH" my_test_cmd ## Should greet you. This altered PATH will disappear after my_test_cmd completes. bash$ export PATH="${HOME}/bin:$PATH" ## Preserve this altered PATH for the running instance. PATH is searched from left to right when a command is called that is not a shell built-in nor an absolute path to something. If you are calling gcc and friends directly or using some kind of halfassed/custom build system, you may need to adjust your PATH. If you just need this toolchain for one user, you can install stuff to somewhere under your home directory and adjust PATH as-needed. Otherwise, you can install to /usr/local –– whichever the case may be, you will install to a "prefix" such as /usr/local or /home/MYUSER/toolchain or something. Directories under this prefix will be created for various files. Executables files will typically end up in PREFIX/bin, for example. When building an autotools-enabled distribution such as GCC, you should be able to specify a ––prefix opt to the 'configure' script. This will determine your install PREFIX. See './configure ––help' for a complete description of available options for a particular autoconf'd distribution. sh$ cd gcc-ancient-version sh$ ./configure ––any-opts-I-need ––prefix=/home/myuser/oldass-toolchain ## GCC has a lot of built options you may want to investigate. ## ./configure ––help is worth a look. ## Note that you may need a special opt (––with-g++ or something? I forget) to build C++ sh$ make && make install The above will install a toolchain under /home/myuser/oldass-toolchain. Your binaries would likely be in /home/myuser/oldass-toolchain/bin Now, if the *app you are actually building* is autotools-ified, you can probably just leave PATH well enough alone. A proper autotools distribution will respect the environment variables $CC and $CXX, defining the location of the preferred C compiler and C++ compiler, respectively. If these are set when 'configure' is run for the target application, it should use the right compiler when 'make' is called later: sh$ CC="/path/to/my/oldass/gcc" CXX="/path/to/my/oldass/g++" ./configure && make |
Here is output, making with the latest package of build-essentials:set -e; gcc -MM -DDEBUG -Dlinux -Wno-deprecated -I /usr/local/include/ -ggdb zedit.cpp | sed 's/\(zedit\)\.o[ :]*/\1.o zedit.d : /g' > zedit.d; [ -s zedit.d ] || rm -f zedit.d |
|
Quoted:
comm.cpp:1590: error: invalid conversion from ‘const char*’ to ‘char*’ comm.cpp:1601: error: invalid conversion from ‘const char*’ to ‘char*’ There is your actual failure (the others are deprecation warnings, but probably ought be fixed) ... const 'something' ––> 'something' is invalid. ETA: At a guess, someone needs to be copying a string to a fresh array somewheres ... I don't really know shit about C++, though, so I'll sit quietly in my corner now. |
|
Quoted:
I tried installing via apt-get package and it failed, giving me this message: jrsteensen@mudhost:~/sol_dev/src$ sudo apt-get install gcc-4.1 gcc-4.1-base libstdc++6-4.1-devReading package lists... DoneBuilding dependency tree Reading state information... DonePackage libstdc++6-4.1-dev is not available, but is referred to by another package.This may mean that the package is missing, has been obsoleted, oris only available from another sourceE: Package 'libstdc++6-4.1-dev' has no installation candidate
So I did the custom build...and no, at this point, rewriting the several thousand lines of code isn't something I have time for. I understand the argument, and once I get it built and evaluated, if I decide to progress with it, I will clean the code up. I know the original coder has last proven it on 4.1.2. What version of Debian used 4.1.2 natively? i have no problems installing the correct version of debian if its easier. I am just trying to put together a baseline VM under Windows 7. Setting up libstdc++6-4.4-dev |
Win a FREE Membership!
Sign up for the ARFCOM weekly newsletter and be entered to win a free ARFCOM membership. One new winner* is announced every week!
You will receive an email every Friday morning featuring the latest chatter from the hottest topics, breaking news surrounding legislation, as well as exclusive deals only available to ARFCOM email subscribers.