Install gcc from source: bash: gcc -v /usr/bin/gcc: Is a directory - c++

I just installed gcc-8.1 from source using those steps:
wget https://ftp.gnu.org/gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.gz
tar xvf gcc-8.1.0.tar.gz
cd gcc-8.1.0
apt build-dep gcc
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-8.1.0/configure --prefix=/usr/bin/gcc-8.1 --enable-languages=c,c++,fortran,go --disable-multilib
make -j8
make install
Everything is correct?
Then I add it to update-alternatives
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8.1 60 --slave /usr/bin/g++ g++ /usr/bin/g++-8.1
There are 3 choices for the alternative gcc (providing /usr/bin/gcc).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/gcc-7 60 auto mode
1 /usr/bin/gcc-5 60 manual mode
* 2 /usr/bin/gcc-7 60 manual mode
3 /usr/bin/gcc-8.1 60 manual mode
Press <enter> to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/gcc-8.1 to provide /usr/bin/gcc (gcc) in manual mode
update-alternatives: warning: skip creation of /usr/bin/g++ because associated file /usr/bin/g++-8.1 (of link group gcc) doesn't exist
My issue is when I type gcc -v, it said bash: /usr/bin/gcc: Is a directory

--prefix=/usr/bin/gcc-8.1 means that everything that is part of the installation will be placed in the /usr/bin/gcc-8.1/ directory.1
This means that your actual GCC binary is probably located at /usr/bin/gcc-8.1/bin/gcc (or some similarly-named executable, maybe it is actually called gcc-8 or gcc-8.1).
When you set the GCC binary to /usr/bin/gcc-8.1 using update-alternatives, you set the symlink that is normally used to resolve which GCC binary you want to a directory - resulting in the error that you are now getting.
To fix this issue, follow these steps:
Remove the wrong entry in update-alternatives:
update-alternatives --remove gcc /usr/bin/gcc-8.1
Add the right entry.2
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8.1/bin/gcc 60 \
--slave /usr/bin/g++ g++ /usr/bin/gcc-8.1/bin/g++
1 Well, mostly, anyways. Usual prefixes include / (binaries in /bin/), /usr/ (binaries in /usr/bin/) and /usr/local/ (binaries in /usr/local/bin/)
2 I am assuming you want to keep GCC installed at that awkward location. Recompiling and re-installing with --prefix=/opt/gcc-8.1 or something similar would probably be better, just modify the path as needed

This is a double edged sword. I am on windows so don't have the linux jargon. But located my gcc problem in a very wierd way. But maybe this will help someone from hours of digging and trying this and that. But cant say i have not learned a lot in the process.
gcc 10.4 release for windows
and that at least got me to here
Read down to the soundforge link

Related

GCC & binutils build - C compiler cannot create executables

I'm trying to build gcc-5.3 and binutils-2.26. I've done it like this:
mkdir gcc; cd gcc
wget http://path/to/gcc-5.3.0.tar.bz2
wget http://path/to/binutils-2.26.tar.bz2
tar xf gcc-5.3.0.tar.bz2
tar xf binutils-2.26.tar.bz2
cd gcc-5.3.0
contrib/download_prerequisites
for file in ../binutils-2.26/*; do ln -s "${file}"; done
cd ..
mkdir build
mkdir dist
cd build
../gcc-5.3.0/configure --prefix=/home/teamcity/gcc/dist --disable-multilib --with-system-zlib --enable-languages=c,c++,fortran --program-suffix=-mine
make
This appears to build the first stage executables okay; prev-gas, prev-gcc, prev-ld are all present with plausible-looking executables in them. But the next stage fails:
Configuring stage 2 in ./intl
configure: loading cache ./config.cache
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for x86_64-unknown-linux-gnu-gcc... /home/teamcity/gcc/build/./prev-gcc/xgcc -B/home/teamcity/gcc/build/./prev-gcc/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/lib/ -isystem /home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/include -isystem /home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/sys-include -L/home/teamcity/gcc/build/./ld
checking for C compiler default output file name...
configure: error: in `/home/teamcity/gcc/build/intl':
configure: error: C compiler cannot create executables
See `config.log' for more details.
The relevant bit of config.log appears to be this:
configure:2978: checking for C compiler default output file name
configure:3000: /home/teamcity/gcc/build/./prev-gcc/xgcc -B/home/teamcity/gcc/build/./prev-gcc/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unkn
own-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/lib/ -isystem /home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/include -isystem /home/teamcity/gcc/dist/x86_64-unknown-l
inux-gnu/sys-include -L/home/teamcity/gcc/build/./ld -g -O2 -gtoggle -static-libstdc++ -static-libgcc conftest.c >&5
/home/teamcity/gcc/build/./prev-gcc/as: 106: exec: /home/teamcity/gcc/build/./gas/as-new: not found
This looks like prev-gcc's as is expecting to find gas/as-new, when actually it's prev-gas/as-new.
Is there some workaround for this? Is it safe to just ln -s prev-gas gas? I'd sort of expect that to cause problems later on. Is it not possible to build these two versions of gcc and binutils together?
This is my edited answer after trying it on my own on an Ubuntu 14.04 Azure VM.
The following approach worked for me:
Build and install binutils 2.26; for the purposes of this discussion,
let's say it's installed in /opt/gcc-5.3.0.
Configure gcc-5.3.0 in a build directory using /root/objdir/../gcc-5.3.0/configure --prefix=/opt/gcc-5.3.0
--enable-languages=c,c++ --disable-multilib --with-ld=/opt/gcc-5.3.0/bin/ld --with-as=/opt/gcc-5.3.0/bin/as assuming gcc-5.3.0 and the build directory, objdir, are at the same
level.
Do make followed by make install in the objdir build directory.
To verify that the ld used by the newly-built gcc is the one from the new binutils:
/opt/gcc-5.3.0/bin/gcc -print-prog-name=ld
The output should be, in this example:
/opt/gcc-5.3.0/bin/ld
Another test: rename the system ld, in my case /usr/bin/ld; the newly-built gcc should still work.
Of course, this applies to both ld and as.
Setting AS and LD environment variables to point to the newly-built binaries from the binutils package did not work: the -print-prog-name=... still showed default tools, and removing/renaming the default tools caused gcc to fail.
Thus the best way of accomplishing this is to build binutils first and then use the --with-ld and --with-as options to configure. If you also want to ensure that the newly-built binutils are used to build GCC, you may want to put them in the PATH before the system-provided tools, or you can even rename the system-provided tools to keep them out of the picture.
Thank you for checking with another mailing list to verify that building GCC and binutils together doesn't work unless they are pulled from the source control, I guess that option is not applicable when using downloaded tarballs. Overall this was an interesting exercise.

I want to type "g++" instead of "i686-pc-cygwin-g++" on Cygwin64 Terminal?

Everytime I have to compile with Cygwin64 Terminal, I have to write
$ i686-pc-cygwin-g++ myFile.cpp
Is there a way I can tell Cygwin that whenever I type g++ I'm actually referring to i686-pc-cygwin-g++ since it says -bash: g++: command not found
when I type g++ .
If there are no at all link to g++ in one of standard directories, like /usr/bin/g++, just create it.
Soft link:
ln -s 'path/to/i686-pc-cygwin-g++' '/usr/bin/g++`
Or even hard link:
ln 'path/to/i686-pc-cygwin-g++' '/usr/bin/g++'
Those are base commands, must be available in any bash shell.
The directory /usr/bin must be in the standard search path.
If link exists or if you use several compilers and want to switch between them, you can install and use update-alternatives, like
sudo update-alternatives --install /usr/bin/g++ g++ /path/to/i686-pc-cygwin-g++ 10
where 10 is priority.
Switch between them with:
sudo update-alternatives --config g++
remove all:
sudo update-alternatives --remove-all g++
As #Amadeus mentioned, it worked :
$ alias g++=i686-pc-cygwin-g++
Made me able to type g++ instead of i686-pc-cygwin-g++

Can I build gcc for ARM with an X64 one?

I need a definitive answer because this is still unclear to me and I can't find an explicit answer anywhere in the docs.
Assuming that I have a working gcc toolchain where
host x86_64-linux-gnu
target x86_64-linux-gnu
, the question is can I possibly configure and build gcc from sources with ?
host x86_64-linux-gnu
build x86_64-linux-gnu
target arm-gnu-eabi
The reason why I would like an answer on this is about whether or not I should spend time trying different configurations for my libraries and whether or whether or not the scripts used to build gcc are capable of some implicit stage 1 build that can potentially bootstrap an ARM compiler for me temporarily on this x64, so I can generate the toolchain that I need for the target that I want .
"Can I build gcc for ARM with an X64 one?"
Yes, you can. I have described this process for a suse linux host development system in a blog post of mine.
==================================================================================
I'm going to replicate the steps here:
1. Ensure to have the necessary headers & libraries installed
I have used YAST's 'Install Software' feature, to install the following packages that will be necessary to complete all the build steps (just search for the package names, select and accept):
gmp-devel
mpfr-devel
mpc-devel
texinfo
ncurses-devel
termcap
2. Create a directory skeleton
cd ~
mkdir arm-none-eabi arm-none-eabi-src
cd arm-none-eabi
mkdir src build
cd ~/arm-none-eabi-src
mkdir src build
3. Download the the source packages and extract them
I'm using gcc-4.7.1 here, but the same process will of course apply for newer versions of GCC.
cd ~/arm-none-eabi-src/src
wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.7.1/gcc-4.7.1.tar.bz2
wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
wget ftp://ftp.gnu.org/gnu/gdb/gdb-7.4.tar.bz2
wget ftp://sources.redhat.com/pub/newlib/newlib-1.20.0.tar.gz
tar -xf gcc-4.7.1.tar.bz2
tar -xf binutils-2.22.tar.bz2
tar -xf gdb-7.4.tar.bz2
tar -xf newlib-1.20.0.tar.gz
4. Build the binutils
cd ~/arm-none-eabi-src/build
mkdir binutils-2.22
cd binutils-2.22
../../src/binutils-2.22/configure \
--target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi \
--with-cpu=cortex-m3 \
--with-no-thumb-interwork \
--with-mode=thumb
make all install
export PATH="$PATH:$HOME/arm-none-eabi/bin"
5. Build GCC (Part1)
cd ~/arm-none-eabi-src/build
mkdir gcc-4.7.1
cd gcc-4.7.1
../../src/gcc-4.7.1/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi --with-cpu=cortex-m3 \
--with-mode=thumb --disable-multilib \
--with-no-thumb-interwork \
--enable-languages="c,c++" --with-newlib \
--with-headers=../../src/newlib-1.20.0/newlib/libc/include
make all-gcc install-gcc
The --enable-cxx-flags configure option might be additionally used to control the build flags of the libstdc++ (included in this step):
--enable-cxx-flags='-fno-exceptions \
-ffunction-sections -fno-omit-frame-pointer'
In general the same C++ compile flags should be used as they'll appear when building the intended target code.
6. Build GCC newlib with the cross compiler (Part2)
cd ~/arm-none-eabi-src/build
mkdir newlib-1.20.0
cd newlib-1.20.0
../../src/newlib-1.20.0/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi --disable-multilib \
--disable-newlib-supplied-syscalls
make all install
A note about the --disable-newlib-supplied-syscalls option:
Disabling the default newlib syscall stub implementation is generally a good idea when you intend to compile for targets without using a linux like operating system, or no OS at all. It will leave you with linker errors on unimplemented stub functions you'll need to provide for newlib.
Removing the option will still enable you to override the newlib provided stubs with your own implementations.
Though, when you plan to use the cross-toolchain in conjunction with CMake, you should omit this option. CMake does some basic tests using the specified compiler definitions (e.g. from a toolchain.cmake file), that'll fail without the default stub implementations supplied.
7. Complete installing GCC
cd ~/arm-none-eabi-src/build/gcc-4.7.1
make all install
8. Build GDB
cd ~/arm-none-eabi-src/build
mkdir gdb-7.4
cd gdb-7.4
../../src/gdb-7.4/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi
make all install
UPDATE
The same works pretty well for GCC 4.8.2 also.

"make[2]: g++: Command not found" in Netbeans

I get the error message:
make[2]: g++: Command not found
which I know means it cannot find the C++ compiler. However, in Netbeans if I go to the configuration to choose my C++ compiler it shows the following being in /usr/bin:
g++4.6
g++4.7
g++4.8
but it doesn't have just g++.
Tried sudo aptitude install g++ but it didnt work.
If I do g++ --version I get:
The program 'g++' can be found in the following packages:
* g++
* pentium-builder
1) Verify you can run "g++" from the command line,
2) type whereis g++ to get the path,
3) Make sure you have the NetBeans C++ plugin installed
Go to Tools->Options->C++->Build Tools
4) Configure the path in NetBeans
Usually, /usr/bin/g++ is a symlink to some /usr/bin/g++-4.7 (or g++-4.8 etc...); just make it again (which is usually provided by the g++ virtual package on Debian or Ubuntu), e.g.
% sudo -s
# cd /usr/bin
# ln -sv g++-4.8 g++
Above % and # are shell prompts that you should not type.
Of course, don't forget the sudo apt-get install g++ etc...
BTW, you might put that link from $HOME/bin/g++ to /usr/bin/g++-4.8 and you don't need root permission for that.
(sometimes, these symlinks go indirectly thru /etc/alternatives etc...)
Your issue is a sysadmin issue; you should rather ask it (with a big lot more details) on askubuntu or superuser; it is off-topic on Stack Overflow.
BTW, NetBeans is not a compiler, but an editor (sometimes called IDE). You could use something better/simpler (e.g. emacs or vim) with e.g. make as a builder (to be run inside a terminal). Before using NetBeans ensure that g++ -v is working alone in some terminal

Error in making OpenCV

I'm getting this error:
OpenCV-2.4.3/modules/features2d/src/freak.cpp:437: error: unable to
find a register to spill in class 'GENERAL_REGS'
After doing:
tar xfj OpenCV-2.4.3.tar.bz2
cd OpenCV-2.4.3
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_NEW_PYTHON_SUPPORT=ON -D BUILD_EXAMPLES=ON ..
make
The same procedure works on another machine. Any ideas?
You need to dig into the Makefiles to remove -O for freak.cpp.
UPDATE:
This is exactly how one should do it (tested with 2.4.3 and 2.4.4).
you need to edit
YOUR_BUILD_DIR/modules/features2d/CMakeFiles/opencv_features2d.dir/build.make
Search for freak.cpp. You find three blocks: Building CXX..., Preprocessing CXX..., and Compiling CX.... I just needed to change the Building part. The last line of that block looks like this:
.... YOUR_COMPILER $(CXX_DEFINES) $(CXX_FLAGS) ...
and if you check you find out that CXX_FLAGS has a -O3 in it. If you add -O0 after CXX_FLAGS it suppresses the O3. So your lines should look like this.
.... YOUR_COMPILER $(CXX_DEFINES) $(CXX_FLAGS) -O0 ...
This is at least working here!
I struggled with this for quite a few hours as well on my CentOS 5.x boxen, and here's my solution.
It's apparent you need to update 'gcc' but natively upgrading via RPM or just grabbing RPM's at random causing some serious config mgmt issues on your server. I don't have time to compile gcc/g++ via source right now either. After grazing out in the repo for a while, I found that there is, indeed, an 4.x release of gcc in the base repo.
Do this (or someone with 'root' to do it in case of OP who doesn't have access):
# yum install gcc44 gcc44-c++ -y
...CentOS/RHEL have bundled a preview RPM of gcc-4.4.6.
Then when you go to do 'cmake' to build your release environment, do at least the following (your cmake params may vary):
# cd /path/to/OpenCV-2.4.3
# mkdir release && cd release
# env CC=/usr/bin/gcc44 CXX=/usr/bin/g++44 cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/place/to/install/ -D BUILD_PYTHON_SUPPORT=ON /path/to/OpenCV-2.4.3/
That will give you a successful build of OpenCV-2.4.3 natively with CenOS/RHEL 5.x.
Had the same problem and solved it like wisehippy with one slight change:
# yum install gcc44 gcc44-c++ -y
# mkdir release && cd release
# cmake -D CMAKE_BUILD_TYPE=RELEASE -DCMAKE_CXX_COMPILER=/usr/bin/g++44 -DCMAKE_C_COMPILER=/usr/bin/gcc44 <OpenCV_Dir>
I found the problem to be solved once I updated my c++ to point to g++44, instead of the default g++ which was 4.1.
As root verify that the files are the same before doing this step, it may not be necessary for you.
diff /usr/bin/c++ /usr/bin/g++
There should be nothing returned if the files are the same. If this is the case, continue.
Backup your old file. You can delete the file as well because it's the same as g++, but I like to be careful.
mv /usr/bin/c++ /usr/bin/c++4.1
Create a link so that C++ points to your g++44. You could use symbolic link here as well.
ln /usr/bin/g++44 /usr/bin/c++
Done.