* Re: [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler
2022-03-15 18:17 ` [TCWG CI] Regression caused by binutils: gprofng: a new GNU profiler Vladimir Mezentsev
@ 2022-03-21 14:41 ` Nick Alcock
0 siblings, 0 replies; 2+ messages in thread
From: Nick Alcock @ 2022-03-21 14:41 UTC (permalink / raw)
To: Vladimir Mezentsev; +Cc: binutils
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)
^ permalink raw reply [flat|nested] 2+ messages in thread