Hi,

On Thu, 16 Aug 2018, Martin Liška wrote:

> SHLIB_SOVERSION = 1
> SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
> 
> which would require a substitution for soversion, show I generalize even 
> so much?

I wouldn't bother.  libgcov.so.1 sounds just fine, and due to symbol 
versioning we never need to change the SO version anymore (like with 
libgcc_s).

> About the location of libgcov.{a,so}, I believe right place would be now:
> 
> /home/marxin/bin/gcc/lib64/libgcov.so.1
> /home/marxin/bin/gcc/lib64/libgcov.so
> /home/marxin/bin/gcc/lib64/libgcov.a

No.  With version dependend dirs the .so symlink and the .a file have to 
be placed into the version dependend dirs.  Look at where libgcc_s.so and 
libgcc.a are placed on your system.

> Because of LD_LIBRARY_PATH location I believe libgcov.so should not be in:
> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so

LD_LIBRARY_PATH doesn't affect the .so symlink (which is used for link 
editing), but where the full SONAME library (i.e. libgcov.so.1) is found.  
_That_ one should indeed be placed into a normal system directory like 
/usr/lib, again look at the distribution of files from your system.

> One another question has popped up:
> 
> libgcov.a archive consists of many one-function-per-object-file objects,
> this is guarded with e.g. #ifdef L_gcov_reset macro. For shared library I need
> something like:
> +#if defined(L_gcov_reset) || defined(L_gcov_shared)
> 
> question is whether it worth separating the functions into separate objects? 
> I know
> during linking linker can strip the unused ones. But still.

No, that wouldn't make sense because the shared library needs to contain 
all the functions that are potentially callable (i.e. all of them).  There 
are no unused ones.


Ciao,
Michael.

Reply via email to