Re: [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler

Re: [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler

[Vladimir Mezentsev]

On 3/15/22 07:30, ci_notify@linaro.org wrote:
> [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler:
> commit bb368aad297fe3ad40cf397e6fc85aa471429a28
> Author: Vladimir Mezentsev<vladimir.mezentsev@oracle.com>
>
>      gprofng: a new GNU profiler
>
> Results regressed to
> # reset_artifacts:
> -10
> # true:
> 0
> # First few build errors in logs:
> # 00:00:21 configure: error: Cannot set --enable-shared for gprofng/libcollector.
> # 00:00:21 configure: error: /home/tcwg-buildslave/workspace/tcwg_gnu_7/abe/snapshots/binutils.git~master/gprofng/libcollector/configure failed for libcollector
> # 00:00:21 checking for getpagesize... make[1]: *** [Makefile:7723: configure-gprofng] Error 1
> # 00:00:32 make: *** [Makefile:1001: all] Error 2

In gprofng/libcollector, we need to generate the shared libraries:
% cat -n gprofng/libcollector/configure.ac
...
     35    LT_INIT
     36    AC_ENABLE_SHARED
     37    AC_DISABLE_STATIC
     38
     39    if test "$enable_shared" != "yes"; then
     40      AC_MSG_ERROR([Cannot set --enable-shared for 
gprofng/libcollector.])
     41    fi
     42
...


But it is so late to turn off the gprofng build.

Is there an easy way to find out if shared libraries are not supported ?
I want to know this in gprofng/configure.ac


Thank you,
-Vladimir

Re: [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler

[Nick Alcock]

On 15 Mar 2022, Vladimir Mezentsev via Binutils outgrape:

> On 3/15/22 07:30, ci_notify@linaro.org wrote:
>> [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler:
>> commit bb368aad297fe3ad40cf397e6fc85aa471429a28
>> Author: Vladimir Mezentsev<vladimir.mezentsev@oracle.com>
>>
>>      gprofng: a new GNU profiler
>>
>> Results regressed to
>> # reset_artifacts:
>> -10
>> # true:
>> 0
>> # First few build errors in logs:
>> # 00:00:21 configure: error: Cannot set --enable-shared for gprofng/libcollector.
>> # 00:00:21 configure: error: /home/tcwg-buildslave/workspace/tcwg_gnu_7/abe/snapshots/binutils.git~master/gprofng/libcollector/configure failed for libcollector
>> # 00:00:21 checking for getpagesize... make[1]: *** [Makefile:7723: configure-gprofng] Error 1
>> # 00:00:32 make: *** [Makefile:1001: all] Error 2
>
> In gprofng/libcollector, we need to generate the shared libraries:
> % cat -n gprofng/libcollector/configure.ac
> ...
>     35    LT_INIT
>     36    AC_ENABLE_SHARED
>     37    AC_DISABLE_STATIC
>     38
>     39    if test "$enable_shared" != "yes"; then
>     40      AC_MSG_ERROR([Cannot set --enable-shared for gprofng/libcollector.])
>     41    fi
>     42
> ...
>
>
> But it is so late to turn off the gprofng build.
>
> Is there an easy way to find out if shared libraries are not supported ?
> I want to know this in gprofng/configure.ac

Usually one would have the top level configure figure this out, and
suppress configuration of gprofng completely. This is done in the big
host-dependent section around line 932 of the top-level configure.ac.
Alas this requires you to know which of that huge pile of hosts supports
shared libraries and which do not. There's not really a way to test this
at runtime: GNU ld knows it, the top-level configure has to figure out
which projects to configure *long* before ld is built.

Probably all we can do is look through ld, figure out which targets
don't support shared libraries, and avoid building libcollector if one
of those is the host. But, really, given that non-Linux platforms are
not supported by libcollector at all yet, and that for gprofng there
isn't a host/target distinction since it isn't a code generator, it is
probably simpler just to have the top-level configure skip configuration
of gprofng if the host isn't one of the short list we currently
currently support.

(The top level configure is shared with GCC, so there's some extra
annoyance involved in getting this in, I'm afraid.)

-- 
NULL && (void)