How to change the default GCC compiler in Ubuntu? - linux

I have installed gcc-3.3/g++-3.3 on ubuntu 11.04 which already has gcc/g++-4.4. So in my system both gcc-3.3 and 4.4 are available. I am able to call both compilers as I want. If I just call the command gcc then gcc-4.4 will get called. To call gcc-3.3, I have to use the command gcc-3.3.
How can I change the default compiler as gcc-3.3? When I execute the command gcc it should call the gcc-3.3 and not gcc-4.4.
In addition, how can I change the variable CXX in a make file to gcc-3.3? I wish to change one common global place in the system instead of changing all make files.

As #Tommy suggested, you should use update-alternatives.
It assigns values to every software of a family, so that it defines the order in which the applications will be called.
It is used to maintain different versions of the same software on a system. In your case, you will be able to use several declinations of gcc, and one will be favoured.
To figure out the current priorities of gcc, type in the command pointed out by #tripleee's comment:
update-alternatives --query gcc
Now, note the priority attributed to gcc-4.4 because you'll need to give a higher one to gcc-3.3.
To set your alternatives, you should have something like this (assuming your gcc installation is located at /usr/bin/gcc-3.3, and gcc-4.4's priority is less than 50):
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-3.3 50
--edit--
Finally, you can also use the interactive interface of update-alternatives to easily switch between versions. Type update-alternatives --config gcc to be asked to choose the gcc version you want to use among those installed.
--edit 2 --
Now, to fix the CXX environment variable systemwide, you need to put the line indicated by #DipSwitch's in your .bashrc file (this will apply the change only for your user, which is safer in my opinion):
echo 'export CXX=/usr/bin/gcc-3.3' >> ~/.bashrc

Here's a complete example of jHackTheRipper's answer for the TL;DR crowd. :-) In this case, I wanted to run g++-4.5 on an Ubuntu system that defaults to 4.6. As root:
apt-get install g++-4.5
update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.6 100
update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.5 50
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 100
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.5 50
update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.6 100
update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.5 50
update-alternatives --set g++ /usr/bin/g++-4.5
update-alternatives --set gcc /usr/bin/gcc-4.5
update-alternatives --set cpp-bin /usr/bin/cpp-4.5
Here, 4.6 is still the default (aka "auto mode"), but I explicitly switch to 4.5 temporarily (manual mode). To go back to 4.6:
update-alternatives --auto g++
update-alternatives --auto gcc
update-alternatives --auto cpp-bin
(Note the use of cpp-bin instead of just cpp. Ubuntu already has a cpp alternative with a master link of /lib/cpp. Renaming that link would remove the /lib/cpp link, which could break scripts.)

This is the great description and step-by-step instruction how to create and manage master and slave (gcc and g++) alternatives.
Shortly it's:
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7
sudo update-alternatives --config gcc

Between 4.8 and 6 with all --slaves:
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 \
10 \
--slave /usr/bin/cc cc /usr/bin/gcc-4.8 \
--slave /usr/bin/c++ c++ /usr/bin/g++-4.8 \
--slave /usr/bin/g++ g++ /usr/bin/g++-4.8 \
--slave /usr/bin/gcov gcov /usr/bin/gcov-4.8 \
--slave /usr/bin/gcov-dump gcov-dump /usr/bin/gcov-dump-4.8 \
--slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-4.8 \
--slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-4.8 \
--slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-4.8 \
--slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-4.8
and
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 \
15 \
--slave /usr/bin/cc cc /usr/bin/gcc-6 \
--slave /usr/bin/c++ c++ /usr/bin/g++-6 \
--slave /usr/bin/g++ g++ /usr/bin/g++-6 \
--slave /usr/bin/gcov gcov /usr/bin/gcov-6 \
--slave /usr/bin/gcov-dump gcov-dump /usr/bin/gcov-dump-6 \
--slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-6 \
--slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-6 \
--slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-6 \
--slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-6
Change between them with update-alternatives --config gcc.

Now, there is gcc-4.9 available for Ubuntu/precise.
Create a group of compiler alternatives where the distro compiler has a higher priority:
root$ VER=4.6 ; PRIO=60
root$ update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-$VER $PRIO --slave /usr/bin/g++ g++ /usr/bin/g++-$VER
root$ update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-$VER $PRIO
root$ VER=4.9 ; PRIO=40
root$ update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-$VER $PRIO --slave /usr/bin/g++ g++ /usr/bin/g++-$VER
root$ update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-$VER $PRIO
NOTE: g++ version is changed automatically with a gcc version switch. cpp-bin has to be done separately as there exists a "cpp" master alternative.
List available compiler alternatives:
root$ update-alternatives --list gcc
root$ update-alternatives --list cpp-bin
To select manually version 4.9 of gcc, g++ and cpp, do:
root$ update-alternatives --config gcc
root$ update-alternatives --config cpp-bin
Check compiler versions:
root$ for i in gcc g++ cpp ; do $i --version ; done
Restore distro compiler settings (here: back to v4.6):
root$ update-alternatives --auto gcc
root$ update-alternatives --auto cpp-bin

I found this problem while trying to install a new clang compiler. Turns out that both the Debian and the LLVM maintainers agree that the alternatives system should be used for alternatives, NOT for versioning.
The solution they propose is something like this:
PATH=/usr/lib/llvm-3.7/bin:$PATH
where /usr/lib/llvm-3.7/bin is a directory that got created by the llvm-3.7 package, and which contains all the tools with their non-suffixed names. With that, llvm-config (version 3.7) appears with its plain name in your PATH. No need to muck around with symlinks, nor to call the llvm-config-3.7 that got installed in /usr/bin.
Also, check for a package named llvm-defaults (or gcc-defaults), which might offer other way to do this (I didn't use it).

In case you want a quicker (but still very clean) way of achieving it for a personal purpose (for instance if you want to build a specific project having some strong requirements concerning the version of the compiler), just follow the following steps:
type echo $PATH and look for a personal directory having a very high priority (in my case, I have ~/.local/bin);
add the symbolic links in this directory:
For instance:
ln -s /usr/bin/gcc-WHATEVER ~/.local/bin/gcc
ln -s /usr/bin/g++-WHATEVER ~/.local/bin/g++
Of course, this will work for a single user (it isn't a system wide solution), but on the other hand I don't like to change too many things in my installation.

I used just the lines below and it worked. I just wanted to compile VirtualBox and VMWare WorkStation using kernel 4.8.10 on Ubuntu 14.04. Initially, most things were not working for example graphics and networking. I was lucky that VMWare workstation requested for gcc 6.2.0. I couldn't start my Genymotion Android emulators because virtualbox was down. Will post results later if necessary.
VER=4.6 ; PRIO=60
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-$VER $PRIO --slave /usr/bin/g++ g++ /usr/bin/g++-$VER
VER=6 ; PRIO=50
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-$VER $PRIO --slave /usr/bin/g++ g++ /usr/bin/g++-$VER
VER=4.8 ; PRIO=40
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-$VER $PRIO --slave /usr/bin/g++ g++ /usr/bin/g++-$VER

Related

How do I add nvim to update-alternatives when using snap under Ubuntu

I'd like to add nvim (a snap) to update-alternatives. The problem is that snap seems to work in mysterious ways when determining which program to run:
$ sudo update-alternatives --install /usr/bin/vim vim /snap/bin/nvim 60
$ vim # works
$ vim hello.txt
error: unknown command "hello.txt", see 'snap help'.
If I look at /snap/bin/nvim it is a link to /usr/bin/snap:
$ ls -lah /snap/bin/nvim
lrwxrwxrwx 1 root root 13 Jan 25 15:02 /snap/bin/nvim -> /usr/bin/snap
But how does the snap executable determine it needs to run nvim
In order to use it like that you have to create a script that starts nvim like this:
#!/usr/bin/env bash
/usr/bin/snap run nvim ${#}
Lets say you call it nvim_start.sh. Now you can use this script in your update-alternatives commands (remember to enable the execution flag):
CUSTOM_NVIM_PATH=/usr/bin/nvim_start.sh
sudo chmod +x "${CUSTOM_NVIM_PATH}"
set -u
sudo update-alternatives --install /usr/bin/ex ex "${CUSTOM_NVIM_PATH}" 110
sudo update-alternatives --install /usr/bin/vi vi "${CUSTOM_NVIM_PATH}" 110
sudo update-alternatives --install /usr/bin/view view "${CUSTOM_NVIM_PATH}" 110
sudo update-alternatives --install /usr/bin/vim vim "${CUSTOM_NVIM_PATH}" 110
sudo update-alternatives --install /usr/bin/vimdiff vimdiff "${CUSTOM_NVIM_PATH}" 110
sudo update-alternatives --set ex "${CUSTOM_NVIM_PATH}"
sudo update-alternatives --set vi "${CUSTOM_NVIM_PATH}"
sudo update-alternatives --set view "${CUSTOM_NVIM_PATH}"
sudo update-alternatives --set vim "${CUSTOM_NVIM_PATH}"
sudo update-alternatives --set vimdiff "${CUSTOM_NVIM_PATH}"
I'm not sure why using /snap/bin/nvim does not work, even when called from inside the script. At least the workaround works OK.

Is it possible to change glibc's default rpath? [duplicate]

I'm trying to build and install my own gcc 4.7.2 in /usr/local to use in place of the gcc 4.4.6 in /usr. (This is on CentOS 6.3.)
gcc makes executables and dynamic libraries that dynamically link to its own dynamic libraries, e.g. libstdc++.so. How do I build and install gcc so that the generated binaries automatically get a linker -rpath option (-rpath /usr/local/lib64) that causes dynamic libraries in /usr/local/lib64 to be linked instead of those in /usr/lib64 or /lib64?
If it works properly, after I build an executable with the gcc without specifying "-Wl,-rpath=/usr/local/lib64", when I ldd the executable, it should show /usr/local/lib64/libstdc++.so.6 instead of /usr/lib64/libstdc++.so.6. Similarly for the libgcc_s.so.1.
I have tried different approaches, including specifying LDFLAGS_FOR_TARGET=-Wl,-rpath=/usr/local/lib64,-rpath=/usr/local/lib on the 'configure' command-line, but nothing worked.
If you don't want to export paths there's an alternative solution:
with your toolchain in the PATH:
gcc -dumpspecs > specsfile
edit specsfile and in the section link add your -rpath example:
*link:
%{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic} -dynamic-linker %(dynamic_linker)} %{static:-static}} -rpath /usr/local/lib64
at this point you can test if it work with:
g++ -specs=specsfile test.cpp
readelf -d a.out |grep RPATH
if it work you can make it permanent (no need to pass -specs everytime)
strace -fF -o /tmp/g++.log g++ test.cpp
grep specs /tmp/g++.log
the grep should show the paths where gcc look for the default specs file.
The specs files are flexible enough to allow conditional linking depending on variables, example:
{!static: %{mabi=n32:-rpath-link %R/lib32:%R/usr/lib32} %{mabi=64:-rpath-link %R/lib64:%R/usr/lib64} %{mabi=32:-rpath-link %R/lib:%R/usr/lib}}
should use different and multiple paths depending on mabi (untested, yet), %R should be the sysroot path, can be changed with needed full path.
There's also a --with-specs= option gcc configure eventually to be used at build time, not clear to me yet how to use with the link section (working on it).
--with-specs="%{shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}%{!shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}"
It work, I used both shared and not !shared just for test, probably some smarter condition should be used, note that it isn't reported with -dumpspecs.
Reading through some thread of the gcc mailing list I had the impression specs aren't liked by everyone (but if I'm not wrong 4.9 add another option --with-extra-specs) instead preferred way to do such customizations appears to be configure.host, but I'm done and not looking into it, have fun! :-)
see also: gcc faq rpath
update above
I don't know if you can set a pre-defined rpath, probably if you can would be in the linker ld of binutils not in gcc/g++, but why would you do that?
Just export LD_LIBRARY_PATH at runtime and LD_RUN_PATH at build time
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
ldd a.out
ldd should show the paths you exported.
To quote a message given when a shared library is built with libtool:
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
add LIBDIR to the `LD_RUN_PATH' environment variable during linking
use the `-Wl,--rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
for completeness
the Makefile I used for testing the thing, all the configure options, environment variables (see boot ldflags) I tried didn't work, --enable-rpath included.
use with mkdir ~/gcc copy the Makefile below into ~/gcc then cd ~/gcc && make build-gcc
notice the options used are only for this test case, don't use as reference.
FETCH = aria2c --file-allocation=none -c -d dl
NICE = nice -n 19
PARALLEL = -j4
DESTDIR = $(HOME)/gcc/install
SRCDIR = $(HOME)/gcc/src
all:
# if more downloads are added just remove {dl,src}/*-my-stamp not the .bak
# the .bak should avoid to rebuild targets because of timestamp
touch_stamp = if [ -f $#.bak ]; then \
touch -r $#.bak $#; \
else \
touch $# $#.bak; \
fi
dl/dl-my-stamp:
$(FETCH) https://ftp.gnu.org/gnu/gcc/gcc-4.7.2/gcc-4.7.2.tar.bz2
$(FETCH) http://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2
$(FETCH) ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz
$(FETCH) https://ftp.gnu.org/gnu/mpfr/mpfr-2.4.2.tar.bz2
$(FETCH) --check-certificate=false http://www.mirrorservice.org/sites/sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2 \
ftp://sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2
$(touch_stamp)
untar_dep = src/untar-my-stamp
src/untar-my-stamp: dl/dl-my-stamp
mkdir -p src
tar -C src -xjf dl/gcc-4.7.2.tar.bz2
tar -C src -xjf dl/gmp-4.3.2.tar.bz2
tar -C src -xzf dl/mpc-0.8.1.tar.gz
tar -C src -xjf dl/mpfr-2.4.2.tar.bz2
tar -C src -xjf dl/binutils-2.24.51.tar.bz2
$(touch_stamp)
define configure-rule
$(1)_install = $(DESTDIR)/$(1)-install-my-stamp
$(1)_builddir = $$($(1)_dir)/build
$(DESTDIR)/$(1)-install-my-stamp: $$($(1)_deps)
mkdir -p $$($(1)_builddir)
cd $$($(1)_builddir) && \
$$($(1)_env) ../configure --cache-file=$(SRCDIR)/$(1)-config.cache \
$$($(1)_configure)
$(NICE) make -C $$($(1)_builddir) $$($(1)_make_target) $(PARALLEL)
ifneq ($$($(1)_post_make),)
$$($(1)_post_make)
endif
touch $$#
.PHONY: build-$(1) clean-$(1)
build-$(1): $$($(1)_install)
clean-$(1):
-rm -fr $$($(1)_builddir)
endef
gmp_dir = src/gmp-4.3.2
gmp_env = CONFIG_SITE=$(SRCDIR)/config.site
gmp_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static --enable-cxx
gmp_deps = $(untar_dep)
gmp_make_target = install
$(eval $(call configure-rule,gmp))
mpfr_dir = src/mpfr-2.4.2
mpfr_env = CONFIG_SITE=$(SRCDIR)/config.site
mpfr_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR)
mpfr_deps = $(untar_dep) $(gmp_install)
mpfr_make_target = install
$(eval $(call configure-rule,mpfr))
mpc_dir = src/mpc-0.8.1
mpc_env = CONFIG_SITE=$(SRCDIR)/config.site
mpc_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR)
mpc_deps = $(untar_dep) $(gmp_install) $(mpfr_install)
mpc_make_target = install
$(eval $(call configure-rule,mpc))
gcc_dir = src/gcc-4.7.2
gcc_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
CXXFLAGS="-I/usr/include/i386-linux-gnu"
gcc_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-local-prefix=$(DESTDIR) \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR) \
--with-mpc=$(DESTDIR) \
--disable-bootstrap \
--enable-languages=c,c++ \
--disable-libgomp --disable-multilib \
--disable-libmudflap --disable-libssp \
--disable-libquadmath \
--enable-rpath \
MAKEINFO=missing
gcc_deps = $(untar_dep) $(gmp_install) $(mpfr_install) $(mpc_install)
gcc_make_target =
gcc_post_make = make -C $(gcc_builddir) install
$(eval $(call configure-rule,gcc))
binutils_dir = src/binutils-2.24.51
#binutils_env = LDFLAGS=-Wl,-rpath\ $(DESTDIR)/lib
binutils_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
BOOT_LDFLAGS="-rpath-link=$(DESTDIR)/lib -rpath=$(DESTDIR)/lib"
binutils_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-gmp=$(DESTDIR) \
--enable-rpath
binutils_deps = $(untar_dep) $(gmp_install)
#binutils_make_target = install
binutils_post_make = make -C $(binutils_builddir) install
$(eval $(call configure-rule,binutils))
.PHONY: env
env:
#echo export PATH=$(DESTDIR)/bin:\$$PATH
#echo export LIBRARY_PATH=/usr/lib/i386-linux-gnu
I was installing httpd-2.4.51 and needed to specify -rpath to compile the program. I use the linker flag -Wl,-rpath -Wl,LIBDIR.
Use commands:
sudo mv httpd.c /usr/lib #create a .c file and move it to the default directory for the library file
sudo gcc -o httpd httpd.c -L$--prefix=/usr/lib -lhttpd -Wl,-rpath=$--prefix=/usr/lib
Your can check where you have gcc installed:
whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/share/man/man1/gcc.1.gz

ghc 8.0 cabal build error "ld: -r and -pie may not be used together" known?

After upgrading to ghc 8.0 on a RECENT ubuntu machine, I got the following build error:
/usr/bin/ld: -r and -pie may not be used together
A different error message for the same problem is:
relocation R_X86_64_32 against `.rodata' can not be used when making a > shared object; recompile with -fPIC
Is this a known bug? Are there other solutions?
The solution is to use the linker flag "-no-pie":
cabal -v --ghc-option="-optl-no-pie" install cabal-install
Is suspect it is perhaps an implicit LD flag that is set on ubuntu that is conflicting somehow.
Okay, this is an incredibly! hacky solution, but it did get me past the immediate problem of not being able to build grub. It should work for any other app, but it's so! hacky, I wouldn't leave this in place for very long.
I realize the poster's question is about cabal, not grub. But the problem affects multiple programs and the "correct" solution of using the -fno-pie compiler flag doesn't actually work. Apparently the latest version of gcc sets "pie" on by default, and this takes precedence over the -fno-pie flag. Or at least sometimes.
Here is my working hack for gcc version 6.2.0-5ubuntu12, lubuntu 16.10 (yakkety), linux kernel 4.8.0-22... to build grub 2.02~beta3:
# TO HACK
sudo cp /usr/bin/gcc /usr/bin/gcc.orig
sudo cp /usr/bin/gcc /usr/bin/gcc.patch
sudo rm /usr/bin/gcc
sudo ln -s /usr/bin/gcc.patch /usr/bin/gcc
sudo bless /usr/bin/gcc.patch
# search and replace "-pie -z now" with "-v -z now" (see below)
# save changes and exit 'bless'
That is, use the 'bless' hex editor to search for the text string -pie -z now and change that string to read -v -z now making sure to replace "pie" with "v space space" so it takes up the EXACT same number of characters.
What this does is hack the compiler into sending -v to the linker instead of -pie. If you want to see for yourself what the compiler's doing, just include -Q -v in your compiler's CFLAGS list, and read closely. Even if you specify -fno-pie, the dang thing will still toss out a -pie option to the linker. Anyway, be sure to put everything back when you're done.
# UNDO THE HACK
sudo ln -f -s /usr/bin/gcc.orig /usr/bin/gcc
.
# REDO THE HACK
sudo ln -f -s /usr/bin/gcc.patch /usr/bin/gcc

How to change the default version of gcc man page?

I have installed gcc-4.8 and gcc-6. The default gcc version is gcc-4.8, but I want to change the default gcc version to gcc-6, so I do the following:
$ sudo update-alternatives --remove-all gcc
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 20
then the default gcc version has changed to gcc-6, but when I run command
$ man gcc
the man page version of gcc is still gcc-4.8. How can I change the man page version of gcc to gcc-6? Thanks!
Sorry for my bad English.
I have found the solution:
Find the location of gcc-6 man page:
$ locate gcc-6 | grep 'man'
/usr/share/man/man1/gcc-6.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gcc-6.1.gz
so the location of gcc-6 man page is /usr/share/man/man1/gcc-6.1.gz
Remove the file /usr/share/man/man1/gcc.1.gz if it exist:
$ sudo rm /usr/share/man/man1/gcc.1.gz
Create a symbolic link to /usr/share/man/man1/gcc-6.1.gz:
$ sudo ln -s /usr/share/man/man1/gcc-6.1.gz /usr/share/man/man1/gcc.1.gz
Then run comman:
$ man gcc
You will see the man page version of gcc has changed to gcc-6.
Sorry for my English.

Trouble compiling libtiff 4.0 beta on linux

I'm trying to compile libtiff 4.0 beta to a static library on Ubuntu 10.10 using gcc. It seems to compile the libjpeg and libz fine, which are dependencies. Here is the error I am getting
libtool: link: ( cd ".libs" && rm -f "libtiff.la" && ln -s "../libtiff.la" "libtiff.la" )
\
source='tif_stream.cxx' object='tif_stream.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../config/depcomp \
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -c -o tif_stream.lo tif_stream.cxx
libtool: compile: g++ -DHAVE_CONFIG_H -I. -c tif_stream.cxx -o .libs/tif_stream.o
../libtool: line 990: g++: command not found
Any ideas on how I can fix this?
​Install​ the g++ package​.​
I think that your compile chain is incomplete. On ubuntu, try installing the package called build-essentials. That should pull in all the tools needed to compile c and c++ libraries.

Resources