As the title said I can't install that specific version of g++ in my current ubuntu (20.04).
I have been trying the usual things as: sudo apt install g++- (and displaying all posibilities but there where only versions from 8 to 10). Same happend looking for gcc possibilities.
Also tried this: gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91 (same problem)
And after looking for a while I gave up in my research and ended up here. Hope someone with more wisdom than me can give my a hand with this.
These steps should work:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt upgrade
sudo apt-get install gcc-multilib libstdc++6:i386
wget https://ftp.gnu.org/gnu/gcc/gcc-4.8.5/gcc-4.8.5.tar.bz2 --no-check-certificate
tar xf gcc-4.8.5.tar.bz2
# cd gcc-4.8.5
# ./contrib/download_prerequisites
# cd ..
sed -i -e 's/__attribute__/\/\/__attribute__/g' gcc-4.8.5/gcc/cp/cfns.h
sed -i 's/struct ucontext/ucontext_t/g' gcc-4.8.5/libgcc/config/i386/linux-unwind.h
mkdir xgcc-4.8.5
pushd xgcc-4.8.5
$PWD/../gcc-4.8.5/configure --enable-languages=c,c++ --prefix=/usr --enable-shared --enable-plugin --program-suffix=-4.8.5
make MAKEINFO="makeinfo --force" -j
sudo make install -j
Note that you have to uncomment the .../download_prerequisites on some platform. For me it worked without on Centos 7 or Ubuntu 20 with the mandatory packages installed:
Ubuntu/Debian:
sudo apt install make wget git gcc g++ lhasa libgmp-dev libmpfr-dev libmpc-dev flex bison gettext texinfo ncurses-dev autoconf rsync
Centos:
sudo yum install wget gcc gcc-c++ python git perl-Pod-Simple gperf patch autoconf automake make makedepend bison flex ncurses-devel gmp-devel mpfr-devel libmpc-devel gettext-devel texinfo
Few seconds later (/giggles) gcc-4.8.5 is installed and available.
Notes:
if you don't have the resources to run make -j omit -j or use -j4 (or a different number which is adequate for your system)
your milage may vary and you may need to install further i386 packages
Since I can't comment I will add to #bebbo solution that on an Ubuntu 20.04 I had to add to his steps patching the following patches:
Add an include to signal.h to libsanitizer/asan/asan_linux.cc
https://patchwork.ozlabs.org/project/gcc/patch/6824253.3U2boEivI2#devpool21/
change a line in libsanitizer/tsan/tsan_platform_linux.cc
as shown. line number may not be the one stated in the patch so search for the line that was changed. There is no need to apply the patch to the other files
https://git.pantherx.org/mirror/guix/commit/0b93d04ac537d6413999349ebe7cdcb1e961700e
Adding to kpeace's answer...
sed -i '/#include <pthread.h>/a #include <signal.h>' path_to_gcc4.8.5src/libsanitizer/asan/asan_linux.cc
sed -i 's/__res_state \\*statp = (__res_state\\*)state\\;/struct __res_state \\*statp = (struct __res_state\\*)state\\;/g' path_to_gcc4.8.5src/libsanitizer/tsan/tsan_platform_linux.cc
Just adding a couple of sed lines to patch them inline.
Also, I've been writing some Ruby scripts to install some software (for fun of course.) I've recently successfully compiled gcc-4.8.5 under LinuxMint 20.1 (Ubuntu 20.04 based, compiler is the system gcc: 9.3.0, installed with sudo apt install build-essential) with this script. Also, I've installed all the packages that Bebbo suggested, including gcc-multilib and libstdc++6:i386 before running this script. Check up InstGcc4 class at the bottom of the code.
install_gcc.rb
They might end up to be 'un-installable' state a few months later. But at least gcc-4.8.5 works now.
ps. I've started to compile this old gcc due to CUDA... My hardware is a decade old GeForce 9600/9400 (yeah 2008 MBP) and CUDA 6.5 was the best option for that machine.
pps. Anyway, strange thing is, I had to give out '-std=gnu++11' for CXXFLAGS to avoid errors.
Related
I'm working on CentOS 7 and regular sudo commands (e.g. sudo yum update, etc.) are working fine. However, one of my sudo commands require to preserve the environment variables, so I used:
sudo -E ./build/unit-tests
and I get this error:
/var/tmp/sclyZMkcN: line 8: -E: command not found
It appears sudo is not recognizing the -E command on CentOS 7. What can I do in this case? Any alternatives or possible fix?
I've recently come across exactly the same problem. I tried to execute a script with sudo -E, which caused the above-mentioned -E: command not found error.
The reason turned out to be Red Hat Developer Toolset providing a broken sudo. A solution is to use the full sudo system path to make sure a good one is used, i.e.
/usr/bin/sudo -E ./some_script.sh
I you know which variables to preserve, you can use env to pass them through the command line.
sudo env foo="$foo" bar="$bar" ./build/unit-tests
I have created a c++ app on Debian Jessie 8.10 amd64 which also need the following libraries:
sudo apt-get install libssl-dev
sudo apt-get install libcurl4-openssl-dev
I also need to cross compile the source code for armhf. So according to this quite helpful link https://wiki.embeddedarm.com/wiki/Jessie_armhf_Cross_Compile I gave the following commands:
sudo apt-get install curl build-essential
su root
echo "deb http://emdebian.org/tools/debian jessie main" >
/etc/apt/sources.list.d/emdebian.list
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | apt-key add -
dpkg --add-architecture armhf
apt-get update
apt-get install crossbuild-essential-armhf
Everything got installed correctly and then I also gave :
sudo apt-get install libssl-dev:armhf
sudo apt-get install libcurl4-openssl-dev:armhf
The first command executed successfully. On the other hand the second one failed giving the following output:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
libcurl4-doc:armhf libcurl3-dbg:armhf libidn11-dev:armhf libkrb5-dev:armhf libldap2-dev:armhf
librtmp-dev:armhf libssh2-1-dev:armhf pkg-config:armhf
The following NEW packages will be installed:
libcurl4-openssl-dev:armhf
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
23 not fully installed or removed.
Need to get 0 B/316 kB of archives.
After this operation, 863 kB of additional disk space will be used.
(Reading database ... 94032 files and directories currently installed.)
Preparing to unpack .../libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb ...
Unpacking libcurl4-openssl-dev:armhf (7.38.0-4+deb8u8) ...
dpkg: error processing archive /var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb (--unpack):
trying to overwrite shared '/usr/include/curl/curlbuild.h', which is different from other instances of package libcurl4-openssl-dev:armhf
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
/var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Since I'm quite new in cross compilation procedures does anyone have any idea what I'm doing wrong?
You are doing nothing wrong. It is a file conflict in related with multiarch packages. It is a bug in the package
Here is a explanation of this kind of bugs, from https://wiki.debian.org/MultiArch/Hints
The package in question is marked Multi-Arch: same, but has
conflicting versions of at least one file for different architectures.
The hint tells the filename (or the number of filenames) and the
architectures (or number of architectures) in question. The easiest
way to fix is to remove the Multi-Arch: same declaration, but often
enough it can be fixed by moving the offending files to
per-architecture locations (typically
/usr/lib/$(DEB_HOST_MULTIARCH)/). For *-dev packages, the Multi-Arch:
same capability often is not critical and removing is a good initial
measure.
I just run into the same kind of problem, which still is an issue with some packages. In my case libcurl-openssl-dev was replacing the /usr/bin/curl-config binary.
To me it required swapping from x64/i386 libraries when i needed cross-compiling but i am well aware it might not be possible for everyone.
I am not a Linux pro, but I have a task to modify KDE app "dolphin" for home using (modify address bar navigation mechanism). I think, that it would easy, but still have no understanding how to do this. Days of tries led me to the solution, that I should not build dolphin from dolphin repository (git://anongit.kde.org/dolphin), but from kde-baseapps repo:
sudo apt-get update
sudo apt-get install git-core build-essential libkactivities-dev
sudo apt-get build-dep dolphin
git clone git://anongit.kde.org/kde-baseapps && cd kde-baseapps && mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..
make -j3
cd dolphin/src/
./dolphin4
Next I think, that I can find source code in "kde-baseapps" folder, but it references to "/usr/include" *.h-files, that references to corresponding *.cpp-files in "kdelibs" package.
That's right, that I should download "kdelibs" sources, modify them and build? That is right way to resolve task or exists a better way to do this?
Yeah, exists a better solution. kdelibs compilation isn't necessary, it is possible to modify only dolphin source code by this bash commands (from ~ dir):
mkdir src
cd src
sudo apt-get update
sudo apt-get build-dep kde-baseapps
apt-get source kde-baseapps
cd kde-baseapps-4.13.3/dolphin/src/
patch < ~/your.patch
cd ../..
mkdir build
cd build
cmake ..
make
sudo make install
hope this is just a very simple question. Ok, here's what I've done: I wanted to install gmp under my Linux Ubuntu 11.10. I have both g++ and gcc on my system. So I downloaded the latest release from the gmp official site (gmp 5.0.2), extracted it and then, since I need the c++ gmp interface, I simply run:
./configure --enable-cxx
But it keeps working for a while and then prints out:
checking for suitable m4... configure: error: No usable m4 in $PATH or /usr/5bin (see config.log for reasons).
Did I do something wrong? Thank you very much!
Matteo
try sudo apt-get install m4 and rerun the ./configure
I know this was from 7 years ago, but Im looking at installing gmp5.1.3 from source on an older system right now. I noted the "funny output" checking for suitable m4... configure: error: No usable m4 in $PATH or /usr/5bin 5bin hunh? I though it was a typo, and it probably is. On line 27285 of configure script, there is ac_dummy="$PATH:/usr/5bin"
that is a shell variable that the script then looks for and doesn't find. in the *nix default FHS, /usr/5bin doesn't exist.
the problem with ac_dummy="$PATH:/usr/5bin" is that the next few lines are a for loop searching the $PATH variable + /usr/5bin for m4.
on my system, /usr/sbin is where the m4 files are located, and is not part of the default $PATH variable.
Fixes:
you could modify your $PATH variable to include /usr/sbin.
you could modify the configure script to say ac_dummy="$PATH:/usr/sbin"
you could wait 7 years for someone to file a bug report.
depending on age and support of your OS, sudo apt-get install m4 could also work.
I have the same error, sudo apt-get install m4 solve this problem.
You can consider this a follow-up question to How do I install the OpenSSL C++ library on Ubuntu?
I'm trying to build some code on Ubuntu 10.04 LTS that requires OpenSSL 1.0.0.
Ubuntu 10.04 LTS comes with OpenSSL 0.9.8k:
$ openssl version
OpenSSL 0.9.8k 25 Mar 2009
So after running sudo apt-get install libssl-dev and building, running ldd confirms I've linked in 0.9.8:
$ ldd foo
...
libssl.so.0.9.8 => /lib/i686/cmov/libssl.so.0.9.8 (0x00110000)
...
libcrypto.so.0.9.8 => /lib/i686/cmov/libcrypto.so.0.9.8 (0x002b0000)
...
How do I install OpenSSL 1.0.0 and the 1.0.0 development package?
Update: I'm writing this update after reading SB's answer (but before trying it), because it's clear I need to explain that the obvious solution of downloading and installing OpenSSL 1.0.0 doesn't work:
After successfully doing the following (recommended in the INSTALL file):
$ ./config
$ make
$ make test
$ make install
...I still get:
OpenSSL 0.9.8k 25 Mar 2009
...and:
$ sudo apt-get install libssl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libssl-dev is already the newest version.
The following packages were automatically installed and are no longer required:
linux-headers-2.6.32-21 linux-headers-2.6.32-21-generic
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
...and (just to make sure) after rebuilding my code, ldd still returns the same thing.
Update #2: I added the "-I/usr/local/ssl/include" and "-L/usr/local/ssl/lib" options (suggested by SB) to my makefile, but I'm now getting a bunch of undefine reference compile errors, for example:
/home/dspitzer/foo/foo.cpp:86: undefined reference to `BIO_f_base64'
/home/dspitzer/foo/foo.cpp:86: undefined reference to `BIO_new'
/usr/local/ssl/include/ contains only an openssl directory (which contains numerous .h files), so I also tried "-I/usr/local/ssl/include/openssl" but got the same errors.
Update #3: I tried changing the OpenSSL includes from (for example):
#include <openssl/bio.h>
...to:
#include "openssl/bio.h"
...in the .cpp source file but still get the same undefined reference errors.
Update #4: I now realize those undefined reference errors are linker errors. If I remove the "-L/usr/local/ssl/lib" from my Makefile, I don't get the errors (but it links to OpenSSL 0.9.8). The contents of /usr/local/ssl/lib/ are:
$ ls /usr/local/ssl/lib/
engines libcrypto.a libssl.a pkgconfig
I added -lcrypto, and the errors went away.
Get the 1.0.0a source from here.
# tar -xf openssl-1.0.0a.tar.gz
# cd openssl-1.0.0a
# ./config
# sudo make install
Note: if you have man pages build errors on modern systems, use make install_sw instead of make install.
This puts it in /usr/local/ssl by default
When you build, you need to tell gcc to look for the headers in /usr/local/ssl/include and link with libs in /usr/local/ssl/lib. You can specify this by doing something like:
gcc test.c -o test -I/usr/local/ssl/include -L/usr/local/ssl/lib -lssl -lcrypto
EDIT DO NOT overwrite any system libraries. It's best to keep new libs in /usr/local. Overwriting Ubuntu defaults can be hazardous to your health and break your system.
Additionally, I was wrong about the paths as I just tried this in Ubuntu 10.04 VM. Fixed.
Note, there is no need to change LD_LIBRARY_PATH since the openssl libs you link against by default are static libs (at least by default - there might be a way to configure them as dynamic libs in the ./config step)
You may need to link against libcrypto because you are using some calls that are built and defined in the libcrypto package. Openssl 1.0.0 actually builds two libraries, libcrypto and libssl.
EDIT 2 Added -lcrypto to gcc line.
Instead of:
$ ./config
$ make
$ make test
$ make install
Do:
$ sudo ./config --prefix=/usr
$ sudo make
$ sudo make test
$ sudo make install
This will help you update to openssl 1.0.1g to patch for CVE-2014-0160 (Heartbleed).
OpenSSL Security Advisory [07 Apr 2014]
TLS heartbeat read overrun (CVE-2014-0160)
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley and Bodo Moeller for
preparing the fix.
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
1.0.2 will be fixed in 1.0.2-beta2.
Source: https://www.openssl.org/news/secadv_20140407.txt
Here's what solved it for me:
Upgrade latest version OpenSSL on Ubuntu
Transcribing the main information:
Download the OpenSSL v1.0.0g source:
$ wget http://www.openssl.org/source/openssl-1.0.0g.tar.gz
Unpack the archive and install:
$ tar xzvf openssl-1.0.0g.tar.gz
$ cd openssl-1.0.0g
$ ./config
$ make
$ make test
$ sudo make install
All files, including binaries and man pages are install under the directory /usr/local/ssl. To ensure users use this version of OpenSSL instead of the previous version you must update the paths for man pages and binaries.
Edit the file /etc/manpath.config adding the following line before the first MANPATH_MAP:
MANPATH_MAP /usr/local/ssl/bin /usr/local/ssl/man
Update the man database (I honestly can't remember and don't know for sure if this command was necessary - maybe try without it and at the end when testing if the man pages are still the old versions come back and run mandb):
sudo mandb
Edit the file /etc/environment and insert the path for OpenSSL binaries (/usr/local/ssl/bin) before the path for Ubuntu's version of OpenSSL (/usr/bin). My environment file looks like this:
PATH="/usr/local/sbin:/usr/local/bin:/usr/local/ssl/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
Logout and login and test:
$ openssl version
OpenSSL 1.0.0g 18 Jan 2012
Also test the man pages by running man openssl and at the very bottom in the left hand corner it should report 1.0.0g.
Note that although the users will now automatically use the new version of OpenSSL, existing programs (e.g. Apache) may not as they are linked against the libraries from the Ubuntu version.