[PATCH V4] gprofng: a new GNU profiler

[Jose E. Marchesi]

> On Thu, 27 Jan 2022, Jose E. Marchesi via Binutils wrote:
>
>> > It looks like you configured build  without --enable-shared.
>> > If yes, this is expected.
>> 
>> Woudn't it be better to skip building gprofng in case no --enable-shared
>> is specified at `configure' time?
>
>  Is it actually necessary to require `--enable-shared' in the first place 
> for the program to work?

I think so.  AFAIK the gprofng collector works as an interposed shared
object.

>  The thing is there is (otherwise) little point in using the option with 
> binutils, given that both libbfd and libopcodes are internal libraries not 
> for general use and neither provides a stable ABI, so every revision would 
> have to be separately installed if any external programs were to use them.
>
>  Therefore having these libraries built as DSOs causes all the drawbacks 
> of dynamic loading while no advantages of same are virtually used, and 
> consequently I believe hardly anyone uses such a configuration.

There is also libctf, which is used by the linker but also intended for
external usage.

RHEL, for example, builds native binutils with --enable-shared, then
excludes both libbfd.so and libopcodes.so from being installed:

%if %{enable_shared}
%{_libdir}/lib*.so
%{_libdir}/libctf*
%exclude %{_libdir}/libbfd.so
%exclude %{_libdir}/libopcodes.so
%endif