Tools for Linux 2.6.39 Compilation - linux-kernel

I have started working on linux for about 6 months or so and now I
wanted to compile Linux version 2.6.39. Here are my questions for
the upgrade :
a. How will I get the GCC, Make, BinUtil and other tool dependency
of linux with their versions.
b. After compiling the tools how to make toolchain for linux
compilation.
I have searched various websites for this. I got information in bits and pieces and for specific linux versions. Is their a site or something where I can get all the information about the upcoming linux upgrades with the details.
My Current Linux machine details are :
Distro : CentOS 4.8
Linux version : 2.6.9
Gcc Version : 3.4.6
Binutils : 2.15.92
Make : 3.80
-Tommy

There are 2 options, depending on that type of kernel you want to build:
If you want a kernel for your machine (or a similar one), you can use the GCC that you already have from your distro.
If you want a kernel for another architecture (like ARM, MIPS, etc) you NEED a cross-compiler. You can build a cross-compiler (a whole toolchain, actually) using something like crosstool-ng.
With crosstool-ng you can also build yourself a toolchain for the first case. This tool take care of downloading the tarballs with the sources for GCC, Binutils, glibc, etc.
If you just want to upgrade the kernel on your machine, regardless of the version, the steps are mostly the same:
Get the source with
wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.9.tar.bz2 or something similar
extract them with tar xjvf linux-*.tar.bz2 and then exter that folder
make oldconfig or make menuconfig or even better make localmodconfig
make
make install as root

Related

GCC Cross Compiler for linux under msys2

I'm looking for a cross compiler to compile for linux under the msys2 environment.
I'm looking for somethink like x86_64-w64-linux-gcc. But I can't find it.
Which package I have to install?
You'll need a VM or a Linux machine to test the resulting binaries, so I'd just compile on one in the first place.
But cross-compilation should be possible too:
Boot up your favorite Linux distribution in a VM.
Install the libraries you want to have. Install g++ to get libstdc++, and possibly other basic libraries.
Copy the root directory / from the VM to the Windows machine.
You only need headers and libraries, not everything. You'll have to experiment to know what directories can or can't be safely removed.
Install Clang on the Windows machine. Installing LLD is also a good idea (it's a separate package in MSYS2; or, if you're using the official Clang binaries, it's bundled with them).
We're using Clang, because it's inherently a cross-compiler, i.e. doesn't require separate binaries to target a different platform, unlike GCC.
Compile with Clang with --target=x86_64-pc-linux-gnu --sysroot=path/to/root/directory.
-fuse-ld=lld is probably a good idea as well.
The string x86_64-pc-linux-gnu was obtained by running clang++ --version on a Linux machine.
You might need a few more flags, but this should be a good starting point.

Is it possible to use a different gcc version inside a Conda environment?

I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).

Is newlib for building cross compiler for powerpc e500mc mandatory?

I am trying to build a cross compiler for PowerPC e500mc with target powerpc-e500mc-eabi. As some websites mentioned, i built an bootstrap compiler first. and then tried to compile newlib with it. But i got some error like,
/bin/sh: powerpc-e500mc-eabi-cc: command not found
I want to know, can we directly compile GCC cross compiler without newLib. Also, can anyone tell me the exact pre-requisites for powerpc e500mc architecture. I have GMP, MPC, MPFR, BinUtils not sure whether newLib required or not.
You can build gcc without any C library, there is no need for newlib. Please find a list of dependencies from a crosstool-ng build below.
1. Alternatives
You can build everything manually, what you obviously attempted to do. This is possible but there are various constraints to keep in mind, for instance builds might fail if your filesystem is not case sensitive or if you build inside your source directory. Besides all the dependencies and their versions.
You let crosstool-ng build your cross toolchain. Crosstool-ng is mostly self-contained with few external dependencies. It will download and build all dependencies in the right versions for you, and it comes with various sample configurations. It will check for obstacles like a case insensitive filesystem. It lets you configure your cross toolchain in a similar way you configure a Linux kernel. I've built various cross toolchains by means of it for several years on several host systems without trouble, including Linux, OS X (homebrew) and Windows (cygwin). You find it here: http://crosstool-ng.org/.
I'm going to line out the steps that it takes to build a cross toolchain by means of crosstool-ng. I tested this setup on Windows (cygwin) today with the crosstool-ng from git.
2. Download crosstool-ng, build and install it.
Follow the steps in
docs/2 - Installing crosstool-NG.txt.
3. Configure your cross toolchain.
Follow the steps in
docs/3 - Configuring a toolchain.txt.
4. Example
mkdir powerpc-e500v2-eabi
cd powerpc-e500v2-eabi
ct-ng powerpc-e500v2-linux-gnuspe
The last step will create a configuration from a sample which I thought is similar enough to what you want. In the next step, we will adapt this configuration, the criteria are
no operating system
no C library
EABI
you want e500mc, the sample is e500v2. I leave it up to you to adapt the configuration to it.
4.1. Configuration
ct-ng menuconfig
Operating System
Target OS
Select bare-metal
C-library
C library
Select none
Target options
ABI
Select EABI
C-Compiler
gcc version
Select 5.1.0 (the sample configured a gcc 4.6.4
here)
Deselect C++ (since you do not want a C library
either and it'd pull extra dependencies)
Debug facilities
Deselect gdb (unless you want it, can pull extra dependencies)
4.2. Build
ct-ng build.4
Crosstool-ng will download and build the following dependencies.
gmp-6.0.0a
mpfr-3.1.2
isl-0.14
mpc-1.0.2
binutils-2.25
gcc-5.1.0
It will install the cross toolchain in
${HOME}/x-tools/powerpc-e500v2-eabi.
You can specify a different install prefix in the configuration.
This build issue can be fixed by creating a symlink powerpc-e500mc-eabi-cc pointing to powerpc-e500mc-eabi-gcc.

How to build binutils for a specific target

I'm trying to configure binutils for an ARM processor, specifically the ARMv5TE. The processor is the Marvell 88F5281. Presently the device is running NetBSD, so I want to make sure I configure binutils for the right target arch / OS.
Is there a way to list a combination of targets / OSes when configuring binutils?
So far I found, arm-*-netbsdelf from the following page, http://gcc.gnu.org/install/specific.html#arm-x-eabi
But I am still wondering if there is a list of targets / OSes when I run the configure script from the command line.
A good place to start might be the NetBSD build.sh, which is designed to build a complete cross compiler toolset for a NetBSD target on a POSIX host.
Download and extract the source tree for the NetBSD version your target is running
Run './build.sh -m evbarm tools'
When completed it should tell you where to find built binutils and cross compiler
Note - if the target is bigendian you will need to use evbarm-eb in the build.sh command.

How to compile for legacy os

I am using Cent OS 5.
It has legacy package installed.
With what version of gcc should I compile ?
Does it really required to compile with old gcc version to support old linux os ?
if yes why ?
I'm going to start off by saying that the easiest way to get software builds that will work on CentOS 4, or even older, is to build the code on those target distributions, or ship your code with some scripts/tools to make it easy to recreate a build on that machine. If you've ever downloaded a source code release, and did the /.configure && make && make install steps, this is what I'm talking about.
Those source releases are built upon the GNU Autotools system, which gives you auto-configuration (it determines what can and can't be used on the target system) and generates a makefile to build with.
There are alternatives to the GNU Autotools system (which, frankly, I find a chore to learn and use), like cmake and scons. Here is a page (on scons) which compares the popular build tools:
http://www.scons.org/wiki/SconsVsOtherBuildTools
So what if you still want to build on your CentOS 5 machine for older CentOS installs?
Now for why you do need legacy libraries and compilers to build with, if you want to build on your CentOS 5 system:
So you have CentOS 5, which runs this toolchain:
gcc 4.1.2
glibc 2.5.x
libstdc++ 4.1.2
And CentOS 4, which runs this toolchain:
gcc 3.4.x
glibc 2.3.x
libstdc++ 3.4.x
The big problem is that if you were to just build C or C++ software with the standard CentOS 5 tools, they would be linked to the CentOS 5 C and C++ libraries (glibc, libstdc++, libgcc), and these libraries are not backward compatible with older releases. That is, software built for glibc 2.5.5 is in no way guaranteed to run with glibc 2.4, or even glibc 2.5.4 (though unless there are special circumstances, you would be able to run glibc 2.4-built software on glibc 2.5.x). You will also need to build the dependencies against the older library versions.
When you go even older, you will need to build a cross-compiler (look up crosstool) that will allow you to target builds for older systems, that will link to the older versions of libc and other dependencies built against that as well.
Is there something else besides building on the target and such?
You could static link all your dependencies into the binary, so you wouldn't have to worry about the dependencies and such. However, I have never done such a thing and I forget if there was some problem to linking glibc statically, or if I'm thinking of some other major library that posed issues with static linking (on a technical level).

Resources