[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #32 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-14 11:34:00 UTC --- Created attachment 23648 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23648 Proposed patch
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 11:41:53 UTC --- I think you should add below the hunk defining conditionally GF_CLOCK_MONOTONIC: #ifndef GF_CLOCK_MONOTONIC #undef HAVE_CLOCK_GETTIME #undef HAVE_CLOCK_GETTIME_LIBRT #endif now that you don't define GF_CLOCK_MONOTONIC if CLOCK_REALTIME isn't defined.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #34 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-14 11:42:47 UTC --- (In reply to comment #31) That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Not really: the delay was caused because the test system broke and it took me quite some time to get myself a replacement. Normally, I bootstrap everywhere once a week and analyse results. Ok, that's nice to hear. Of course, it doesn't change the fact that this time it did take a month, and, one might add, at almost the worst possible moment. ;) Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead. I'd really like to see this fixed before 4.6.0: it is a regression from 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively minor gain on other platforms. Well, do we really have any actual gfortran users on Tru64? Whereas a high-resolution monotonic clock, while admittedly not a huge feature per se, is something that is now available to gfortran users on some rather more popular platforms. If all else fails, I'd go as far as advocating to revert the patch that introduced clock_gettime There has been a number of patches in this area more or less related to clock_gettime, so IMHO fixing it properly is simpler and less prone to introduce new regressions. My previous message in this PR hopefully does exactly this and introduces a patch which should fix it along the lines previously discussed. As my normal gcc development machine is packed in a box, I haven't been able to test it. Also, note that it won't apply cleanly as the paths are messed up (but the contents should otherwise apply fine). As I mentioned previously, I'd prefer to commit it after the 4.6 release, but if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6. (and quite late in the release cycle, I might say). Yes, it started out as a simple patch which turned into a morass of system-dependent stuff wrt. where clock_gettime lives and various levels of weakref support. Sorry about that.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #35 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-14 11:50:26 UTC --- (In reply to comment #33) I think you should add below the hunk defining conditionally GF_CLOCK_MONOTONIC: #ifndef GF_CLOCK_MONOTONIC #undef HAVE_CLOCK_GETTIME #undef HAVE_CLOCK_GETTIME_LIBRT #endif now that you don't define GF_CLOCK_MONOTONIC if CLOCK_REALTIME isn't defined. Thanks; that should protect against the case where clock_gettime is available but neither CLOCK_REALTIME nor CLOCK_MONOTONIC are. Ideally, this shouldn't be necessary as POSIX specifies that CLOCK_REALTIME must always be available if clock_gettime exists, but I suppose both belts and suspenders are nice in this case.. :)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #36 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-14 12:07:54 UTC --- CLOCK_REALTIME should be available, at least on POSIX compliant systems, but must it be defined as preprocessor macro? http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html talks about manifest constants, not macros. So it wouldn't surprise me if it was defined in an enum rather than using #define. Alternatively to those undefs would be to do #ifdef CLOCK_MONOTONIC #define GF_CLOCK_MONOTONIC CLOCK_MONOTONIC #else #define GF_CLOCK_MONOTONIC CLOCK_REALTIME #endif and just keep using GF_CLOCK_MONOTONIC only in code guarded with HAVE_CLOCK_GETTIME or HAVE_CLOCK_GETTIME_LIBRT, or #ifdef CLOCK_MONOTONIC #define GF_CLOCK_MONOTONIC CLOCK_MONOTONIC #elif defined (HAVE_CLOCK_GETTIME) || defined (HAVE_CLOCK_GETTIME_LIBRT) #define GF_CLOCK_MONOTONIC CLOCK_REALTIME #endif if you prefer that.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-11 16:45:31 UTC --- That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Not really: the delay was caused because the test system broke and it took me quite some time to get myself a replacement. Normally, I bootstrap everywhere once a week and analyse results. Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead. I'd really like to see this fixed before 4.6.0: it is a regression from 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively minor gain on other platforms. If all else fails, I'd go as far as advocating to revert the patch that introduced clock_gettime (and quite late in the release cycle, I might say). Sorry for being so late to reply: I've been totally swamped this week. Thanks. Rainer
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #28 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-08 09:34:36 UTC --- (In reply to comment #26) Tru64 UNIX doesn't support weak undefined symbols, which seems to be what weakrefs are. Hmm, I think it is going to be difficult. What we want to have: a) If libc has clock_gettime, use it unconditionally b) If librt has clock_gettime and weak refs are supported, use it if available c) If librt has it, but no weak refs are supported, don't use it. d) If it not available at all, don't use it. (b) and (d) work; also (a) works - albeit with a warning. Now one needs to support (c). I think the best would be to set (effectively) HAVE_CLOCK_GETTIME to false. One possibility would be to replace: #ifdef HAVE_CLOCK_GETTIME # ifdef SUPPORTS_WEAK ... # else by #if define(HAVE_CLOCK_GETTIME) define(SUPPORTS_WEAK) That would exclude platforms, where libc supports clock_gettime but which do not have weak refs. Another possibility is a link-time check which does not work well for some cross-compilations. What do you think?
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #29 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-08 22:38:49 UTC --- (In reply to comment #28) (In reply to comment #26) Tru64 UNIX doesn't support weak undefined symbols, which seems to be what weakrefs are. Hmm, I think it is going to be difficult. What we want to have: a) If libc has clock_gettime, use it unconditionally b) If librt has clock_gettime and weak refs are supported, use it if available c) If librt has it, but no weak refs are supported, don't use it. d) If it not available at all, don't use it. Yes, sounds like a good plan. (b) and (d) work; also (a) works - albeit with a warning. Now one needs to support (c). Indeed; the patch was developed based on the understanding that only Linux has clock_gettime in librt, and Linux supports weakrefs, so (c) does not need to be considered. Oh well. I think the best would be to set (effectively) HAVE_CLOCK_GETTIME to false. One possibility would be to replace: #ifdef HAVE_CLOCK_GETTIME # ifdef SUPPORTS_WEAK ... # else by #if define(HAVE_CLOCK_GETTIME) define(SUPPORTS_WEAK) That would exclude platforms, where libc supports clock_gettime but which do not have weak refs. Another possibility is a link-time check which does not work well for some cross-compilations. What do you think? I think the easiest way would be to change the test in configure.ac where we check for clock_gettime in librt, so that we set, say, HAVE_CLOCK_GETTIME_LIBRT instead of HAVE_CLOCK_GETTIME, thus allowing us to distinguish whether the function a) exists at all b) is in libc or librt. That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #30 from dave at hiauly1 dot hia.nrc.ca 2011-03-09 00:10:22 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #29 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-08
22:38:49 UTC ---
(In reply to comment #28)
(In reply to comment #26)
Tru64 UNIX doesn't support weak undefined symbols, which seems to be
what weakrefs are.
Hmm, I think it is going to be difficult. What we want to have:
a) If libc has clock_gettime, use it unconditionally
b) If librt has clock_gettime and weak refs are supported, use it if
available
c) If librt has it, but no weak refs are supported, don't use it.
d) If it not available at all, don't use it.
Yes, sounds like a good plan.
(b) and (d) work; also (a) works - albeit with a warning. Now one needs to
support (c).
Indeed; the patch was developed based on the understanding that only Linux has
clock_gettime in librt, and Linux supports weakrefs, so (c) does not need to
be
considered. Oh well.
I think the best would be to set (effectively) HAVE_CLOCK_GETTIME
to false.
One possibility would be to replace:
#ifdef HAVE_CLOCK_GETTIME
# ifdef SUPPORTS_WEAK
...
# else
by
#if define(HAVE_CLOCK_GETTIME) define(SUPPORTS_WEAK)
That would exclude platforms, where libc supports clock_gettime but which do
not have weak refs. Another possibility is a link-time check which does not
work well for some cross-compilations.
What do you think?
I think the easiest way would be to change the test in configure.ac where we
check for clock_gettime in librt, so that we set, say,
HAVE_CLOCK_GETTIME_LIBRT
instead of HAVE_CLOCK_GETTIME, thus allowing us to distinguish whether the
function a) exists at all b) is in libc or librt.
I think it is unnecessary to check whether clock_gettime is in librt
as we don't want libgfortran to depend on librt in general. This reduces
the accuracy when weak references are not supported and clock_gettime
is only in librt. The case where weak references are supported and
clock_gettime isn't available at all seems remote.
If weak references are supported, always define weak_gettime as
__attribute__((__weakref__(clock_gettime))). Probably, the extra
overhead of the runtime check is acceptable.
If weak references are not supported and clock_gettime is in libc,
define weak_gettime as we currently do:
static inline int weak_gettime (clockid_t clk_id, struct timespec *res)
{
return clock_gettime (clk_id, res);
}
Condition the code that uses weak_gettime on either having clock_gettime
in libc or weak references. This could be tweaked to eliminate the `if'
when clock_gettime is in libc.
Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target||alpha-dec-osf5.1b Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Host||alpha-dec-osf5.1b Resolution|FIXED | Target Milestone|--- |4.6.0 Build||alpha-dec-osf5.1b --- Comment #24 from Rainer Orth ro at gcc dot gnu.org 2011-03-07 14:53:42 UTC --- All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an undefined reference to clock_gettime: clock_gettime| | U | The function is defined in librt only.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #25 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-07 16:08:23 UTC --- (In reply to comment #24) All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an undefined reference to clock_gettime: The function is defined in librt only. Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does the problem only occur for static or also for dynamic linkage? Cf. previous patches http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00075.html and http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-07 16:20:17 UTC --- --- Comment #25 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-07 16:08:23 UTC --- (In reply to comment #24) All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an undefined reference to clock_gettime: The function is defined in librt only. Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does Tru64 UNIX doesn't support weak undefined symbols, which seems to be what weakrefs are. the problem only occur for static or also for dynamic linkage? I haven't yet tried static linking, but when using a dynamic libgfortran.so, the breakage occurs as described. Rainer
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #27 from dave at hiauly1 dot hia.nrc.ca 2011-03-07 17:59:27 UTC --- All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an undefined reference to clock_gettime: The function is defined in librt only. Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does The function clock_gettime is available in both libc and librt on PA-RISC HP-UX. I see a compilation warning on 32-bit HP-UX that `if (clock_gettime)' will always evaluate to true. Since libc is always linked in, there isn't a problem on PA HP-UX. Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-07 18:36:33 UTC --- Fixed, closing.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #22 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-05 16:22:09 UTC --- Author: jb Date: Sat Feb 5 16:22:04 2011 New Revision: 169852 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169852 Log: PR 47571 Fix HPUX bootstrap regression, cleanup Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/date_and_time.c trunk/libgfortran/intrinsics/system_clock.c trunk/libgfortran/intrinsics/time_1.h
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #21 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 14:42:39 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html This is my previous janitorial patch, + a kludge which I believe should fix the issue on HP-UX and other targets that support weak references but not weak undefined references. Fixes build error on HP-UX. Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #18 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-03
09:53:50 UTC ---
To add to Tobias comment, in the patch the only place where a weakref is used
is
+#ifdef SUPPORTS_WEAK
+static int weak_gettime (clockid_t, struct timespec *)
+ __attribute__((__weakref__(clock_gettime)));
+#else
+static inline int weak_gettime (clockid_t clk_id, struct timespec *res)
+{
+ return clock_gettime (clk_id, res);
+}
+#endif
That is, for some reason SUPPORTS_WEAK must be defined on HPUX even though weak
references are not actually supported. Why is this?
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2011-02/msg00075.htm |atches/2011-02/msg00196.htm |l |l --- Comment #19 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-03 12:47:59 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html This is my previous janitorial patch, + a kludge which I believe should fix the issue on HP-UX and other targets that support weak references but not weak undefined references.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-02-03 15:33:37 UTC --- on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and probably others. If weak symbols do not work, why is then SUPPORTS_WEAK set? (Or, if it isn't set, why does it fail?) The situation is messy and difficult: 1) The backend defines TARGET_SUPPORTS_WEAK. This is needed for C++. The support varies based on assembler, etc. The target has COMDAT and secondary symbol symbol support when GAS is used. This allows for multiple definitions of functions and data. However, undefined weak symbols are not supported. It is not possible to check whether a function is defined or not using a `if'. A function pointer is actually a pointer to a function descriptor (plabel). 2) Libgfortran defines SUPPORTS_WEAK based on #pragma weak. This is probably wrong for PA HP-UX. There is a similar situation in gthr-posix.h where there is a mechanism to override SUPPORTS_WEAK. 3) I think the actual error was caused by the lack of a declaration for clock_gettime as a function. The default symbol type is data. Was time.h included? 4) Because of 1, the `if' will always evaluate to true. HP-UX has clock_gettime, so this shouldn't be a problem. Dave
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #15 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-02 08:48:27 UTC --- Author: jb Date: Wed Feb 2 08:48:24 2011 New Revision: 169517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169517 Log: PR 47571 Weakref trickery for clock_gettime() Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/time_1.h
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #16 from John David Anglin danglin at gcc dot gnu.org 2011-02-03 00:44:13 UTC --- (In reply to comment #15) Author: jb Date: Wed Feb 2 08:48:24 2011 New Revision: 169517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169517 Log: PR 47571 Weakref trickery for clock_gettime() Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/time_1.h Causes /usr/ccs/bin/ld: Invalid symbol type for plabel (.libs/date_and_time.o, clock_ge ttime). collect2: ld returned 1 exit status on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and probably others.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-03 07:38:44 UTC --- (In reply to comment #16) on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and probably others. If weak symbols do not work, why is then SUPPORTS_WEAK set? (Or, if it isn't set, why does it fail?)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org, ||jb at gcc dot gnu.org Summary|undefined reference to |[4.6 Regression] undefined |clock_gettime in Linux |reference to clock_gettime |build of 02/01/2011 |in Linux build of ||02/01/2011 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 14:56:30 UTC --- clock_gettime is part of POSIX. Linux's man page states: Feature Test Macro Requirements for glibc _POSIX_C_SOURCE = 199309L
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 15:08:13 UTC --- On Linux/Glibc libgfortran is built with _GNU_SOURCE, which according to the glibc manual is a superset of all kinds of _POSIX_C_SOURCE=[latest_supported_standard] XOPEN_SOURCE=[latest_supported_standard] and so forth. My guess is that the issue is due to mismatch between the build environment and the environment where gfortran is executed. It might be that the OP is running on some old distro that doesn't provide librt.so which is needed by clock_gettime() on Glibc. OP, what does ldd /path/to/libgfortran.so.3 say? FWIW, I have no idea what Patch 81226 refers to.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 15:14:14 UTC --- clock_gettime is defined in librt, so if libgfortran started using librt symbols, it needs to a) link against it dynamically for libgfortran.so b) arrange for gfortran driver to pass in -lrt when linking libgfortran statically.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #4 from Michael Richmond michael.a.richmond at nasa dot gov 2011-02-01 15:27:19 UTC --- (In reply to comment #2) OP, what does ldd /path/to/libgfortran.so.3 say? linux-gate.so.1 = (0xe000) libm.so.6 = /lib/libm.so.6 (0xb772b000) libc.so.6 = /lib/libc.so.6 (0xb75c) /lib/ld-linux.so.2 (0xb7822000) I am running SuSE Linux 11.3
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 15:29:50 UTC --- For the symbols defined in librt, cf. http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/librt.html Regarding http://gcc.gnu.org/ml/fortran/2011-01/msg00326.html 2) Uses clock_gettime() if available and (In reply to comment #3) clock_gettime is defined in librt, so if libgfortran started using librt symbols It probably means that one needs to use libgfortran.spec for that as f951 has no knowledge whether clock_gettime is available. Is is clear that librt exists if clock_gettime is available? librt seems to be a Linux-specific library-name choice. If not, one could consider moving back to a clock_gettime-free libgfortran.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #6 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 15:50:52 UTC --- (In reply to comment #3) clock_gettime is defined in librt, so if libgfortran started using librt symbols, it needs to a) link against it dynamically for libgfortran.so Yes, that's what it does, using a configure.ac snippet lifted from libgomp. On my system, ldd libgfortran.so shows: linux-vdso.so.1 = (0x7fff71ae9000) libquadmath.so.0 = /home/janne/src/gfortran/trunk/install/lib/../lib64/libquadmath.so.0 (0x7f885a485000) libm.so.6 = /lib/libm.so.6 (0x7f885a1df000) librt.so.1 = /lib/librt.so.1 (0x7f8859fd7000) libc.so.6 = /lib/libc.so.6 (0x7f8859c54000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f8859a36000) /lib64/ld-linux-x86-64.so.2 (0x7f885a9cf000) where the librt and libpthread dependencies are due to using clock_gettime() from librt. b) arrange for gfortran driver to pass in -lrt when linking libgfortran statically. Right, I haven't considered this part. Anyone have any idea how that could be done?
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Target|i686-pc-linux-gnu | Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.01 16:02:50 Host|i686-pc-linux-gnu | AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Build|i686-pc-linux-gnu | --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 16:02:50 UTC --- So using -static I was able to reproduce this bug on x86_64-unknown-linux-gnu. As Jakub mentioned, the driver must link in librt when linking statically. I'll look into how this could be done. As a workaround for the reporter, dynamic linking works fine.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01
16:08:10 UTC ---
(In reply to comment #6)
clock_gettime is defined in librt, so if libgfortran started using librt
symbols, it needs to a) link against it dynamically for libgfortran.so
Yes, that's what it does
But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor
very special.
b)
arrange for gfortran driver to pass in -lrt when linking libgfortran
statically.
Right, I haven't considered this part. Anyone have any idea how that could be
done?
Via libgfortran/libgfortran.spec.in and some configure script?
Cf. libgomp and libgomp/configure.ac's
# Set up the set of libraries that we need to link against for libgomp.
# Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp,
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
link_gomp=-lgomp %{static: $LIBS}
else
link_gomp=-lgomp $LIBS
fi
AC_SUBST(link_gomp)
By the way, there is also -lrt added via libgomp/configure.tgt for HPUX.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-01 16:13:24 UTC --- How many fortran users actually need to more precise DATE_AND_TIME though? Bringing in -lpthread (as dependency of -lrt) certainly has some extra overhead, e.g. everything that uses gthr* will suddenly use real locking. You could e.g. use clock_gettime only through a weakref, thus let the users choose if clock_gettime should be used or not. If they don't link in librt, less precise implementation would be used, if they do link it in, it would become more precise (-lrt would be linked in automatically e.g. for -fopenmp compilations).
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #10 from Michael Richmond michael.a.richmond at nasa dot gov 2011-02-01 16:18:49 UTC --- (In reply to comment #7) As a workaround for the reporter, dynamic linking works fine. When I use gfortran -Bdynamic call_date_and_time.f90 I get the same error
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #11 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01
16:20:06 UTC ---
(In reply to comment #8)
(In reply to comment #6)
clock_gettime is defined in librt, so if libgfortran started using librt
symbols, it needs to a) link against it dynamically for libgfortran.so
Yes, that's what it does
But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor
very special.
Because the original report links statically (as can be deduced from the
presence of libgfortran.a). As I mentioned, static linking is broken but
dynamic works. FWIW, I suspect the output of ldd in comment #4 refers to the
system provided libgfortran, as neither librt nor libquadmath is present.
b)
arrange for gfortran driver to pass in -lrt when linking libgfortran
statically.
Right, I haven't considered this part. Anyone have any idea how that could
be
done?
Via libgfortran/libgfortran.spec.in and some configure script?
Cf. libgomp and libgomp/configure.ac's
# Set up the set of libraries that we need to link against for libgomp.
# Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp,
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
link_gomp=-lgomp %{static: $LIBS}
else
link_gomp=-lgomp $LIBS
fi
AC_SUBST(link_gomp)
By the way, there is also -lrt added via libgomp/configure.tgt for HPUX.
Thanks, I'll have to take a look at this later tonight.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-01 16:26:33 UTC --- I concur with Jakub. If (big if) I have understood weakrefs correctly, one does something like in libquadmath/quadmath_weak.h and then can use them then in the following way if (__weak_reference_name) res = __weak_reference_name () else res = some_other_function (Cf. also http://stackoverflow.com/questions/274753/)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #13 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 20:02:38 UTC --- (In reply to comment #9) How many fortran users actually need to more precise DATE_AND_TIME though? None, since the DATE_AND_TIME API is limited to millisecond precision. The motivation for using clock_gettime() is the SYSTEM_CLOCK intrinsic, whose purpose is precise measurement of wall clock intervals. In this case, the SYSTEM_CLOCK API allows us to expose the extra precision to user code, and perhaps more importantly, we use CLOCK_MONOTONIC which is better suited for this purpose than CLOCK_REALTIME. The reason why DATE_AND_TIME now also uses clock_gettime() is that part of the patch was some cleanup centralizing #ifdefs under a single gf_gettime() function rather than sprinkling them around the code. Bringing in -lpthread (as dependency of -lrt) certainly has some extra overhead, e.g. everything that uses gthr* will suddenly use real locking. You could e.g. use clock_gettime only through a weakref, thus let the users choose if clock_gettime should be used or not. If they don't link in librt, less precise implementation would be used, if they do link it in, it would become more precise (-lrt would be linked in automatically e.g. for -fopenmp compilations). The above being said, this sounds like a good idea. I'll look into this rather than trying to link librt statically. (FWIW I don't think the extra locking overhead would matter in practice, as libgfortran uses quite coarse grained locking, and AFAIK uncontested futexes are very fast)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg00075.htm ||l --- Comment #14 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-01 21:14:18 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00075.html I'm a bit unsure about the whole weakref stuff, but this seems to work for me on x86_64-unknown-linux-gnu.
