Bug 1939638 - gcc-toolset-10-libasan-devel depends on the wrong libasan
Summary: gcc-toolset-10-libasan-devel depends on the wrong libasan
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gcc
Version: 8.3
Hardware: All
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Marek Polacek
QA Contact: Alexandra Petlanová Hájková
Oss Tikhomirova
URL:
Whiteboard:
: 1940505 (view as bug list)
Depends On:
Blocks: 1940505
TreeView+ depends on / blocked
 
Reported: 2021-03-16 17:50 UTC by Jose E. Marchesi
Modified: 2023-07-18 14:19 UTC (History)
8 users (show)

Fixed In Version: gcc-toolset-10-gcc-10.2.1-8.2.el8
Doc Type: Bug Fix
Doc Text:
.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.
Clone Of:
: 1940505 (view as bug list)
Environment:
Last Closed: 2021-05-18 15:43:11 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jose 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!

Comment 1 Marek Polacek 2021-03-16 20:10:54 UTC
(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.

Comment 3 Jose E. Marchesi 2021-03-16 20:35:47 UTC
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!

Comment 4 Marek Polacek 2021-03-16 20:41:54 UTC
(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!

Comment 15 Martin Cermak 2021-04-13 10:06:52 UTC
*** Bug 1940505 has been marked as a duplicate of this bug. ***

Comment 19 errata-xmlrpc 2021-05-18 15:43:11 UTC
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


Note You need to log in before you can comment on or make changes to this bug.