Building from source
I chose to install Atom which is a very powerful text editor. This installation, overall, was a terrible experience as i spent a lot of time trying to install it and then realizing that i couldn’t at first (which i’ll get to in a moment) and then trying to do on a second machine and everything was going well but even then wasn’t able to. The reason i couldn’t install it is because at first I tried to install it on Aarchie which is the ARM64 machine. I got quite far into the installation with Archie but then hit a roadblock. The roadblock was a dependency which wasn’t supported for ARM64 machines. All other dependencies were supported and just this one wasn’t hence stopping the entire installation. What I did first is head over to this link: https://flight-manual.atom.io/hacking-atom/sections/hacking-on-atom-core/#platform-linux, which i found through Google, and followed the steps. I first forked Atom’s git repo with my account so i can actually clone it. Then I ran the bootstrap script which is located under “[atom repo]/scripts/bootstrap”. This bootstrap script installs all the dependencies, at least after it detects a nodejs installation in the system. It didn’t pick up nodejs as it’s not installed in the server so then I head over to nodejs’s website, downloaded the binary for arm64, put it under a node folder on the server so I install node locally only, and then exported node’s binary location into the environment variables. Then again I ran the bootstrap script and this time it gave me about 2 full pages (8×11) of errors. Now this was extremely overwhelming so I started Googling and found out that I needed to install the “build-tools” for npm (node package manager). So then I just ran the command “npm install build-tools -g (for global)” in hopes that it would install all the missing dependencies and let me install atom. It didn’t. Npm failed at installing the dependancy called “phantomjs” and after doing research, found out that phantomjs was only available for debian type arm64 machines. This was the roadblock. I now had to either give up and find a compatible arm64 open-source project or use xerxes, the x86_64 machine. I refused to give up and started a ssh session with xerxes.
Now with xerxes everything was going well. I was able to download phantomjs and got quite far into the installation. However, I soon hit another roadblock which, to put it short, kept looking for a dependency in the wrong directory. After hours of trying and waiting (because each time the build is about 20 mins long), i got tired of it and decided to go for something simpler to install. In a sense I didn’t give up because the problem seemed to be with the build tool. The next open-source project I went for is nmap. Nmap is a great tool for analyzing your network essentially. I went on to the site, https://nmap.org/download.html , to download the tool. Xerxes already has a version of nmap so I’m going to install this locally to not overwrite the already installed one. Now this installation took about 5 mins and, thankfully, was successful. I was able to use nmap to analyze certain ips, etc.
My final thoughts on “building from source” process is that it either can be a breeze or a pain in the neck as sometimes you might have to wait for 20 mins (like with atom) to see if you’re missing a dependency or something. That is why you always build in parts so that if you miss something, you don’t have to rebuild the entire thing. This is something I noticed with atom. It didn’t have a “caching” system. Every single time you ran the command build, it literally built the entire thing. I didn’t see any parameters you can pass in from the documentation that would allow you to store what installed successfully, and continue from where the issue was in the build process.
Glibc is the GNU project’s run time implementation of the C language. It was written by Roland McGrath when he started working on it in the 1980’s as a teenager and was initially released in 1987. It is an important part of the Linux community as most Linux based operating systems use it.
MultiArch is a feature that allows running of applications that were built with a different architecture. The glibc has support for MultiArch and therefore allows you to run your C code that was built with a different machine which has different architecture without recompiling it. In short words, MultiArch makes your code portable.
Override is another feature which is also supported by glibc and it allows you to override system related functions with your own implementation. There might be a time where the system related function call is deprecated or is inefficient for your application. The override feature will allow you to run your application with your own implementation of the system function and possibly giving you an edge over the native function.
After installing glibc, I performed a test by writing a simple hello world program that outputs the run time version of glibc. Here is my output:
Overall, my experience with installing and running glibc was much better than with atom/nmap. I got to learn a bit of history about the standard C library as well as glibc while researching about both. One of the observations that I made is while downloading glibc, there were log messages that were constantly being output on the console from the makefile and just thinking about the vast amount of source code that was being compiled was astonishing. And a lot of it was written by one person which to me was astounding.