With OpenSSL v3 installed, the libcrypto feature check fails as it use the
deprecated MD5_* API (and is compiled with -Werror). The error message is
as follows.
$ make tools/perf
```
Makefile.config:778: No libcrypto.h found, disables jitted code injection,
please install openssl-devel or libssl-dev
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... libbfd: [ on ]
... libbfd-buildid: [ on ]
... libcap: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libcrypto: [ OFF ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... libzstd: [ on ]
... disassembler-four-args: [ on ]
```
This is very confusing because the suggested library (on my Ubuntu 20.04
it is libssl-dev) is already installed. As the test only checks for the
presence of libcrypto, this commit suppresses the deprecation warning to
allow the test to pass.
Signed-off-by: Zixuan Tan <[email protected]>
---
tools/build/feature/test-libcrypto.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
index a98174e0569c..31afff093d0b 100644
--- a/tools/build/feature/test-libcrypto.c
+++ b/tools/build/feature/test-libcrypto.c
@@ -2,6 +2,12 @@
#include <openssl/sha.h>
#include <openssl/md5.h>
+/*
+ * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
+ * feature test to fail silently. This is a workaround.
+ */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+
int main(void)
{
MD5_CTX context;
--
2.34.1
On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> deprecated MD5_* API (and is compiled with -Werror). The error message is
> as follows.
>
> $ make tools/perf
> ```
> Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> please install openssl-devel or libssl-dev
>
> Auto-detecting system features:
> ... dwarf: [ on ]
> ... dwarf_getlocations: [ on ]
> ... glibc: [ on ]
> ... libbfd: [ on ]
> ... libbfd-buildid: [ on ]
> ... libcap: [ on ]
> ... libelf: [ on ]
> ... libnuma: [ on ]
> ... numa_num_possible_cpus: [ on ]
> ... libperl: [ on ]
> ... libpython: [ on ]
> ... libcrypto: [ OFF ]
> ... libunwind: [ on ]
> ... libdw-dwarf-unwind: [ on ]
> ... zlib: [ on ]
> ... lzma: [ on ]
> ... get_cpuid: [ on ]
> ... bpf: [ on ]
> ... libaio: [ on ]
> ... libzstd: [ on ]
> ... disassembler-four-args: [ on ]
> ```
>
> This is very confusing because the suggested library (on my Ubuntu 20.04
> it is libssl-dev) is already installed. As the test only checks for the
> presence of libcrypto, this commit suppresses the deprecation warning to
> allow the test to pass.
>
> Signed-off-by: Zixuan Tan <[email protected]>
> ---
> tools/build/feature/test-libcrypto.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> index a98174e0569c..31afff093d0b 100644
> --- a/tools/build/feature/test-libcrypto.c
> +++ b/tools/build/feature/test-libcrypto.c
> @@ -2,6 +2,12 @@
> #include <openssl/sha.h>
> #include <openssl/md5.h>
>
> +/*
> + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> + * feature test to fail silently. This is a workaround.
> + */
then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
so I wonder how come the rest of the compilation passed for you.. do you have
CONFIG_JITDUMP disabled?
thanks,
jirka
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +
> int main(void)
> {
> MD5_CTX context;
> --
> 2.34.1
>
Em Sun, Jun 26, 2022 at 04:45:39PM +0200, Jiri Olsa escreveu:
> On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > as follows.
> >
> > $ make tools/perf
> > ```
> > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > please install openssl-devel or libssl-dev
> >
> > Auto-detecting system features:
> > ... dwarf: [ on ]
> > ... dwarf_getlocations: [ on ]
> > ... glibc: [ on ]
> > ... libbfd: [ on ]
> > ... libbfd-buildid: [ on ]
> > ... libcap: [ on ]
> > ... libelf: [ on ]
> > ... libnuma: [ on ]
> > ... numa_num_possible_cpus: [ on ]
> > ... libperl: [ on ]
> > ... libpython: [ on ]
> > ... libcrypto: [ OFF ]
> > ... libunwind: [ on ]
> > ... libdw-dwarf-unwind: [ on ]
> > ... zlib: [ on ]
> > ... lzma: [ on ]
> > ... get_cpuid: [ on ]
> > ... bpf: [ on ]
> > ... libaio: [ on ]
> > ... libzstd: [ on ]
> > ... disassembler-four-args: [ on ]
> > ```
> >
> > This is very confusing because the suggested library (on my Ubuntu 20.04
> > it is libssl-dev) is already installed. As the test only checks for the
> > presence of libcrypto, this commit suppresses the deprecation warning to
> > allow the test to pass.
> >
> > Signed-off-by: Zixuan Tan <[email protected]>
> > ---
> > tools/build/feature/test-libcrypto.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > index a98174e0569c..31afff093d0b 100644
> > --- a/tools/build/feature/test-libcrypto.c
> > +++ b/tools/build/feature/test-libcrypto.c
> > @@ -2,6 +2,12 @@
> > #include <openssl/sha.h>
> > #include <openssl/md5.h>
> >
> > +/*
> > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > + * feature test to fail silently. This is a workaround.
> > + */
>
> then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> so I wonder how come the rest of the compilation passed for you.. do you have
> CONFIG_JITDUMP disabled?
So, here, on fedora 36:
[acme@quaco perf-urgent]$ m
make: Entering directory '/home/acme/git/perf-urgent/tools/perf'
BUILD: Doing 'make -j8' parallel build
HOSTCC /tmp/build/perf-urgent/fixdep.o
HOSTLD /tmp/build/perf-urgent/fixdep-in.o
LINK /tmp/build/perf-urgent/fixdep
Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h'
diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h
Warning: Kernel ABI header at 'tools/arch/x86/include/asm/disabled-features.h' differs from latest version at 'arch/x86/include/asm/disabled-features.h'
diff -u tools/arch/x86/include/asm/disabled-features.h arch/x86/include/asm/disabled-features.h
Warning: Kernel ABI header at 'tools/arch/arm64/include/uapi/asm/perf_regs.h' differs from latest version at 'arch/arm64/include/uapi/asm/perf_regs.h'
diff -u tools/arch/arm64/include/uapi/asm/perf_regs.h arch/arm64/include/uapi/asm/perf_regs.h
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/svm.h' differs from latest version at 'arch/x86/include/uapi/asm/svm.h'
diff -u tools/arch/x86/include/uapi/asm/svm.h arch/x86/include/uapi/asm/svm.h
Warning: Kernel ABI header at 'tools/arch/arm64/include/uapi/asm/kvm.h' differs from latest version at 'arch/arm64/include/uapi/asm/kvm.h'
diff -u tools/arch/arm64/include/uapi/asm/kvm.h arch/arm64/include/uapi/asm/kvm.h
Warning: Kernel ABI header at 'tools/include/linux/coresight-pmu.h' differs from latest version at 'include/linux/coresight-pmu.h'
diff -u tools/include/linux/coresight-pmu.h include/linux/coresight-pmu.h
Makefile.config:778: No libcrypto.h found, disables jitted code injection, please install openssl-devel or libssl-dev
Makefile.config:1108: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... libbfd: [ on ]
... libbfd-buildid: [ on ]
... libcap: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libcrypto: [ OFF ] <-------------------------------------------------------
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... libzstd: [ on ]
... disassembler-four-args: [ on ]
GEN /tmp/build/perf-urgent/common-cmds.h
MKDIR /tmp/build/perf-urgent/fd/
CC /tmp/build/perf-urgent/exec-cmd.o
CC /tmp/build/perf-urgent/fd/array.o
But then:
⬢[acme@toolbox perf-urgent]$ perf -vv
perf version 5.19.rc3.gfbec4d8dd3a7
dwarf: [ on ] # HAVE_DWARF_SUPPORT
dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT
glibc: [ on ] # HAVE_GLIBC_SUPPORT
syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT
libbfd: [ on ] # HAVE_LIBBFD_SUPPORT
debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT
libelf: [ on ] # HAVE_LIBELF_SUPPORT
libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT
numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT
libperl: [ on ] # HAVE_LIBPERL_SUPPORT
libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT
libslang: [ on ] # HAVE_SLANG_SUPPORT
libcrypto: [ OFF ] # HAVE_LIBCRYPTO_SUPPORT
libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT
libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT
zlib: [ on ] # HAVE_ZLIB_SUPPORT
lzma: [ on ] # HAVE_LZMA_SUPPORT
get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT
bpf: [ on ] # HAVE_LIBBPF_SUPPORT
aio: [ on ] # HAVE_AIO_SUPPORT
zstd: [ on ] # HAVE_ZSTD_SUPPORT
libpfm4: [ OFF ] # HAVE_LIBPFM
⬢[acme@toolbox perf-urgent]$
But...:
⬢[acme@toolbox perf-urgent]$ ldd ~/bin/perf | grep ssl
libssl.so.3 => /lib64/libssl.so.3 (0x00007f02dc87e000)
⬢[acme@toolbox perf-urgent]$
- Arnaldo
On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <[email protected]> wrote:
>
> On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > as follows.
> >
> > $ make tools/perf
> > ```
> > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > please install openssl-devel or libssl-dev
> >
> > Auto-detecting system features:
> > ... dwarf: [ on ]
> > ... dwarf_getlocations: [ on ]
> > ... glibc: [ on ]
> > ... libbfd: [ on ]
> > ... libbfd-buildid: [ on ]
> > ... libcap: [ on ]
> > ... libelf: [ on ]
> > ... libnuma: [ on ]
> > ... numa_num_possible_cpus: [ on ]
> > ... libperl: [ on ]
> > ... libpython: [ on ]
> > ... libcrypto: [ OFF ]
> > ... libunwind: [ on ]
> > ... libdw-dwarf-unwind: [ on ]
> > ... zlib: [ on ]
> > ... lzma: [ on ]
> > ... get_cpuid: [ on ]
> > ... bpf: [ on ]
> > ... libaio: [ on ]
> > ... libzstd: [ on ]
> > ... disassembler-four-args: [ on ]
> > ```
> >
> > This is very confusing because the suggested library (on my Ubuntu 20.04
> > it is libssl-dev) is already installed. As the test only checks for the
> > presence of libcrypto, this commit suppresses the deprecation warning to
> > allow the test to pass.
> >
> > Signed-off-by: Zixuan Tan <[email protected]>
> > ---
> > tools/build/feature/test-libcrypto.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > index a98174e0569c..31afff093d0b 100644
> > --- a/tools/build/feature/test-libcrypto.c
> > +++ b/tools/build/feature/test-libcrypto.c
> > @@ -2,6 +2,12 @@
> > #include <openssl/sha.h>
> > #include <openssl/md5.h>
> >
> > +/*
> > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > + * feature test to fail silently. This is a workaround.
> > + */
>
> then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> so I wonder how come the rest of the compilation passed for you.. do you have
> CONFIG_JITDUMP disabled?
>
> thanks,
> jirka
>
No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
Yes, you are right. The rest of the compilation should fail, but it doesn't.
I checked the verbose build commands. This seems to be the result of another
inconsistency.
If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
prefix is checked. This causes urandom always be used to create build id
rather than MD5 and SHA1, no matter what the detection result is.
In perf/Makefile.config, from line 776
```
ifndef NO_LIBCRYPTO
ifneq ($(feature-libcrypto), 1)
msg := $(warning No libcrypto.h found, disables jitted code injection,
please install openssl-devel or libssl-dev);
NO_LIBCRYPTO := 1
else <-- if libcrypto feature detected
CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT <-- define this
EXTLIBS += -lcrypto
$(call detected,CONFIG_CRYPTO)
endif
endif
```
In perf/util/genelf.c, from line 33
```
#ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
#define BUILD_ID_MD5
#undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
#undef BUILD_ID_URANDOM /* different uuid for each run */
#ifdef BUILD_ID_SHA
#include <openssl/sha.h>
#endif
#ifdef BUILD_ID_MD5
#include <openssl/md5.h>
#endif
#endif <-- this block will be skipped
```
Maybe we should fix this, to really make use of libcrypto if it is available?
Links:
This commit include the genelf.c:
https://lore.kernel.org/all/[email protected]/T/#mb6d3e18bee4901b71a4d4ef4f406feaaf48346d9
This commit include the feature test:
https://lore.kernel.org/all/[email protected]/T/#m12a2ababf8ad3e366d56d9efab870592e6ff60a5
Thanks,
Zixuan
> > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > +
> > int main(void)
> > {
> > MD5_CTX context;
> > --
> > 2.34.1
> >
On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <[email protected]> wrote:
> >
> > On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > > as follows.
> > >
> > > $ make tools/perf
> > > ```
> > > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > > please install openssl-devel or libssl-dev
> > >
> > > Auto-detecting system features:
> > > ... dwarf: [ on ]
> > > ... dwarf_getlocations: [ on ]
> > > ... glibc: [ on ]
> > > ... libbfd: [ on ]
> > > ... libbfd-buildid: [ on ]
> > > ... libcap: [ on ]
> > > ... libelf: [ on ]
> > > ... libnuma: [ on ]
> > > ... numa_num_possible_cpus: [ on ]
> > > ... libperl: [ on ]
> > > ... libpython: [ on ]
> > > ... libcrypto: [ OFF ]
> > > ... libunwind: [ on ]
> > > ... libdw-dwarf-unwind: [ on ]
> > > ... zlib: [ on ]
> > > ... lzma: [ on ]
> > > ... get_cpuid: [ on ]
> > > ... bpf: [ on ]
> > > ... libaio: [ on ]
> > > ... libzstd: [ on ]
> > > ... disassembler-four-args: [ on ]
> > > ```
> > >
> > > This is very confusing because the suggested library (on my Ubuntu 20.04
> > > it is libssl-dev) is already installed. As the test only checks for the
> > > presence of libcrypto, this commit suppresses the deprecation warning to
> > > allow the test to pass.
> > >
> > > Signed-off-by: Zixuan Tan <[email protected]>
> > > ---
> > > tools/build/feature/test-libcrypto.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > > index a98174e0569c..31afff093d0b 100644
> > > --- a/tools/build/feature/test-libcrypto.c
> > > +++ b/tools/build/feature/test-libcrypto.c
> > > @@ -2,6 +2,12 @@
> > > #include <openssl/sha.h>
> > > #include <openssl/md5.h>
> > >
> > > +/*
> > > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > > + * feature test to fail silently. This is a workaround.
> > > + */
> >
> > then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> > so I wonder how come the rest of the compilation passed for you.. do you have
> > CONFIG_JITDUMP disabled?
> >
> > thanks,
> > jirka
> >
> No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
>
> Yes, you are right. The rest of the compilation should fail, but it doesn't.
> I checked the verbose build commands. This seems to be the result of another
> inconsistency.
>
> If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
> defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
> prefix is checked. This causes urandom always be used to create build id
> rather than MD5 and SHA1, no matter what the detection result is.
>
> In perf/Makefile.config, from line 776
> ```
> ifndef NO_LIBCRYPTO
> ifneq ($(feature-libcrypto), 1)
> msg := $(warning No libcrypto.h found, disables jitted code injection,
> please install openssl-devel or libssl-dev);
> NO_LIBCRYPTO := 1
> else <-- if libcrypto feature detected
> CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT <-- define this
> EXTLIBS += -lcrypto
> $(call detected,CONFIG_CRYPTO)
> endif
> endif
> ```
>
> In perf/util/genelf.c, from line 33
> ```
> #ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
nice :)
>
> #define BUILD_ID_MD5
> #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> #undef BUILD_ID_URANDOM /* different uuid for each run */
>
> #ifdef BUILD_ID_SHA
> #include <openssl/sha.h>
> #endif
>
> #ifdef BUILD_ID_MD5
> #include <openssl/md5.h>
> #endif
> #endif <-- this block will be skipped
> ```
>
> Maybe we should fix this, to really make use of libcrypto if it is available?
yea, I think that was the original idea, let's keep the variable with
SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
full fix would be to detect the new API and use it when it's available but..
given that the check was false at least since 2016, perhaps we could remove
that code? ;-) Stephane?
jirka
>
> Links:
> This commit include the genelf.c:
> https://lore.kernel.org/all/[email protected]/T/#mb6d3e18bee4901b71a4d4ef4f406feaaf48346d9
> This commit include the feature test:
> https://lore.kernel.org/all/[email protected]/T/#m12a2ababf8ad3e366d56d9efab870592e6ff60a5
>
> Thanks,
> Zixuan
>
> > > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > > +
> > > int main(void)
> > > {
> > > MD5_CTX context;
> > > --
> > > 2.34.1
> > >
On Tue, Jun 28, 2022 at 08:16:06AM +0200, Jiri Olsa wrote:
> On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> > On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <[email protected]> wrote:
> > >
> > > On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > > > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > > > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > > > as follows.
> > > >
> > > > $ make tools/perf
> > > > ```
> > > > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > > > please install openssl-devel or libssl-dev
> > > >
> > > > Auto-detecting system features:
> > > > ... dwarf: [ on ]
> > > > ... dwarf_getlocations: [ on ]
> > > > ... glibc: [ on ]
> > > > ... libbfd: [ on ]
> > > > ... libbfd-buildid: [ on ]
> > > > ... libcap: [ on ]
> > > > ... libelf: [ on ]
> > > > ... libnuma: [ on ]
> > > > ... numa_num_possible_cpus: [ on ]
> > > > ... libperl: [ on ]
> > > > ... libpython: [ on ]
> > > > ... libcrypto: [ OFF ]
> > > > ... libunwind: [ on ]
> > > > ... libdw-dwarf-unwind: [ on ]
> > > > ... zlib: [ on ]
> > > > ... lzma: [ on ]
> > > > ... get_cpuid: [ on ]
> > > > ... bpf: [ on ]
> > > > ... libaio: [ on ]
> > > > ... libzstd: [ on ]
> > > > ... disassembler-four-args: [ on ]
> > > > ```
> > > >
> > > > This is very confusing because the suggested library (on my Ubuntu 20.04
> > > > it is libssl-dev) is already installed. As the test only checks for the
> > > > presence of libcrypto, this commit suppresses the deprecation warning to
> > > > allow the test to pass.
> > > >
> > > > Signed-off-by: Zixuan Tan <[email protected]>
> > > > ---
> > > > tools/build/feature/test-libcrypto.c | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > > > index a98174e0569c..31afff093d0b 100644
> > > > --- a/tools/build/feature/test-libcrypto.c
> > > > +++ b/tools/build/feature/test-libcrypto.c
> > > > @@ -2,6 +2,12 @@
> > > > #include <openssl/sha.h>
> > > > #include <openssl/md5.h>
> > > >
> > > > +/*
> > > > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > > > + * feature test to fail silently. This is a workaround.
> > > > + */
> > >
> > > then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> > > so I wonder how come the rest of the compilation passed for you.. do you have
> > > CONFIG_JITDUMP disabled?
> > >
> > > thanks,
> > > jirka
> > >
> > No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
> >
> > Yes, you are right. The rest of the compilation should fail, but it doesn't.
> > I checked the verbose build commands. This seems to be the result of another
> > inconsistency.
> >
> > If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
> > defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
> > prefix is checked. This causes urandom always be used to create build id
> > rather than MD5 and SHA1, no matter what the detection result is.
> >
> > In perf/Makefile.config, from line 776
> > ```
> > ifndef NO_LIBCRYPTO
> > ifneq ($(feature-libcrypto), 1)
> > msg := $(warning No libcrypto.h found, disables jitted code injection,
> > please install openssl-devel or libssl-dev);
> > NO_LIBCRYPTO := 1
> > else <-- if libcrypto feature detected
> > CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT <-- define this
> > EXTLIBS += -lcrypto
> > $(call detected,CONFIG_CRYPTO)
> > endif
> > endif
> > ```
> >
> > In perf/util/genelf.c, from line 33
> > ```
> > #ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
>
> nice :)
>
> >
> > #define BUILD_ID_MD5
> > #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> > #undef BUILD_ID_URANDOM /* different uuid for each run */
> >
> > #ifdef BUILD_ID_SHA
> > #include <openssl/sha.h>
> > #endif
> >
> > #ifdef BUILD_ID_MD5
> > #include <openssl/md5.h>
> > #endif
> > #endif <-- this block will be skipped
> > ```
> >
> > Maybe we should fix this, to really make use of libcrypto if it is available?
>
> yea, I think that was the original idea, let's keep the variable with
> SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
>
> full fix would be to detect the new API and use it when it's available but..
> given that the check was false at least since 2016, perhaps we could remove
> that code? ;-) Stephane?
ping
jirka
Em Tue, Aug 02, 2022 at 03:09:05PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Aug 01, 2022 at 03:24:18PM +0200, Jiri Olsa escreveu:
> > On Tue, Jun 28, 2022 at 08:16:06AM +0200, Jiri Olsa wrote:
> > > On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> > > > On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <[email protected]> wrote:
> > > > >
> > > > > On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > > > > > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > > > > > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > > > > > as follows.
> > > > > >
> > > > > > $ make tools/perf
> > > > > > ```
> > > > > > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > > > > > please install openssl-devel or libssl-dev
> > > > > >
> > > > > > Auto-detecting system features:
> > > > > > ... dwarf: [ on ]
> > > > > > ... dwarf_getlocations: [ on ]
> > > > > > ... glibc: [ on ]
> > > > > > ... libbfd: [ on ]
> > > > > > ... libbfd-buildid: [ on ]
> > > > > > ... libcap: [ on ]
> > > > > > ... libelf: [ on ]
> > > > > > ... libnuma: [ on ]
> > > > > > ... numa_num_possible_cpus: [ on ]
> > > > > > ... libperl: [ on ]
> > > > > > ... libpython: [ on ]
> > > > > > ... libcrypto: [ OFF ]
> > > > > > ... libunwind: [ on ]
> > > > > > ... libdw-dwarf-unwind: [ on ]
> > > > > > ... zlib: [ on ]
> > > > > > ... lzma: [ on ]
> > > > > > ... get_cpuid: [ on ]
> > > > > > ... bpf: [ on ]
> > > > > > ... libaio: [ on ]
> > > > > > ... libzstd: [ on ]
> > > > > > ... disassembler-four-args: [ on ]
> > > > > > ```
> > > > > >
> > > > > > This is very confusing because the suggested library (on my Ubuntu 20.04
> > > > > > it is libssl-dev) is already installed. As the test only checks for the
> > > > > > presence of libcrypto, this commit suppresses the deprecation warning to
> > > > > > allow the test to pass.
> > > > > >
> > > > > > Signed-off-by: Zixuan Tan <[email protected]>
> > > > > > ---
> > > > > > tools/build/feature/test-libcrypto.c | 6 ++++++
> > > > > > 1 file changed, 6 insertions(+)
> > > > > >
> > > > > > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > > > > > index a98174e0569c..31afff093d0b 100644
> > > > > > --- a/tools/build/feature/test-libcrypto.c
> > > > > > +++ b/tools/build/feature/test-libcrypto.c
> > > > > > @@ -2,6 +2,12 @@
> > > > > > #include <openssl/sha.h>
> > > > > > #include <openssl/md5.h>
> > > > > >
> > > > > > +/*
> > > > > > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > > > > > + * feature test to fail silently. This is a workaround.
> > > > > > + */
> > > > >
> > > > > then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> > > > > so I wonder how come the rest of the compilation passed for you.. do you have
> > > > > CONFIG_JITDUMP disabled?
> > > > >
> > > > No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
> > > >
> > > > Yes, you are right. The rest of the compilation should fail, but it doesn't.
> > > > I checked the verbose build commands. This seems to be the result of another
> > > > inconsistency.
> > > >
> > > > If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
> > > > defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
> > > > prefix is checked. This causes urandom always be used to create build id
> > > > rather than MD5 and SHA1, no matter what the detection result is.
> > > >
> > > > In perf/Makefile.config, from line 776
> > > > ```
> > > > ifndef NO_LIBCRYPTO
> > > > ifneq ($(feature-libcrypto), 1)
> > > > msg := $(warning No libcrypto.h found, disables jitted code injection,
> > > > please install openssl-devel or libssl-dev);
> > > > NO_LIBCRYPTO := 1
> > > > else <-- if libcrypto feature detected
> > > > CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT <-- define this
> > > > EXTLIBS += -lcrypto
> > > > $(call detected,CONFIG_CRYPTO)
> > > > endif
> > > > endif
> > > > ```
> > > >
> > > > In perf/util/genelf.c, from line 33
> > > > ```
> > > > #ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
> > >
> > > nice :)
> > >
> > > >
> > > > #define BUILD_ID_MD5
> > > > #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> > > > #undef BUILD_ID_URANDOM /* different uuid for each run */
> > > >
> > > > #ifdef BUILD_ID_SHA
> > > > #include <openssl/sha.h>
> > > > #endif
> > > >
> > > > #ifdef BUILD_ID_MD5
> > > > #include <openssl/md5.h>
> > > > #endif
> > > > #endif <-- this block will be skipped
> > > > ```
> > > >
> > > > Maybe we should fix this, to really make use of libcrypto if it is available?
> > >
> > > yea, I think that was the original idea, let's keep the variable with
> > > SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
> > >
> > > full fix would be to detect the new API and use it when it's available but..
> > > given that the check was false at least since 2016, perhaps we could remove
> > > that code? ;-) Stephane?
> >
> > ping
>
> So, we should start with 谭梓煊 patch, then fix that ifdef and go on
> from there?
I.e. with this:
diff --git a/tools/perf/util/genelf.c b/tools/perf/util/genelf.c
index aed49806a09bab8f..953338b9e887e26f 100644
--- a/tools/perf/util/genelf.c
+++ b/tools/perf/util/genelf.c
@@ -30,7 +30,11 @@
#define BUILD_ID_URANDOM /* different uuid for each run */
-#ifdef HAVE_LIBCRYPTO
+// FIXME, remove this and fix the deprecation warnings before its removed and
+// We'll break for good here...
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+
+#ifdef HAVE_LIBCRYPTO_SUPPORT
#define BUILD_ID_MD5
#undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
Em Mon, Aug 01, 2022 at 03:24:18PM +0200, Jiri Olsa escreveu:
> On Tue, Jun 28, 2022 at 08:16:06AM +0200, Jiri Olsa wrote:
> > On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> > > On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <[email protected]> wrote:
> > > >
> > > > On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > > > > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > > > > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > > > > as follows.
> > > > >
> > > > > $ make tools/perf
> > > > > ```
> > > > > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > > > > please install openssl-devel or libssl-dev
> > > > >
> > > > > Auto-detecting system features:
> > > > > ... dwarf: [ on ]
> > > > > ... dwarf_getlocations: [ on ]
> > > > > ... glibc: [ on ]
> > > > > ... libbfd: [ on ]
> > > > > ... libbfd-buildid: [ on ]
> > > > > ... libcap: [ on ]
> > > > > ... libelf: [ on ]
> > > > > ... libnuma: [ on ]
> > > > > ... numa_num_possible_cpus: [ on ]
> > > > > ... libperl: [ on ]
> > > > > ... libpython: [ on ]
> > > > > ... libcrypto: [ OFF ]
> > > > > ... libunwind: [ on ]
> > > > > ... libdw-dwarf-unwind: [ on ]
> > > > > ... zlib: [ on ]
> > > > > ... lzma: [ on ]
> > > > > ... get_cpuid: [ on ]
> > > > > ... bpf: [ on ]
> > > > > ... libaio: [ on ]
> > > > > ... libzstd: [ on ]
> > > > > ... disassembler-four-args: [ on ]
> > > > > ```
> > > > >
> > > > > This is very confusing because the suggested library (on my Ubuntu 20.04
> > > > > it is libssl-dev) is already installed. As the test only checks for the
> > > > > presence of libcrypto, this commit suppresses the deprecation warning to
> > > > > allow the test to pass.
> > > > >
> > > > > Signed-off-by: Zixuan Tan <[email protected]>
> > > > > ---
> > > > > tools/build/feature/test-libcrypto.c | 6 ++++++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > > > > index a98174e0569c..31afff093d0b 100644
> > > > > --- a/tools/build/feature/test-libcrypto.c
> > > > > +++ b/tools/build/feature/test-libcrypto.c
> > > > > @@ -2,6 +2,12 @@
> > > > > #include <openssl/sha.h>
> > > > > #include <openssl/md5.h>
> > > > >
> > > > > +/*
> > > > > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > > > > + * feature test to fail silently. This is a workaround.
> > > > > + */
> > > >
> > > > then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> > > > so I wonder how come the rest of the compilation passed for you.. do you have
> > > > CONFIG_JITDUMP disabled?
> > > >
> > > > thanks,
> > > > jirka
> > > >
> > > No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
> > >
> > > Yes, you are right. The rest of the compilation should fail, but it doesn't.
> > > I checked the verbose build commands. This seems to be the result of another
> > > inconsistency.
> > >
> > > If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
> > > defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
> > > prefix is checked. This causes urandom always be used to create build id
> > > rather than MD5 and SHA1, no matter what the detection result is.
> > >
> > > In perf/Makefile.config, from line 776
> > > ```
> > > ifndef NO_LIBCRYPTO
> > > ifneq ($(feature-libcrypto), 1)
> > > msg := $(warning No libcrypto.h found, disables jitted code injection,
> > > please install openssl-devel or libssl-dev);
> > > NO_LIBCRYPTO := 1
> > > else <-- if libcrypto feature detected
> > > CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT <-- define this
> > > EXTLIBS += -lcrypto
> > > $(call detected,CONFIG_CRYPTO)
> > > endif
> > > endif
> > > ```
> > >
> > > In perf/util/genelf.c, from line 33
> > > ```
> > > #ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
> >
> > nice :)
> >
> > >
> > > #define BUILD_ID_MD5
> > > #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> > > #undef BUILD_ID_URANDOM /* different uuid for each run */
> > >
> > > #ifdef BUILD_ID_SHA
> > > #include <openssl/sha.h>
> > > #endif
> > >
> > > #ifdef BUILD_ID_MD5
> > > #include <openssl/md5.h>
> > > #endif
> > > #endif <-- this block will be skipped
> > > ```
> > >
> > > Maybe we should fix this, to really make use of libcrypto if it is available?
> >
> > yea, I think that was the original idea, let's keep the variable with
> > SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
> >
> > full fix would be to detect the new API and use it when it's available but..
> > given that the check was false at least since 2016, perhaps we could remove
> > that code? ;-) Stephane?
>
> ping
So, we should start with 谭梓煊 patch, then fix that ifdef and go on
from there?
- Arnaldo
On Wed, Aug 3, 2022 at 2:13 AM Arnaldo Carvalho de Melo
<[email protected]> wrote:
>
> Em Tue, Aug 02, 2022 at 03:09:05PM -0300, Arnaldo Carvalho de Melo escreveu:
> >
> > So, we should start with 谭梓煊 patch, then fix that ifdef and go on
> > from there?
>
> I.e. with this:
>
>
> diff --git a/tools/perf/util/genelf.c b/tools/perf/util/genelf.c
> index aed49806a09bab8f..953338b9e887e26f 100644
> --- a/tools/perf/util/genelf.c
> +++ b/tools/perf/util/genelf.c
> @@ -30,7 +30,11 @@
>
> #define BUILD_ID_URANDOM /* different uuid for each run */
>
> -#ifdef HAVE_LIBCRYPTO
> +// FIXME, remove this and fix the deprecation warnings before its removed and
> +// We'll break for good here...
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +
> +#ifdef HAVE_LIBCRYPTO_SUPPORT
>
> #define BUILD_ID_MD5
> #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
yea, i think that's ok, thank you
Zixuan
On Tue, Aug 02, 2022 at 03:09:05PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Aug 01, 2022 at 03:24:18PM +0200, Jiri Olsa escreveu:
> > On Tue, Jun 28, 2022 at 08:16:06AM +0200, Jiri Olsa wrote:
> > > On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> > > > On Sun, Jun 26, 2022 at 10:45 PM Jiri Olsa <[email protected]> wrote:
> > > > >
> > > > > On Sat, Jun 25, 2022 at 11:34:38PM +0800, Zixuan Tan wrote:
> > > > > > With OpenSSL v3 installed, the libcrypto feature check fails as it use the
> > > > > > deprecated MD5_* API (and is compiled with -Werror). The error message is
> > > > > > as follows.
> > > > > >
> > > > > > $ make tools/perf
> > > > > > ```
> > > > > > Makefile.config:778: No libcrypto.h found, disables jitted code injection,
> > > > > > please install openssl-devel or libssl-dev
> > > > > >
> > > > > > Auto-detecting system features:
> > > > > > ... dwarf: [ on ]
> > > > > > ... dwarf_getlocations: [ on ]
> > > > > > ... glibc: [ on ]
> > > > > > ... libbfd: [ on ]
> > > > > > ... libbfd-buildid: [ on ]
> > > > > > ... libcap: [ on ]
> > > > > > ... libelf: [ on ]
> > > > > > ... libnuma: [ on ]
> > > > > > ... numa_num_possible_cpus: [ on ]
> > > > > > ... libperl: [ on ]
> > > > > > ... libpython: [ on ]
> > > > > > ... libcrypto: [ OFF ]
> > > > > > ... libunwind: [ on ]
> > > > > > ... libdw-dwarf-unwind: [ on ]
> > > > > > ... zlib: [ on ]
> > > > > > ... lzma: [ on ]
> > > > > > ... get_cpuid: [ on ]
> > > > > > ... bpf: [ on ]
> > > > > > ... libaio: [ on ]
> > > > > > ... libzstd: [ on ]
> > > > > > ... disassembler-four-args: [ on ]
> > > > > > ```
> > > > > >
> > > > > > This is very confusing because the suggested library (on my Ubuntu 20.04
> > > > > > it is libssl-dev) is already installed. As the test only checks for the
> > > > > > presence of libcrypto, this commit suppresses the deprecation warning to
> > > > > > allow the test to pass.
> > > > > >
> > > > > > Signed-off-by: Zixuan Tan <[email protected]>
> > > > > > ---
> > > > > > tools/build/feature/test-libcrypto.c | 6 ++++++
> > > > > > 1 file changed, 6 insertions(+)
> > > > > >
> > > > > > diff --git a/tools/build/feature/test-libcrypto.c b/tools/build/feature/test-libcrypto.c
> > > > > > index a98174e0569c..31afff093d0b 100644
> > > > > > --- a/tools/build/feature/test-libcrypto.c
> > > > > > +++ b/tools/build/feature/test-libcrypto.c
> > > > > > @@ -2,6 +2,12 @@
> > > > > > #include <openssl/sha.h>
> > > > > > #include <openssl/md5.h>
> > > > > >
> > > > > > +/*
> > > > > > + * The MD5_* API have been deprecated since OpenSSL 3.0, which causes the
> > > > > > + * feature test to fail silently. This is a workaround.
> > > > > > + */
> > > > >
> > > > > then we use these deprecated MD5 calls in util/genelf.c if libcrypto is detected,
> > > > > so I wonder how come the rest of the compilation passed for you.. do you have
> > > > > CONFIG_JITDUMP disabled?
> > > > >
> > > > > thanks,
> > > > > jirka
> > > > >
> > > > No, CONFIG_JITDUMP is not disabled. I am using the default configuration.
> > > >
> > > > Yes, you are right. The rest of the compilation should fail, but it doesn't.
> > > > I checked the verbose build commands. This seems to be the result of another
> > > > inconsistency.
> > > >
> > > > If libcrypto is detected, the macro "HAVE_LIBCRYPTO_SUPPORT" will be
> > > > defined, but in perf/util/genelf.c, "HAVE_LIBCRYPTO" without the "_SUPPORT"
> > > > prefix is checked. This causes urandom always be used to create build id
> > > > rather than MD5 and SHA1, no matter what the detection result is.
> > > >
> > > > In perf/Makefile.config, from line 776
> > > > ```
> > > > ifndef NO_LIBCRYPTO
> > > > ifneq ($(feature-libcrypto), 1)
> > > > msg := $(warning No libcrypto.h found, disables jitted code injection,
> > > > please install openssl-devel or libssl-dev);
> > > > NO_LIBCRYPTO := 1
> > > > else <-- if libcrypto feature detected
> > > > CFLAGS += -DHAVE_LIBCRYPTO_SUPPORT <-- define this
> > > > EXTLIBS += -lcrypto
> > > > $(call detected,CONFIG_CRYPTO)
> > > > endif
> > > > endif
> > > > ```
> > > >
> > > > In perf/util/genelf.c, from line 33
> > > > ```
> > > > #ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
> > >
> > > nice :)
> > >
> > > >
> > > > #define BUILD_ID_MD5
> > > > #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> > > > #undef BUILD_ID_URANDOM /* different uuid for each run */
> > > >
> > > > #ifdef BUILD_ID_SHA
> > > > #include <openssl/sha.h>
> > > > #endif
> > > >
> > > > #ifdef BUILD_ID_MD5
> > > > #include <openssl/md5.h>
> > > > #endif
> > > > #endif <-- this block will be skipped
> > > > ```
> > > >
> > > > Maybe we should fix this, to really make use of libcrypto if it is available?
> > >
> > > yea, I think that was the original idea, let's keep the variable with
> > > SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
> > >
> > > full fix would be to detect the new API and use it when it's available but..
> > > given that the check was false at least since 2016, perhaps we could remove
> > > that code? ;-) Stephane?
> >
> > ping
>
> So, we should start with 谭梓煊 patch, then fix that ifdef and go on
> from there?
yes, I thought we could remove that, but there's no reply from
Stephane so let's fix that
jirka
Em Wed, Aug 03, 2022 at 09:32:48AM +0200, Jiri Olsa escreveu:
> On Tue, Aug 02, 2022 at 03:09:05PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 01, 2022 at 03:24:18PM +0200, Jiri Olsa escreveu:
> > > On Tue, Jun 28, 2022 at 08:16:06AM +0200, Jiri Olsa wrote:
> > > > On Mon, Jun 27, 2022 at 11:08:34AM +0800, 谭梓煊 wrote:
> > > > > #ifdef HAVE_LIBCRYPTO <-- but check this, it's always false
> > > > nice :)
> > > > > #define BUILD_ID_MD5
> > > > > #undef BUILD_ID_SHA /* does not seem to work well when linked with Java */
> > > > > #undef BUILD_ID_URANDOM /* different uuid for each run */
> > > > > #ifdef BUILD_ID_SHA
> > > > > #include <openssl/sha.h>
> > > > > #endif
> > > > > #ifdef BUILD_ID_MD5
> > > > > #include <openssl/md5.h>
> > > > > #endif
> > > > > #endif <-- this block will be skipped
> > > > > ```
> > > > > Maybe we should fix this, to really make use of libcrypto if it is available?
> > > > yea, I think that was the original idea, let's keep the variable with
> > > > SUPPORT suffix and use the -Wdeprecated-declarations for genelf.c
> > > >
> > > > full fix would be to detect the new API and use it when it's available but..
> > > > given that the check was false at least since 2016, perhaps we could remove
> > > > that code? ;-) Stephane?
> > >
> > > ping
> >
> > So, we should start with 谭梓煊 patch, then fix that ifdef and go on
> > from there?
>
> yes, I thought we could remove that, but there's no reply from
> Stephane so let's fix that
Yeah, I did it and it seems to build, so lets ship it :-)
- Arnaldo