Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.GCC Toolset 10: the `libasan6` library has been added to GCC
In GCC Toolset 10, the Address Sanitizer feature did not work in the GCC compiler because the `libasan6` library was missing. With this update, the `libasan6` library has been added, and a program will be compiled and linked correctly when the `-fsanitize=address` feature is used.
DescriptionJose E. Marchesi
2021-03-16 17:50:35 UTC
Hi people! :)
Description of problem:
The gcc-toolset-10-libasan-devel package defined by gcc-toolset-10.spec contains the following requires:
%package -n %{?scl_prefix}libasan-devel
Summary: The Address Sanitizer static library
Requires: libasan%{_isa} >= 8.3.1
Obsoletes: libasan5
i.e. it is supposed to work well with the libasan shared object installed by the bulk gcc 8.3.1. This is to be expected of a devtoolset hacked package. However, this is the linker script installed by gcc-toolset-10-libasan-devel:
echo '/* GNU ld script */
%{oformat}
INPUT ( %{?scl:%{_root_prefix}}%{!?scl:%{_prefix}}/%{_lib}/libasan.so.6 )' > libasan.so
%endif
i.e. the installed libasan.so requires libasan.so.6. However, the bulk libasan 8.3.1 package installs libasan.so.5 instead.
Version-Release number of selected component (if applicable):
gcc-toolset-10-gcc 10.2.1-2
How reproducible:
Always.
Steps to Reproduce:
1. Install gcc-toolset-10-gcc
2. scl enable gcc-toolset-10 bash
3. echo 'int main () { return 0; }' | gcc -xc -fsanitize=address -
Actual results:
/opt/rh/gcc-toolset-10/root/usr/bin/ld: cannot find /usr/lib64/libasan.so.6
Expected results:
The link phase succeeds.
Additional info:
gcc-toolset-10.spec also generates a libasan6 package. It seems to me that gcc-toolset-10 should specify a require for it, something like:
%package -n %{?scl_prefix}libasan-devel
Summary: The Address Sanitizer static library
+%if 0%{!?scl:1}
+Requires: libasan6%{_isa} = %{version}-%{release}
+%else
Requires: libasan%{_isa} >= 8.3.1
Obsoletes: libasan5
+%endif
devtoolset-10-gcc has a similar problem. I am not 100% sure of the difference between devtoolset-10-gcc and gcc-toolset-10 though.
TIA!
(In reply to Jose E. Marchesi from comment #0)
> Hi people! :)
>
> Description of problem:
>
> The gcc-toolset-10-libasan-devel package defined by gcc-toolset-10.spec
> contains the following requires:
>
> %package -n %{?scl_prefix}libasan-devel
> Summary: The Address Sanitizer static library
> Requires: libasan%{_isa} >= 8.3.1
> Obsoletes: libasan5
>
> i.e. it is supposed to work well with the libasan shared object installed by
> the bulk gcc 8.3.1. This is to be expected of a devtoolset hacked package.
> However, this is the linker script installed by gcc-toolset-10-libasan-devel:
>
> echo '/* GNU ld script */
> %{oformat}
> INPUT ( %{?scl:%{_root_prefix}}%{!?scl:%{_prefix}}/%{_lib}/libasan.so.6 )'
> > libasan.so
> %endif
>
> i.e. the installed libasan.so requires libasan.so.6. However, the bulk
> libasan 8.3.1 package installs libasan.so.5 instead.
>
>
> Version-Release number of selected component (if applicable):
>
> gcc-toolset-10-gcc 10.2.1-2
>
> How reproducible:
>
> Always.
>
> Steps to Reproduce:
> 1. Install gcc-toolset-10-gcc
> 2. scl enable gcc-toolset-10 bash
> 3. echo 'int main () { return 0; }' | gcc -xc -fsanitize=address -
>
> Actual results:
>
> /opt/rh/gcc-toolset-10/root/usr/bin/ld: cannot find /usr/lib64/libasan.so.6
Reproduced, sorry about that!
> Expected results:
>
> The link phase succeeds.
>
>
> Additional info:
>
> gcc-toolset-10.spec also generates a libasan6 package. It seems to me that
> gcc-toolset-10 should specify a require for it, something like:
>
> %package -n %{?scl_prefix}libasan-devel
> Summary: The Address Sanitizer static library
> +%if 0%{!?scl:1}
> +Requires: libasan6%{_isa} = %{version}-%{release}
> +%else
> Requires: libasan%{_isa} >= 8.3.1
> Obsoletes: libasan5
> +%endif
>
>
> devtoolset-10-gcc has a similar problem. I am not 100% sure of the
> difference between devtoolset-10-gcc and gcc-toolset-10 though.
devtoolset-10-gcc is actually fine, it properly requires libasan6. The difference is that DTS = RHEL 7, GTS = RHEL8.
This will be fixed in the next build/release.
Hi Marek.
Thanks for looking at this! :)
Regarding devtoolset-10-gcc, I was confused by the %else block in the .spec file:
%package -n %{?scl_prefix}libasan-devel
Summary: The Address Sanitizer static library
%if 0%{?rhel} > 7
Requires: libasan%{_isa} >= 8.3.1
Obsoletes: libasan5
%else
Requires: libasan6%{_isa} >= 8.3.1
%endif
But if devtoolset-10-gcc is never to be used in RHEL8 then I guess it is no problem.
Salud!
(In reply to Jose E. Marchesi from comment #3)
> Hi Marek.
>
> Thanks for looking at this! :)
>
> Regarding devtoolset-10-gcc, I was confused by the %else block in the .spec
> file:
>
> %package -n %{?scl_prefix}libasan-devel
> Summary: The Address Sanitizer static library
> %if 0%{?rhel} > 7
> Requires: libasan%{_isa} >= 8.3.1
> Obsoletes: libasan5
> %else
> Requires: libasan6%{_isa} >= 8.3.1
> %endif
>
> But if devtoolset-10-gcc is never to be used in RHEL8 then I guess it is no
> problem.
Correct.
Thanks for opening the bug!
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (gcc-toolset-10-gcc bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:1823
Hi people! :) Description of problem: The gcc-toolset-10-libasan-devel package defined by gcc-toolset-10.spec contains the following requires: %package -n %{?scl_prefix}libasan-devel Summary: The Address Sanitizer static library Requires: libasan%{_isa} >= 8.3.1 Obsoletes: libasan5 i.e. it is supposed to work well with the libasan shared object installed by the bulk gcc 8.3.1. This is to be expected of a devtoolset hacked package. However, this is the linker script installed by gcc-toolset-10-libasan-devel: echo '/* GNU ld script */ %{oformat} INPUT ( %{?scl:%{_root_prefix}}%{!?scl:%{_prefix}}/%{_lib}/libasan.so.6 )' > libasan.so %endif i.e. the installed libasan.so requires libasan.so.6. However, the bulk libasan 8.3.1 package installs libasan.so.5 instead. Version-Release number of selected component (if applicable): gcc-toolset-10-gcc 10.2.1-2 How reproducible: Always. Steps to Reproduce: 1. Install gcc-toolset-10-gcc 2. scl enable gcc-toolset-10 bash 3. echo 'int main () { return 0; }' | gcc -xc -fsanitize=address - Actual results: /opt/rh/gcc-toolset-10/root/usr/bin/ld: cannot find /usr/lib64/libasan.so.6 Expected results: The link phase succeeds. Additional info: gcc-toolset-10.spec also generates a libasan6 package. It seems to me that gcc-toolset-10 should specify a require for it, something like: %package -n %{?scl_prefix}libasan-devel Summary: The Address Sanitizer static library +%if 0%{!?scl:1} +Requires: libasan6%{_isa} = %{version}-%{release} +%else Requires: libasan%{_isa} >= 8.3.1 Obsoletes: libasan5 +%endif devtoolset-10-gcc has a similar problem. I am not 100% sure of the difference between devtoolset-10-gcc and gcc-toolset-10 though. TIA!