Question: I want to make a makefile that installs a library in the host default multi-arch folder, like `/usr/lib/x86_64-linux-gnu` and `/usr/lib/i386-linux-gnu/` and `/usr/lib/arm-linux-gnueabihf`.

But without using `dpkg-architecture` and `debhelper` as they are not always present on the host device.

Only using `gcc` and `make`.

I already found the `/etc/ld.so.conf.d` folder. I could parse the \*.conf files from there, but is this a correct approach? The multi-arch folder will always be there?

Another method I though is parsing the content of `ldconfig -v | grep /usr/lib/` and getting the first result (removing the collon).

Is there an easier way to do this?

Answer: 
Setup your own [debian repository proxy](https://www.howtoforge.com/debian-packages-proxy-with-apt-cacher) within your intranet.

[Customize the ubuntu installation](https://help.ubuntu.com/community/InstallCDCustomization) so that your debian repository proxy is the only entry in `/etc/apt/sources.list`.

Et voila: you have full control about the software installed on your clients (as long as no user has super user permissions).

---

> 
> Update : Added this after the first answer. These users are support, novice users of systems and developers of the bank software... so some of them need sudo privileges. Is there a ready way to monitor them so that any exceptions are caught quickly (like adding the sources list) but other actions like installing stuff from known repos goes unreported.
> 
> 
> 

In your custom installation you can modify the `/etc/sudoers` file so that your users are allowed to run `sudo apt update` and `sudo apt install` but no other command starting with `apt`. Of course, you also have to restrict `sudo bash` (or any other shell).
In almost every shop I've seen so far, developers had full access to development machines, but these machines only had access to the Internet and to the source code repository.

Source code is checked in and compiled on trusted machines (which the developers usually don't have or need administrative permissions on), and then from there deployed to test systems that have access to the internal network.

Whether these machines are used by the developers or a separate test team is up to your organization -- but generally the boundary between trusted and untrusted machines is between separate machines, with the interface between them verifiable (such as source code commits).

Front desk employees get no administrative privileges, ever. When we deployed Solitaire to all of these machines, complaints about this policy pretty much ceased.