Static dependencies linking

[Blebowski]

Hi,

I was wondering if you would be open to adding configure option to link all needed dependencies statically
(or place them into the install location $PREFIX/share at build time, and they would be linked dynamically at startup).

The thing is if NVC is installed in a shared network environment, mutliple versions might need to be maintained.
At my workplace we have something like (for many SWs):

/tools/opensource/nvc/v1.10/...
/tools/opensource/nvc/v1.11/...

We have the same for commerical EDA tools. For each repository with developed code, there is "sw_list" YML file
that contains list of SW versions used to develop that code. A setup_env script then prepares the PATH variable.
Different repositories might need different version, so that all the developmnent results are reproducible.

With this setup, if the build relies on having all the dependencies installed locally, if the dependencies
get non-backwards compatible update (e.g. due to machine upgrades), the previously built versions
can get broken.

Having "all in one batch" would be simpler to use in such environments.

[nickg]

The biggest issue is probably LLVM for which there is already a configure option --enable-static-llvm. I managed to build a completely static binary using make V=1 LDFLAGS="-static" LIBS="-llzma -lz -lm -lreadline -ltermcap -lbz2" (the extra LIBS are the transitive dependencies of the dynamically linked libraries). I'm not sure this is something I really want to recommend to users though.

[Blebowski]

Why so ? Is it because it is messy ? If so, couldn't that be hidden within the configure script ?

Or due to the size of the binary ? The "normal" build is about 11 MB on my PC, while the --enable-static-llvm and the make command above, has about 58 MB.

Or could there be some performance implications ?

[nickg]

Statically linking libc has all sorts of issues. The main one for NVC is that dlopen cannot resolve symbols in the executable or in libc. I think this means only the --jit elaboration mode will work. It will also cause weird problems with VHPI where the plugin might itself be dynamically linked against libc which will cause a second copy of glibc to be loaded in the process which may be incompatible with the version statically linked against. I don't want to have to debug any of these.

It might be possible to statically link just a subset of the dependencies. E.g. libzstd, TCL, readline etc. in addition to LLVM.

[Blebowski]

I see, thanks for explanation.