This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, libfortran] PR 47571 Fix static linking regression
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 1 Feb 2011 23:37:54 +0200
- Subject: Re: [Patch, libfortran] PR 47571 Fix static linking regression
- References: <AANLkTinb=SiyUezxej5kARB9MxtvA6A0YqZc6JHDBfmk@mail.gmail.com> <4D48820C.3090103@gmail.com>
On Tue, Feb 1, 2011 at 23:58, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 01/02/2011 21:12, Janne Blomqvist wrote:
>
>> my recent patch to use clock_gettime() made static linking break on
>> Linux, Âsince the driver didn't link in librt. It was also pointed out
>> that always requiring librt in libgfortran might in principle reduce
>> performance for non-threaded programs as librt pulls in libpthread and
>> thus the weakrefed IO locking stuff becomes real locks.
>>
>> The attached patch fixes this by not linking in librt (and this
>> libpthread) in libgfortran.so, and instead calls clock_gettime()
>> through a weak reference, falling back to gettimeofday()/other
>> fallbacks in case librt is not explicitly linked in (or implicitly
>> e.g. via -fopenmp). For platforms that provide clock_gettime() in
>> libc, clock_gettime() ought to always be used, although I'm not able
>> to test this.
>>
>> Regtested on x86_64-unknown-linux-gnu, tested a simple program to
>> ensure usage of clock_gettime() or gettimeofday() depending on whether
>> librt is linked. Ok for trunk?
>
> ÂDoes SUPPORTS_WEAK necessarily imply supports weakref? ÂI'm not certain
> they're the same thing.
Well, that macro is used in quadmath_weak.h and in gthr-posix.h in a
similar way, so I guess it's ok.
--
Janne Blomqvist