Lab 2: Building Software

2018-09-20

Part 1: A New Package


I sarted this lab looking through the packages for the coolest sounding one. My eyes came across alive, and that sounds pretty cool to me. To start off, I downloaded the tar file and unpackaged it. Ran the "./configure" and got a big red error saying I needed to install guile-config.
OK, no problem.
I tried using apt-get, dnf but couldn't find it. No matter. I downloaded the tar package, unpacked it, and ran it's configure command.
After about 1000000 check files greeted with no libtdl...
So I tried installing that... guess what I got an error. It said I didn't have libtool, So installed that and got met with a error saying no GNU libunistring
I eventually quit because I think there is a bug saying: GNU libunistring is required, please install it, even though it was installed on the system already.


Ended up adding Gleem, but that was an openGL library that I couldn't build and not a package I could build.


So I tried freedink but I couldn't quite get that to work...
Its a pretty complex game engine, and the install instructions did not recommend installing it through make, but rather use apt-get or dnf.


So now I'm on to GNU fontopia and the configure worked!
Ran make.
Got stuck trying to get this library to work #include <console/dialogs.h>
Couldn't find anything so on to the next software

Started working on ghostscript.
Ran .configure ....no errors.
Ran make
I waited on bated breath as lines and lines passed by, making the package.

To my happyness I saw this: [NateM@aarchie gnu-ghostscript-9.14.1]$ with no giant red warnings
Time for testing... Followed these instructions to an extent: https://www.gnu.org/software/ghostscript/intro.html

Changed to the examples directory, and ran gs chess.ps
IT WORKED!!!!!!


Summary:
So for this package there were no dependencies that needed to be installed. A simple ./configure && make was all it took. I'm a bit bummed out I couldn't get the previous packages installed, please let me know if I was doing something wrong and let me know if you got it working.




Part 2: The Package Strikes Back


Onto glibc.
I made a new directory, then used git to clone the repository, rather than using tar packages like last time. Ran the configure and no errors. NICE! Time for the make file...

Well I'm an old man now. Near on deaths door with all my grandkids around me, and finally a runnable version of glibc.
OK I changed a stdlib file, llabs.c in particular. So if the value given is over 0, it will default return 1000;

#include 

#undef       llabs


/* Return the absolute value of I.  */
long long int
llabs (long long int i)
{
  return i < 0 ? -i : 1000;
}

Ran Make again, and it didn't take forever this time. Just goes to shows the power of make compared to GCC manual compilation. Making a test file for llabs, and here's the output


[NateM@aarchie glibc]$ ./testrun.sh ./firstTry
Current value of i: -5, and the labs return: 5
Current value of i: -4, and the labs return: 4
Current value of i: -3, and the labs return: 3
Current value of i: -2, and the labs return: 2
Current value of i: -1, and the labs return: 1
Current value of i: 0, and the labs return: 0
Current value of i: 1, and the labs return: 1
Current value of i: 2, and the labs return: 2
Current value of i: 3, and the labs return: 3
Current value of i: 4, and the labs return: 4
Current value of i: 5, and the labs return: 5

My tests didn't work which leads me to beleive that the .c file is being overridden for my system. Used grep -r to search all files to see what file might be overwriting it. Searched through change logs. I couldn't find why that wasn't working, the grep logs returned big list of files. Lots of the files didn't make sense to me.
Tried to change the div.c as Hojung An did in his blog to test that this file at least was working and that the testrun.sh works.

#include 

/* Return the `div_t' representation of NUMER over DENOM.  */
div_t
div (int numer, int denom)
{
  div_t result;
  result.quot = 100 / 2;
  result.rem = 100 % 2;
  return result;
}
******Output**************************************************
Current value of i: -5, and the labs return: 50
Current value of i: -4, and the labs return: 50
Current value of i: -3, and the labs return: 50
Current value of i: -2, and the labs return: 50
Current value of i: -1, and the labs return: 50
Current value of i: 0, and the labs return: 50
Current value of i: 1, and the labs return: 50
Current value of i: 2, and the labs return: 50
Current value of i: 3, and the labs return: 50
Current value of i: 4, and the labs return: 50
Current value of i: 5, and the labs return: 50

So this worked first try. It's interesting that llabs.c didn't work, maybe its a depreciated funtion, or it has been overridden. I did notice that in the source file it had an #UNDEF llabs perhaps that had something to do with it. .



Overriding:
From my research, overriding in terms of the Glibc package means that you use different versions of the functions. Depending on the make file and how it is built the library may call a different vesion to use instead of the standard version. In our make file there are LD_PRELOAD declarations. LD_PRELOAD tells the build to replace the serial library functions with the specific files it is suggesting. I believe that is what is happening to my test of the llabs.c file, however I can't find what its being overwritten with. Here's a quick result from a recursive grep on LD_PRELOAD
elf/Makefile: LD_PRELOAD=$(subst $(empty) ,:,$(strip $(preloadtest-preloads:=.so)))
elf/Makefile:vismain-ENV = LD_PRELOAD=$(addprefix $(objpfx),vismod3.so)
elf/Makefile: LD_PRELOAD= \

LD_PRELOAD Resource: https://blog.fpmurphy.com/2012/09/all-about-ld_preload.html



MultiArch:
Stands for Multiple Architectures (I'm assuming, couldn't find confirmation in my search). What this means is that when you run your ./configure command, the code looks at your systems architecture and determines what code is best suited to run on your machine. So if you have an aarch64 install this version, if you have x86_64 version install that version. Its used to pull the best and most optimized code for your system.
Debian MultiArch info https://wiki.debian.org/Multiarch/Implementation