[PATCH V4] gprofng: a new GNU profiler

[Maciej W. Rozycki]

On Wed, 2 Feb 2022, Vladimir Mezentsev wrote:

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

 Forcing `--enable-shared' in gprofng/ unconditionally could be confusing 
to the user who might want to avoid shared libraries for a reason.

 I think perhaps the best solution would be using AC_ENABLE_SHARED in 
gprofng/ or the equivalent LT_INIT option (I think it's the default 
anyway) and bail out with a suitable message such as:

"Building in gprofng is unsupported with shared libraries disabled.
Please reconfigure with `--enable-shared=gprofng' or `--disable-gprofng'."

or suchlike.

 Then in libopcodes/ you probably want the `pic-only' option to LT_INIT 
(or use `--with-pic') unless `--enable-shared' has been also used for the 
library, though I think it would best be conditionalised on gprofng having 
been enabled if possible as there's a performance hit from using PIC code.  
As there's a `--without-pic' option too the user can give this all may 
have to be coordinated at the top level rather than within gprofng/.

 Perhaps the way how `extra_host_libiberty_configure_flags' are handled 
could serve as an example (though I think it should also use `--with-pic' 
rather than `--enable-shared' unless `--enable-shared' has been explicitly 
given already).

 I realise what I have outlined is not a complete solution, but I hope it 
can help regardless.

  Maciej