public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
Date: Mon, 21 Mar 2011 15:05:00 -0000 [thread overview]
Message-ID: <bug-47571-4-dlSy0Z8hkd@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47571-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-21 14:47:20 UTC ---
> --- Comment #38 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-15 17:04:41 UTC ---
> Created attachment 23669
> --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23669
> Updated patch
>
> This patch takes into account the comments by Jakub, and unconditionally sets
> GF_CLOCK_MONOTONIC if clock_gettime is available; this should fix a bug if
> CLOCK_* are not preprocessor macros.
This patch doesn't work:
SUPPORTS_WEAK is 1, GTHREAD_USE_WEAK is 1 since acinclude.m4
(LIBGFOR_GTHREAD_WEAK) doesn't set it to 0, and HAVE_CLOCK_GETTIME_LIBRT
is 1, too, so we still have an undefined reference to clock_gettime ;-(
Could we please avoid this mess with SUPPORTS_WEAK and GTHREAD_USE_WEAK
and make configure define SUPPORTS_WEAKREF or something like this, since
this is what we are actually looking for?
If we include alpha*-dec-osf* in the list of targets that don't support
weakrefs, things should start working again, but I'd prefer a patch where
you can actually read *and understand* what's going on here.
Apart from that, has anyone actually *measured* the overhead of simply
linking libgfortran with librt on Linux, rather than claiming that there
might be some? It the overhead were acceptable or even neglegible, we
could avoid all this mess in the first place, link with -lrt if need be,
and be done with it.
Additionally, the usage model for the weakref seems questionable to
me: while the technique is well-known and common on ELF targets to
produce code that can work with or without libpthread linked into the
application (which is what users will actually do!), which user is
supposed to link his Fortran code with librt to get improved system
clock resolution? I dare say that close to nobody will even think about
this.
Rainer
next prev parent reply other threads:[~2011-03-21 14:48 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 14:24 [Bug fortran/47571] New: " michael.a.richmond at nasa dot gov
2011-02-01 14:56 ` [Bug fortran/47571] [4.6 Regression] " burnus at gcc dot gnu.org
2011-02-01 15:08 ` jb at gcc dot gnu.org
2011-02-01 15:14 ` jakub at gcc dot gnu.org
2011-02-01 15:27 ` michael.a.richmond at nasa dot gov
2011-02-01 15:30 ` burnus at gcc dot gnu.org
2011-02-01 15:51 ` jb at gcc dot gnu.org
2011-02-01 16:03 ` jb at gcc dot gnu.org
2011-02-01 16:08 ` burnus at gcc dot gnu.org
2011-02-01 16:13 ` jakub at gcc dot gnu.org
2011-02-01 16:19 ` michael.a.richmond at nasa dot gov
2011-02-01 16:20 ` jb at gcc dot gnu.org
2011-02-01 16:27 ` burnus at gcc dot gnu.org
2011-02-01 21:18 ` jb at gcc dot gnu.org
2011-02-01 21:28 ` jb at gcc dot gnu.org
2011-02-02 8:48 ` jb at gcc dot gnu.org
2011-02-03 0:44 ` danglin at gcc dot gnu.org
2011-02-03 7:38 ` burnus at gcc dot gnu.org
2011-02-03 9:54 ` jb at gcc dot gnu.org
2011-02-03 12:48 ` jb at gcc dot gnu.org
2011-02-03 15:33 ` dave at hiauly1 dot hia.nrc.ca
2011-02-04 14:42 ` dave at hiauly1 dot hia.nrc.ca
2011-02-05 16:22 ` jb at gcc dot gnu.org
2011-02-07 18:40 ` jb at gcc dot gnu.org
2011-03-07 14:54 ` ro at gcc dot gnu.org
2011-03-07 14:56 ` jakub at gcc dot gnu.org
2011-03-07 16:08 ` burnus at gcc dot gnu.org
2011-03-07 16:20 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-03-07 18:00 ` dave at hiauly1 dot hia.nrc.ca
2011-03-08 9:35 ` burnus at gcc dot gnu.org
2011-03-08 22:39 ` jb at gcc dot gnu.org
2011-03-09 0:10 ` dave at hiauly1 dot hia.nrc.ca
2011-03-11 16:45 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-03-14 11:34 ` jb at gcc dot gnu.org
2011-03-14 11:42 ` jakub at gcc dot gnu.org
2011-03-14 11:43 ` jb at gcc dot gnu.org
2011-03-14 11:50 ` jb at gcc dot gnu.org
2011-03-14 12:08 ` jakub at gcc dot gnu.org
2011-03-15 16:24 ` [Bug fortran/47571] [4.6/4.7 " ro at CeBiTec dot Uni-Bielefeld.DE
2011-03-15 17:05 ` jb at gcc dot gnu.org
2011-03-15 17:16 ` jakub at gcc dot gnu.org
2011-03-15 17:53 ` jb at gcc dot gnu.org
2011-03-15 20:44 ` jb at gcc dot gnu.org
2011-03-16 12:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-03-17 13:30 ` ro at gcc dot gnu.org
2011-03-17 13:31 ` [Bug fortran/47571] [4.7 " ro at gcc dot gnu.org
2011-03-21 15:05 ` ro at CeBiTec dot Uni-Bielefeld.DE [this message]
2011-03-21 17:08 ` jakub at gcc dot gnu.org
2011-03-21 17:11 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-03-22 14:18 ` blomqvist.janne at gmail dot com
2011-03-23 13:26 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-03-25 19:59 ` jakub at gcc dot gnu.org
2011-04-11 20:24 ` jb at gcc dot gnu.org
2011-04-15 4:21 ` jb at gcc dot gnu.org
2011-04-18 11:59 ` burnus at gcc dot gnu.org
2011-04-18 12:09 ` jb at gcc dot gnu.org
2011-04-18 14:10 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-04-18 15:51 ` jb at gcc dot gnu.org
2011-04-18 15:59 ` jb at gcc dot gnu.org
2015-08-31 14:03 ` fxcoudert at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-47571-4-dlSy0Z8hkd@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).