Re: make-3.79.1 on glibc-2.1.91 (2)

2000-07-23 Thread Paul Eggert

   From: Bruno Haible [EMAIL PROTECTED]
   Date: Mon, 17 Jul 2000 17:23:34 +0200 (CEST)

   Here is a patch to convert this 'if' test to a configure time test, thus
   avoiding the dependency on librt when the function clock_gettime is not
   really used.

That looks like a good approach to work around the linker problem.
I can see some improvements, though:

* The check for high resolution file timestamps can be done at compile-time,
  not at run-time, thus avoiding the need to worry about cross-compiling
  when configuring.

* I don't see the need to rename FILE_TIMESTAMP_HI_RES to
  HAVE_HI_RES_FILE_TIMESTAMP.  The latter name is a bit misleading, since
  it's sometimes zero even when the host has high resolution file timestamps.
  Avoiding the rename simplifies the patch.

How about this patch instead?  It assumes all the previous patches
I've submitted for make 3.79.1.

2000-07-23  Bruno Haible  [EMAIL PROTECTED]
   and  Paul Eggert  [EMAIL PROTECTED]

* file.c (file_timestamp_now):
Use preprocessor-time check for FILE_TIMESTAMP_HI_RES
so that clock_gettime is not linked unless needed.

* filedef.h (FILE_TIMESTAMP_HI_RES):
Remove definition; "configure" now does this.

* configure.in (jm_AC_TYPE_UINTMAX_T): Move up,
to before high resolution file timestamp check,
since that check now uses uintmax_t.
(FILE_TIMESTAMP_HI_RES): Define to nonzero if the code should use
high resolution file timestamps.
(HAVE_CLOCK_GETTIME): Do not define if !FILE_TIMESTAMP_HI_RES,
so that we don't link in clock_gettime unnecessarily.

===
RCS file: configure.in,v
retrieving revision 3.79.1.0
retrieving revision 3.79.1.1
diff -pu -r3.79.1.0 -r3.79.1.1
--- configure.in2000/06/23 16:09:41 3.79.1.0
+++ configure.in2000/07/23 07:22:51 3.79.1.1
@@ -53,10 +53,39 @@ AC_ARG_ENABLE(nsec-timestamps,
   [make_cv_nsec_timestamps="$enableval"],
   [make_cv_nsec_timestamps="yes"])
 
+jm_AC_TYPE_UINTMAX_T
 if test "x$make_cv_nsec_timestamps" != xno; then
   AC_STRUCT_ST_MTIM_NSEC
+  AC_MSG_CHECKING([whether to use high resolution file timestamps])
+  AC_CACHE_VAL(make_cv_file_timestamp_hi_res, [
+make_cv_file_timestamp_hi_res=no
+if test $ac_cv_struct_st_mtim_nsec != no; then
+  AC_TRY_COMPILE([
+#  if HAVE_INTTYPES_H
+#   include inttypes.h
+#  endif],
+   [char a[0x7fff  (uintmax_t) -1  30 ? 1 : -1];],
+   make_cv_file_timestamp_hi_res=yes)
+fi])
+  AC_MSG_RESULT($make_cv_file_timestamp_hi_res)
+  if test $make_cv_file_timestamp_hi_res = yes; then
+val=1
+  else
+val=0
+  fi
+  AC_DEFINE_UNQUOTED(FILE_TIMESTAMP_HI_RES, $val,
+[Use high resolution file timestamps if nonzero.])
+
+  if test $make_cv_file_timestamp_hi_res = yes; then
+# Solaris 2.5.1 needs -lposix4 to get the clock_gettime function.
+# Solaris 7 prefers the library name -lrt to the obsolescent name -lposix4.
+AC_SEARCH_LIBS(clock_gettime, [rt posix4])
+if test "$ac_cv_search_clock_gettime" != no; then
+  AC_DEFINE(HAVE_CLOCK_GETTIME, 1,
+   [Define if you have the clock_gettime function.])
+fi
+  fi
 fi
-jm_AC_TYPE_UINTMAX_T
 
 AC_SUBST(LIBOBJS)
 
@@ -73,14 +102,6 @@ changequote([,])dnl
 fi
 AC_MSG_RESULT($ac_cv_check_symbol_$1)])dnl
 
-# Solaris 2.5.1 needs -lposix4 to get the clock_gettime function.
-# Solaris 7 prefers the library name -lrt to the obsolescent name -lposix4.
-AC_SEARCH_LIBS(clock_gettime, [rt posix4])
-if test "$ac_cv_search_clock_gettime" != no; then
-  AC_DEFINE(HAVE_CLOCK_GETTIME, 1,
-[Define if you have the clock_gettime function.])
-fi
-
 # See if we have a standard version of gettimeofday().  Since actual
 # implementations can differ, just make sure we have the most common
 # one.
===
RCS file: file.c,v
retrieving revision 3.79.1.1
retrieving revision 3.79.1.2
diff -pu -r3.79.1.1 -r3.79.1.2
--- file.c  2000/07/07 07:01:18 3.79.1.1
+++ file.c  2000/07/23 07:22:51 3.79.1.2
@@ -592,33 +592,32 @@ file_timestamp_now (int *resolution)
   /* Don't bother with high-resolution clocks if file timestamps have
  only one-second resolution.  The code below should work, but it's
  not worth the hassle of debugging it on hosts where it fails.  */
-  if (FILE_TIMESTAMP_HI_RES)
-{
-#if HAVE_CLOCK_GETTIME  defined CLOCK_REALTIME
+#if FILE_TIMESTAMP_HI_RES
+# if HAVE_CLOCK_GETTIME  defined CLOCK_REALTIME
+  {
+struct timespec timespec;
+if (clock_gettime (CLOCK_REALTIME, timespec) == 0)
   {
-   struct timespec timespec;
-   if (clock_gettime (CLOCK_REALTIME, timespec) == 0)
- {
-   r = 1;
-   s = timespec.tv_sec;
-   ns = timespec.tv_nsec;
-   goto got_time;
- }
+   r = 1;
+   s = timespec.tv_sec;
+   

Re: make-3.79.1 on glibc-2.1.91 (2)

2000-07-23 Thread Paul D. Smith

Thanks.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




Re: make-3.79.1 on glibc-2.1.91 (2)

2000-07-17 Thread Paul D. Smith

%% Bruno Haible [EMAIL PROTECTED] writes:

  bh make-3.79.1, built on a recent glibc snapshot, links with the shared
  bh library librt, but doesn't any symbol from this library! Of course this
  bh costs startup time.

  bh The reason is that the function file_timestamp_now() in file.c uses
  bh clock_gettime, but that block depends on

  bh if (FILE_TIMESTAMP_HI_RES)

  bh which macroexpands into

  bh if (0)

Seems like any decent compiler would omit this code!  Since Linux is
using GCC, I would double-expect that.  Maybe it only happens when you
build with optimization on?

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




Re: make-3.79.1 on glibc-2.1.91 (2)

2000-07-17 Thread Bruno Haible

Paul D. Smith writes:

 Seems like any decent compiler would omit this code!  Since Linux is
 using GCC, I would double-expect that.  Maybe it only happens when you
 build with optimization on?

No compiler is required to omit "if (0)" code, and gcc indeed doesn't
omit it if -O is not given. Therefore compiling the make-3.79.1 code
without optimization but without -lutil will result in a link error.
Since looking into the optimization flags in order to know whether to
link in libutil.so is too tricky, it is preferrable to determine a
priori whether libutil.so will be needed.

Bruno




Re: make-3.79.1 on glibc-2.1.91 (2)

2000-07-17 Thread Paul D. Smith

%% Bruno Haible [EMAIL PROTECTED] writes:

  bh Paul D. Smith writes:

   Seems like any decent compiler would omit this code!  Since Linux is
   using GCC, I would double-expect that.  Maybe it only happens when you
   build with optimization on?

  bh No compiler is required to omit "if (0)" code, and gcc indeed
  bh doesn't omit it if -O is not given.

Certainly compilers aren't required to do so.

  bh Therefore compiling the make-3.79.1 code without optimization but
  bh without -lutil will result in a link error.  Since looking into
  bh the optimization flags in order to know whether to link in
  bh libutil.so is too tricky, it is preferrable to determine a priori
  bh whether libutil.so will be needed.

I wasn't suggesting that -lutil be removed from the link line; I guess I
was assuming that the linker would be intelligent enough to not bother
with libraries where no reference exists in the code.

That is, if the compiler omitted the invocation of clock_gettime (as
most every compiler will do with -O at least--that's a _very_ simple
optimization), then the linker wouldn't add a reference to the library
even though it appeared on the link line since no symbol in that library
was used by the program.

I agree this is a good bit of assuming; nevertheless it would be
interesting to see if make included a reference to libutil.so if
compiled with -O.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




Re: make-3.79.1 on glibc-2.1.91 (2)

2000-07-17 Thread Bruno Haible

Paul D. Smith writes:

 it would be interesting to see if make included a reference to
 libutil.so if compiled with -O.

Yes, it did. I verified using "ldd ./make" that it had a reference to
libutil.so before my patch, and that with my patch, the reference was
gone.

Bruno