0

Goal

I'm building a portable Linux c++ environment for a course to avoid sudo bureaucracy at our site and have a ready-made solution with VSCode included. I've done this with success for a Python course and a Julia course (see Juliawin), but g++ seems to be a different beast.

Bundling dependencies

I used a technique to download all .deb programs and libraries (like build-essential, liblapack-dev and libblas-dev) along with their dependencies and extracted it into a pseudo root directory, e.g.
enter image description here

Environment wrapper

I then created a bash script emdw-deps to allow a user to activate this environment via source emdw-deps. In this script, I set a bunch of environment variables for our build tools to pick up all the headers and libraries included in this system. Specifically, I set LD_LIBRARY_PATH, LIBRARY_PATH, C_LIBRARY_PATH, CPLUS_LIBRARY_PATH, CMAKE_LIBRARY_PATH, INCLUDE, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, CMAKE_INCLUDE_PATH, CMAKE_PREFIX_PATH, PATH, CC, and CXX.

Cannot link libc_nonshared.a

This allows me access to all my bundled tools from a terminal session. E.g. when I type which g++, I get the portable location:

/home/emdw/Downloads/portable_cpp/linux/usr/bin/g++

This also allows me to get the linker to link to all the bundled libraries, shared libraries, and headers. However, ld keeps throwing a linking error for what seems to be a hardcoded location /usr/lib/x86_64-linux-gnu/libc_nonshared.a. This is the output I get when I compile this hello world example:

$ g++ hello.cpp -o hello
/usr/bin/ld: cannot find /usr/lib/x86_64-linux-gnu/libc_nonshared.a
collect2: error: ld returned 1 exit status

The symptom

If I make a symlink from my bundled libc_nonshared.a to the system path:

sudo ln /home/emdw/Downloads/portable_cpp/linux/usr/lib/x86_64-linux-gnu/libc_nonshared.a /usr/lib/x86_64-linux-gnu/libc_nonshared.a -s

Then I can successfully compile hello.cpp

$ g++ hello.cpp -o hello
$ ./hello
Hello world!

Since I work on a clean Linux Mint VM with no software installed, I can confirm that this is indeed a successful compilation from my portable pipeline with only libc_nonshared.a as a non-portable hardcoded component. This is obviously not a solution, but only a way to point to the real problem.

Question

Are there any environment variables or compiler flags that can allow me to point the build tools to an alternative location for libc_nonshared.a?

Simon Streicher
  • 2,638
  • 1
  • 26
  • 30
  • `g++ hello.cpp -o hello -L/home/emdw/Downloads/portable_cpp/linux/usr/lib/x86_64-linux-gnu` – Ted Lyngmo Jan 24 '22 at 18:03
  • @TedLyngmo That gives the exact same error. (Also, that path is already available to g++ via `CPLUS_LIBRARY_PATH` and/or `LD_LIBRARY_PATH`.) It seems to somehow be hardcoded in `ld`... – Simon Streicher Jan 24 '22 at 19:53
  • Ok, then I don't see how the symlink you placed in `/usr/lib/x86_64-linux-gnu` that points at `/home/emdw/Downloads/portable_cpp/linux/usr/lib/x86_64-linux-gnu/libc_nonshared.a` could have helped. – Ted Lyngmo Jan 24 '22 at 19:56
  • @TedLyngmo Yes, I can't see that either other than `ld` having a hardcoded path to `/usr/lib/x86_64-linux-gnu/libc_nonshared.a` baked into the binary, or some hardcoded search locations for `libc_nonshared.a`, or instructions to ignore any flags or environmental variables for `libc_nonshared.a`. It also seems like `libc_nonshared.a` is always included in any compilation of any c++ (and c) file. It might have something to do with https://stackoverflow.com/questions/66701091 – Simon Streicher Jan 24 '22 at 20:10
  • The whole library seems like a legacy one.(https://stackoverflow.com/a/66701284/7582247). What version of `g++` is it? – Ted Lyngmo Jan 24 '22 at 21:49
  • g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 – Simon Streicher Jan 24 '22 at 21:56
  • Ok, I have g++ (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 - Perhaps that's worth a try? There's also clang++ Ubuntu clang version 11.0.0-2~ubuntu20.04.1. Both are available directly with `apt` – Ted Lyngmo Jan 24 '22 at 21:57
  • 1
    Will give it a shot – Simon Streicher Jan 24 '22 at 22:01
  • g++ 10 doesn't fix the problem, it still tries to access `/usr/lib/x86_64-linux-gnu/libc_nonshared.a` – Simon Streicher Jan 25 '22 at 06:32
  • And if you do `apt list -a libc6-dev` which one is installed? Also what does `dpkg --listfiles libc6-dev | wc -l` show? I get `586` (and `libc_nonshared.a` is one of them) – Ted Lyngmo Jan 25 '22 at 06:43
  • `... 'libc6-dev' is not installed`. This is expected, since everything is portable and build on a clean VM. I collect all the relevant .deb files through [this technique](https://askubuntu.com/a/334163/580182), extracted them into a pseudo root directory, and [building a wrapper over this directory](https://gist.github.com/heetbeet/96d780cc76ae2e1e34eb2425ac1b8b9c). This wrapper can be sourced through a terminal `source path/to/wrapper` to allow access to all the libs/bins/headers. This setup is correct since I can compile really complex projects with it, except for the `libc_nonshared.a` bug. – Simon Streicher Jan 25 '22 at 07:10
  • Hmm, seems like something you could do and maintain simpler with `docker`. Start with the official `ubuntu` image and install the tools you need on top of it and save the result as your portable wrapper – Ted Lyngmo Jan 25 '22 at 08:01

0 Answers0