Installs static libs instead of shared libs, for example lib/libncbi-vdb.a.2.11.0

[yurivict]

Version 2.11.0 installs static libs instead of shared libs:

lib/libkdf5-static.a
lib/libkdf5.a
lib/libkdf5.a.2 
lib/libkdf5.a.2.11.0
lib/libkdf5.so
lib/libkdf5.so.2
lib/libkdf5.so.2.11.0
lib/libncbi-ngs-c++-static.a
lib/libncbi-ngs-c++.a
lib/libncbi-ngs-c++.a.2
lib/libncbi-ngs-c++.a.2.11.0
lib/libncbi-ngs-static.a
lib/libncbi-ngs.a
lib/libncbi-ngs.a.2
lib/libncbi-ngs.a.2.11.0
lib/libncbi-vdb-static.a
lib/libncbi-vdb.a
lib/libncbi-vdb.a.2
lib/libncbi-vdb.a.2.11.0
lib/libncbi-vdb.so
lib/libncbi-vdb.so.2
lib/libncbi-vdb.so.2.11.0
lib/libncbi-wvdb-static.a
lib/libncbi-wvdb.a
lib/libncbi-wvdb.a.2
lib/libncbi-wvdb.a.2.11.0
lib/libncbi-wvdb.so
lib/libncbi-wvdb.so.2
lib/libncbi-wvdb.so.2.11.0

This issue is similar to issue https://github.com/ncbi/ngs/issues/33 in the ngs project.

OS: FreeBSD 12.2

[klymenko]

What problems does to cause?

[yurivict]

For example, here

lib/libncbi-wvdb-static.a
lib/libncbi-wvdb.a
lib/libncbi-wvdb.a.2
lib/libncbi-wvdb.a.2.11.0

all libs are static. There is no need to install same static library under different file names. Symbolic links are usually used with shared libraries. There is no need to symlink static libs.

[kwrodarmer]

Hi @yurivict - I would point out that your interpretation of the utility of the static links does not seem to take into account application linking at build time, which in some cases that we use will include a library's version, e.g. gcc -o app -lncbi-wvdb.2.11.0 ...

In our build system, we treat library names and versions separately from the static or shared nature of the package.

So while you say there is no need because you assume the only use of symlinks is for the runtime link editor, we use them during the build. Which begs the question, what problem is it creating for you?

[yurivict]

So while you say there is no need because you assume the only use of symlinks is for the runtime link editor, we use them during the build. Which begs the question, what problem is it creating for you?

It doesn't cause any particular problems so far except it looks broken to anybody used to look at shared library names. For example:

-rwxr-xr-x    1 root  wheel      30440 Feb 24 17:14 libdaemon.so.0.5.0
lrwxr-xr-x    1 root  wheel         18 Feb 24 17:14 libdaemon.so.0 -> libdaemon.so.0.5.0
lrwxr-xr-x    1 root  wheel         18 Feb 24 17:14 libdaemon.so -> libdaemon.so.0.5.0
-rwxr-xr-x    1 root  wheel        933 Feb 24 17:14 libdaemon.la
-rw-r--r--    1 root  wheel      40986 Feb 24 17:14 libdaemon.a
-rwxr-xr-x    1 root  wheel     184416 Feb 24 17:14 libnghttp2.so.14.20.1
lrwxr-xr-x    1 root  wheel         21 Feb 24 17:14 libnghttp2.so.14 -> libnghttp2.so.14.20.1
lrwxr-xr-x    1 root  wheel         21 Feb 24 17:14 libnghttp2.so -> libnghttp2.so.14.20.1
-rw-r--r--    1 root  wheel     309662 Feb 24 17:14 libnghttp2.a
-rwxr-xr-x    1 root  wheel      77344 Feb 24 17:14 libtasn1.so.6.6.0
lrwxr-xr-x    1 root  wheel         17 Feb 24 17:14 libtasn1.so.6 -> libtasn1.so.6.6.0
lrwxr-xr-x    1 root  wheel         17 Feb 24 17:14 libtasn1.so -> libtasn1.so.6.6.0
-rw-r--r--    1 root  wheel     139760 Feb 24 17:14 libtasn1.a

-- symbolic links are used for shared libraries, also in conjunction with shared library SONAMEs.

[kwrodarmer]

symbolic links are used for shared libraries, also in conjunction with shared library SONAMEs

Yes.

It doesn't cause any particular problems so far except it looks broken to anybody used to look at shared library names.

We'll take it into consideration. Thank you for your feedback.