Bug 1338695

Summary: static and dynamic libgfortran are inconsistent
Product: Red Hat Developer Toolset Reporter: Dave Love <dave.love>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Martin Cermak <mcermak>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: DTS 4.0 RHEL 6CC: law, mcermak, mnewsome, mpolacek, ohudlick
Target Milestone: alpha   
Target Release: 5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-24 17:53:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dave Love 2016-05-23 09:40:36 UTC
Description of problem:

The toolset ships its own libgfortran.a, but its libgfortran.so just invokes the system version.  The dynamic and static versions actually produce different results, with the dynamic one contrary to the documentation.  I guess it affects other things, but I saw problems with the system_clock intrinsic affecting benchmark timing.

The static library has a weak reference to clock_gettime, unlike the dynamic one, and will use it instead of the lower resolution, non-monotonic, gettimeofday if librt is linked.  (See info (gfortran)SYSTEM_CLOCK, though I haven't checked the code and don't understand why librt isn't always linked.)

Version-Release number of selected component (if applicable):
devtoolset-4-gcc-gfortran-5.3.1-6.1.el6.x86_64

How reproducible:


Steps to Reproduce:

$ cat x.f90
integer (8) ticks, rate
call system_clock (ticks, rate)
print *, rate
end
$ scl enable devtoolset-4 'which gfortran'
/opt/rh/devtoolset-4/root/usr/bin/gfortran
$ scl enable devtoolset-4 'gfortran x.f90 -lrt && ./a.out'
                 1000
$ scl enable devtoolset-4 'gfortran x.f90 -lrt -static-libgfortran && ./a.out'
           1000000000
$ 

With Fedora 23's gfortran 5.3, the dynamic library gives the same result as the static one above.

Comment 1 Jakub Jelinek 2016-05-24 17:53:00 UTC
This is by design in DTS.  We are not shipping multiple different libgfortran.so.3 libraries, similarly not multiple different libstdc++.so.6 libraries etc.
Thus, for symbols that are already available in the system shared library, you get what the system GCC provides, while for symbols not available from the system shared library you get the new ones linked into the binary or shared library as hidden symbols.