[PATCH V4] gprofng: a new GNU profiler

[Vladimir Mezentsev]

On 2/2/22 08:30, Jose E. Marchesi via Binutils wrote:
>> 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.

yes.
We use the gprofng library in LD_PRELOAD. This library should be a 
shared library.


I am trying to set  extra_configure_flags='--enable-shared' for gprofng 
build only.
But gprofng depens on libopcodes and this library should build with -fPIC.
I haven't yet found how to solve this build issue.

-Vladimir



>
>>   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
>