Fix broken nssfix build on newer glibc (take 2)

[JonathonReinhart]

This takes a different approach than #255 by simply linking against the libnss_*.so.2 SONAME explicitly, rather than the normal method of passing -lnss_*. This works because the .so.2 stubs still exist on GLIBC >=2.34.

Fixes #245 (take 2)

[JonathonReinhart]

Regarding this failure:
https://github.com/JonathonReinhart/staticx/actions/runs/5774679773/job/15651888713?pr=259

--------------------------------------------------------------------------------
Verify StaticX can't link against target system libs

App run normally:
dlopen("libcrypt.so") returned 0x563d4dc492d0
OK

Making staticx executable ($STATICX_FLAGS=):

Running staticx executable
dlopen("libcrypt.so") returned (nil)
OK

Running original app under centos:5
./app: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./app)
Error: Process completed with exit code 1.

This has nothing to do with libnssfix.

The problem is a logical error with the test here:

staticx/test/no-default-lib/run_test.sh

Line 35 in e853e3d

scuba --image $TEST_DOCKER_IMAGE $app $libname 0

We're building a dynamic app on Ubuntu 22.04 and wondering why it fails to run on CentOS 5. We were getting (un)lucky before with GLIBC versions.

The test is attempting to show that -nodeflib works: that the original app is able to dlopen() a file from the filesystem, but is unable to do so after statcx-ifying. The offending line is there to prove that the given libname exists in the docker image and can be dlopen()ed regularly. That gives more credibility to the subsequent negative test.

I guess ideally we would do the first part with an app already on the system or by building inside of docker, but that seems like too much work.