Make updated GCC active - Linux

[Circlotron]

Just now I compiled GCC from source and installed it, but if I check the --version at the command line it still shows "gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0" the old version. There is definitely a /usr/local/gcc-14.2.0 folder, so the new one did install. How do I make the new one active? Can I simply remove the old one using apt?

[eutectique]

If you say which gcc -- what does it show?
You can uninstall the old one (if it was installed).

I usually install compilers into /opt directory, have symbolic links to whatever I want by default, and add /opt to the PATH :

Code: [Select]

> ll /opt/
total 32K
drwxr-xr-x  9 censored censored 4.0K Jun 15  2023 LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/
drwxr-xr-x  6 censored censored 4.0K Jun 15  2023 gcc-arm-none-eabi-10.3-2021.10/
lrwxrwxrwx  1 censored censored   30 Jun 15  2023 gcc-arm -> gcc-arm-none-eabi-10.3-2021.10/
lrwxrwxrwx  1 censored censored   47 Jun 15  2023 llvm-arm -> LLVMEmbeddedToolchainForArm-16.0.0-Linux-x86_64/


[Circlotron]

which gcc --- says /usr/bin/gcc

[Circlotron]

How to I change the path to the new folder?

[brucehoult]

Just now I compiled GCC from source and installed it, but if I check the --version at the command line it still shows "gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0" the old version. There is definitely a /usr/local/gcc-14.2.0 folder, so the new one did install. How do I make the new one active? Can I simply remove the old one using apt?

I highly doubt that /usr/local/gcc-14.2.0 or any subfolder of that will be already in your PATH.  But /usr/local/bin probably is. When you build the gcc you should specify just --PREFIX=/usr/local.

But I don't like that, and myself would mkdir /opt/gcc-14.2.0; chown me:me /opt/gcc-14.2.0 and then set that as the install location. And then add /opt/gcc-14.2.0/bin to PATH in e.g. your .bashrc

[langwadt]

which gcc --- says /usr/bin/gcc

/usr/bin/gcc is just a symbolic link

ls -la /usr/bin/gcc

to see what it points to

[Circlotron]

which gcc --- says /usr/bin/gcc

/usr/bin/gcc is just a symbolic link

ls -la /usr/bin/gcc

to see what it points to

lrwxrwxrwx 1 root root 5 May 21  2019 /usr/bin/gcc -> gcc-7

[Circlotron]

Just now I compiled GCC from source and installed it, but if I check the --version at the command line it still shows "gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0" the old version. There is definitely a /usr/local/gcc-14.2.0 folder, so the new one did install. How do I make the new one active? Can I simply remove the old one using apt?

I highly doubt that /usr/local/gcc-14.2.0 or any subfolder of that will be already in your PATH.  But /usr/local/bin probably is. When you build the gcc you should specify just --PREFIX=/usr/local.

But I don't like that, and myself would mkdir /opt/gcc-14.2.0; chown me:me /opt/gcc-14.2.0 and then set that as the install location. And then add /opt/gcc-14.2.0/bin to PATH in e.g. your .bashrc

Could i just add add /usr/local/gcc-14.2.0/bin to PATH in  .bashrc ?
There doesn't seem to be any path references in .bashrc   Not sure what I am looking for though.

[Circlotron]

If I type apt list --installed in the terminal it does not list version 14.2.0 so presumably it cannot be removed by apt. So is it okay to simply delete the /usr/local/gcc-14.2.0/bin folder where it currently resides, and reinstall to /usr/bin ? Or what if I simply copy the folder to there, or will that break lost of stuff?

[magic]

Could i just add add /usr/local/gcc-14.2.0/bin to PATH in  .bashrc ?

Yes.

Maybe it won't be enough, but that's the starting point for bash to find your gcc binaries at all.

Code: [Select]

export PATH=/usr/local/gcc-14.2.0/bin:$PATH
BTW, the convention is that you install things directly into /usr/local (so the required path is /usr/local/bin, which is probably in your PATH variable already) and if you want to use a subdirectory for each software package, you put that stuff into /opt as brucehoult did.

[Nominal Animal]

You have compiled a local version of gcc for your system and installed it outside/bypassing the package management system.

I wouldn't do it that way.  gcc-14.2.0-2 is already in Debian (Sid), so you could just install that one.  After removing the /usr/local/gcc-14.2.0 tree, of course.  Ubuntu, Mint, et cetera are all derivatives of Debian (and use many Debian packages directly), so using Debian packages is perfectly okay.

The other option is to create your own gcc variant package per Guide for Debian Maintainers, and install that package.

Basically, it involves renaming the sources to packagename_version.orig.tar.{xz,gz,bz2}, extracting them to a directory named packagename-version/, changing to that directory, running dh_make --s to initially create the Debian tooling under debian/ for a single package, editing the files under debian/ with debian/rules (a Makefile used by the Debian tooling) something like

Code: [Select]

#!/usr/bin/make -f
CONFIGURE_FLAGS := --prefix=/usr
%:
dh $@
where the last line indent is a single TAB and not spaces (run sed -e 's|^  *|\t|' -i debian/rules), with CONFIGURE_FLAGS being the Make variable passed to configure; you might wish to use CONFIGURE_FLAGS += additional option(s) instead, perhaps repeatedly, to just add to the defaults, instead of replacing them with the single prefix one as above.  Ensure the top entry in debian/changelog refers to an UNRELEASED distribution, if you don't want to sign the packages.
The binary package is created by running dpkg-debuild -i -us -uc b in the packagename-version/ directory.

For many packages you can find the debian/ tooling as a packagename_version.debian.tar.xz at packages.debian.org.  Unfortunately, gcc-14 builds a lot of stuff and is one of the most complex ones.  As a typical example, coreutils (that provides most of the core command-line utilities like cat and chmod we expect to have available under /bin and /usr/bin), has just a 67-line debian/rules, and would be a much better starting point for someone to look at practical Debian tooling files.

I warmly recommend taking a day or so to find out how to package Debian .deb packages and experiment with it, until you feel comfortable.  It is worth it. Do bookmark or record on paper the URLs for the tutorials/guides, because you will forget it (temporarily) soon, but quickly re-reading the relevant guides/manuals will refresh your memory.  There is a set of details in debian/ tooling to work out and remember, especially the debian/changelog and how it affects package versioning, but none of them are very complicated.  You'll see.

For anyone else to reproduce the build (to as exactly as is typically necessary), you only need to provide (the original source tarball and) a tarball containing the proper debian/ tooling, even for different Linux hardware architectures.  Note that the base directory is always debian/ for the tooling archive; never packagename-version/debian/.  In most cases the same tooling works for a new source version, so you only need to add a changelog entry and bump up the version numbers.

[Circlotron]

Thanks for your replies everybody, especially your's Nominal Animal. After getting thoroughly bamboozled by this whole situation, and especially since I just saw that Mint 22 has now been released that comes with gcc 13, and I was thinking of upgrading from scratch anyway (stuck with 19.3 which is difficult and messy to upgrade from) I'll just take that approach and be done with it.