build: Changes to depends to provide for completely static Gridcoin Linux build

[jamescowens]

This PR represents an effort to build a completely static daemon and GUI version of Gridcoin.

I recently started investigating the depends builds for Linux (i.e. using HOST=x86_64-pc-linux-gnu) and very quickly realized it was completely broken. Because on some machines, the pkg-config/linker would find the system libs and link in, it would give the appearance of working, but an inspection by ldd revealed numerous unwanted dependencies.

To get this to compile correctly with only the libc system library dependencies was a significant effort. Several missing depends packages had to be added, all the depends packages converted to static libs, and then a section in configure.ac implemented to turn off the automatic lib detection and replace with defined lib variables to ensure that the system libraries didn't get picked up instead. Literally hours were spent futzing with the libraries to be included and the library order. Gemini Pro 2.5 was somewhat helpful in its assistance.

Both gridcoinresearchd and gridcoinresearch now work and give the following:

    linux-vdso.so.1 (0x00007ffe1c376000)
    libm.so.6 => /lib64/libm.so.6 (0x00007ff170b16000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff1733f5000)
    libc.so.6 => /lib64/libc.so.6 (0x00007ff170800000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff173451000)

Which are the correct libc dependencies.

This should support #2456 as well as #2766.

[jamescowens]

@div72 I am not sure why MacOS depends boost is not finding libz. Can you take a look?

[div72]

Checking it out.

[div72]

ZLIB_LIBS is not getting properly defined without --with-static-libs, I am more surprised that other depends CI is still working without it.

[jamescowens]

The whole thing is janky actually. I think the original idea is that redirecting towards the local site pkgconfigs would ensure that the proper (static) libs would be picked up, but what has apparently been happening is that the system libs are leaking in rather than a failure to link the proper static library resulting in a failure of the build. This would not be easy to detect without checking ldd, because as long as the build was tested on that machine, it would work.

I will put in a hack conditional to fill out this variable for MacOS.

Maybe we should put an ldd check in the depends builds to make sure that only the libc libraries are linked?

With Windows, this is not a problem because the whole thing has to be built given that the native Windows environment is alien.

[div72]

Maybe we should put an ldd check in the depends builds to make sure that only the libc libraries are linked?

Good idea. Also any specific reason you decided to do this after we decided to retire autotools?

[jamescowens]

I view this as a dry run for what we have to do on the cmake side.

[jamescowens]

I am sure we are going to run into a different set of issues with cmake, but this shows the pressure points.

[CyberTailor]

I am sure we are going to run into a different set of issues with cmake, but this shows the pressure points.

I independently started to backport CMake support in depends from Bitcoin. Now I'm at the point where the daemon builds and links without issues, but there are multiple link failures for GUI.

(I'm cross-compiling only for mingw32 now, no darwin yet.)

[CyberTailor]

So don't rush to support CMake right now. When static builds are fixed, it will be easier for me to finish cross-compile support with CMake.