Bug 1433946 - Deriving libasan package from Dev Tools/ Software Collection main paradigm
Summary: Deriving libasan package from Dev Tools/ Software Collection main paradigm
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: doc-Release_Notes
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: alpha
: 6.1
Assignee: Lenka Špačková
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-20 12:42 UTC by Dmitry Zhukovski
Modified: 2020-05-14 15:47 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
GCC in Red Hat Developer Toolset 3.x contained the libasan package, which might have conflicted with the system version of libasan. As a consequence, depending on which libasan was present in the system, the -fsanitize=address tool worked only either with the system GCC or with the Red Hat Developer Toolset version of GCC, but not with both at the same time. To prevent the described conflict, in Red Hat Developer Toolset 4.x and later versions, the package was renamed to libasanN, where N is a number. However, if the Red Hat Software Collections repository is enabled, the problem can occur after the system update because the system version of libasan is provided in an earlier version than the Red Hat Developer Toolset 3.x version, which is still available in the repository. To work around this problem, exclude this package while updating: ~]$ yum update --exclude=libasan
Clone Of:
Environment:
Last Closed: 2017-04-26 10:59:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dmitry Zhukovski 2017-03-20 12:42:18 UTC
As per email communication - creating this BZ.
--------------------------------------------------------------------

I(and my customer) find libasan package deriving from Dev Tools/ Software Collection main paradigm - be easily switched between system tools and libs and the ones installed from SCL/devtools.

  This is brand new rhel 7 machine with libasan install:

[root@rhel7-1 ~]# ls -l /lib64/libasan.so*

lrwxrwxrwx. 1 root root     16 Mar 15 16:27 /lib64/libasan.so.0 -> libasan.so.0.0.0

-rwxr-xr-x. 1 root root 174896 Aug 31  2016 /lib64/libasan.so.0.0.0

[root@rhel7-1 ~]# gcc  -fsanitize=address C.C

[root@rhel7-1 ~]# rpm -qa | grep asan

libasan-4.8.5-11.el7.x86_64


  Then we install devtoolset-3-libasan-devel

[root@rhel7-1 ~]# yum install  devtoolset-3-libasan-devel

Loaded plugins: package_upload, product-id, search-disabled-repos, subscription-manager

Resolving Dependencies

--> Running transaction check

---> Package devtoolset-3-libasan-devel.x86_64 0:4.9.2-6.2.el7 will be installed

--> Processing Dependency: libasan >= 4.9.0 for package: devtoolset-3-libasan-devel-4.9.2-6.2.el7.x86_64

--> Running transaction check

---> Package libasan.x86_64 0:4.8.5-11.el7 will be updated

---> Package libasan.x86_64 0:4.9.2-6.2.el7 will be an update

--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================

 Package                              Arch             Version                 Repository                          Size

========================================================================================================================

Installing:

 devtoolset-3-libasan-devel           x86_64           4.9.2-6.2.el7           rhel-server-rhscl-7-rpms           252 k

Updating for dependencies:

 libasan                              x86_64           4.9.2-6.2.el7           rhel-server-rhscl-7-rpms           215 k

Transaction Summary

========================================================================================================================

Install  1 Package

Upgrade             ( 1 Dependent package)

Total download size: 467 k

Is this ok [y/d/N]: y

Downloading packages:

Delta RPMs disabled because /usr/bin/applydeltarpm not installed.

(1/2): libasan-4.9.2-6.2.el7.x86_64.rpm                                                          | 215 kB  00:00:00

(2/2): devtoolset-3-libasan-devel-4.9.2-6.2.el7.x86_64.rpm                                       | 252 kB  00:00:00

------------------------------------------------------------------------------------------------------------------------

Total                                                                                   621 kB/s | 467 kB  00:00:00

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

  Updating   : libasan-4.9.2-6.2.el7.x86_64                                                                         1/3

  Installing : devtoolset-3-libasan-devel-4.9.2-6.2.el7.x86_64                                                      2/3

  Cleanup    : libasan-4.8.5-11.el7.x86_64                                                                          3/3

Uploading Package Profile

  Verifying  : libasan-4.9.2-6.2.el7.x86_64                                                                         1/3

  Verifying  : devtoolset-3-libasan-devel-4.9.2-6.2.el7.x86_64                                                      2/3

  Verifying  : libasan-4.8.5-11.el7.x86_64                                                                          3/3

Installed:

  devtoolset-3-libasan-devel.x86_64 0:4.9.2-6.2.el7

Dependency Updated:

  libasan.x86_64 0:4.9.2-6.2.el7

Complete!


   as package dependency it also updates(replaces) system libasan to newer version.

[root@rhel7-1 ~]# rpm -qa | grep asan

devtoolset-3-libasan-devel-4.9.2-6.2.el7.x86_64

libasan-4.9.2-6.2.el7.x86_64

[root@rhel7-1 ~]# ls -l /lib64/libasan.so*

lrwxrwxrwx. 1 root root     16 Mar 15 16:30 /lib64/libasan.so.1 -> libasan.so.1.0.0

-rwxr-xr-x. 1 root root 682656 Aug 20  2015 /lib64/libasan.so.1.0.0


  So devtool's sanitiser works flawlessly but system one become broken

[root@rhel7-1 ~]# scl enable devtoolset-3 "gcc  -fsanitize=address C.C"

[root@rhel7-1 ~]#

[root@rhel7-1 ~]#

[root@rhel7-1 ~]# gcc  -fsanitize=address C.C

/usr/bin/ld: cannot find /usr/lib64/libasan.so.0.0.0

collect2: error: ld returned 1 exit status

--------------------------------------------------------------------------------

  I spoke with Jakub and his message is "either you have libasan 4.8 and not devtoolset-3-libasan-devel, then system gcc -fsanitize=address works, but not DTS or you have libasan 4.9 and devtoolset-3-libasan-devel installed, then system -fsanitize=address doesn't work, but DTS gcc -fsanitize=address works."

  So - it works against of easy and flexible switch between system tools/libs and SCL ones.

  But if this is true then we need some formal statement on the web/KCS/DevTools docs. If not - then this must be fixed.

  Can you please comment on that ?

br,
dmitry

Comment 4 Matt Newsome 2017-03-20 14:55:51 UTC
Please note that support for Red Hat Developer Toolset 3.x ended with the release of Red Hat Developer Toolset 6.0:

  https://access.redhat.com/support/policy/updates/rhscl

That said, this was a known issue with Red Hat Developer Toolset 3.x libasan, which was addressed in Red Hat Developer Toolset 4.0 and later. The libasan package in Red Hat Developer Toolset was renamed "libasan2", which does not conflict with the equivalent earlier package in Red Hat Enterprise Linux 7.

Comment 5 Dmitry Zhukovski 2017-03-20 17:27:08 UTC
Yes - indeed - DTS 4 and DTS6 do not have that dependencies and works like charm not interfere with system libs/tools.

  However - simple "yum update" with enabled SCL repo breaks everything as it tries to install "broken" libasan-4.9.2-6.2.el7. After that update user can't use system gcc/libs anymore.

  Can we something here ? I guess simple minor-minor update of the package that does ADD it's libs instead of REPLACING.. ?

br,

dmitry

 -----------------------------------------------------------

[root@rhel7-1 ~]# yum update
Loaded plugins: package_upload, product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package libasan.x86_64 0:4.8.5-11.el7 will be updated
---> Package libasan.x86_64 0:4.9.2-6.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================
 Package               Arch Version Repository                              Size
========================================================================================================================
Updating:
 libasan               x86_64 4.9.2-6.2.el7 rhel-server-rhscl-7-rpms               215 k

Transaction Summary
========================================================================================================================
Upgrade  1 Package

Total download size: 215 k
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
libasan-4.9.2-6.2.el7.x86_64.rpm | 215 kB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : libasan-4.9.2-6.2.el7.x86_64 1/2
  Cleanup    : libasan-4.8.5-11.el7.x86_64 2/2
Uploading Package Profile
  Verifying  : libasan-4.9.2-6.2.el7.x86_64 1/2
  Verifying  : libasan-4.8.5-11.el7.x86_64 2/2

Updated:
  libasan.x86_64 0:4.9.2-6.2.el7

Complete!

Comment 6 Marek Polacek 2017-03-21 09:51:09 UTC
Since support for Red Hat Developer Toolset 3.x ended, we can hardly change anything.  As a workaround, I think you can use
# yum update --exclude=libasan

Comment 7 Dmitry Zhukovski 2017-03-21 10:28:28 UTC
I might be wrong but I think it's bad attitude to tell customer - go and fix yourself your scripts/config files to exclude some package that we still ship as part of SCL repository and that does break system's libasan even if they do not install DTS-3.

Matt - what is our conclusion on that ?


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