make-3.79.1 on glibc-2.1.91 (2)
Hi, make-3.79.1, built on a recent glibc snapshot, links with the shared library librt, but doesn't any symbol from this library! Of course this costs startup time. The reason is that the function file_timestamp_now() in file.c uses clock_gettime, but that block depends on if (FILE_TIMESTAMP_HI_RES) which macroexpands into if (0) 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. 2000-07-14 Bruno Haible <[EMAIL PROTECTED]> * configure.in: Add test evaluating FILE_TIMESTAMP_HI_RES. Define HAVE_HI_RES_FILE_TIMESTAMP depending on the result. Check for clock_gettime only if HAVE_HI_RES_FILE_TIMESTAMP is 1. * filedef.h (FILE_TIMESTAMP_HI_RES): Remove macro. (FILE_TIMESTAMPS_PER_S, FILE_TIMESTAMP_LO_BITS): Use HAVE_HI_RES_FILE_TIMESTAMP in place of FILE_TIMESTAMP_HI_RES. * file.c (file_timestamp_cons): Likewise. (file_timestamp_now): Likewise. *** make-3.79.1/configure.in.bakFri Jun 23 18:09:41 2000 --- make-3.79.1/configure.inSat Jul 15 19:31:47 2000 *** *** 53,62 [make_cv_nsec_timestamps="$enableval"], [make_cv_nsec_timestamps="yes"]) if test "x$make_cv_nsec_timestamps" != xno; then AC_STRUCT_ST_MTIM_NSEC fi - jm_AC_TYPE_UINTMAX_T AC_SUBST(LIBOBJS) --- 53,109 [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([for high resolution file timestamps]) + AC_CACHE_VAL(make_cv_hi_res_file_timestamp, [ + AC_TRY_RUN([ + #if HAVE_INTTYPES_H + # include + #endif + #define FILE_TIMESTAMP uintmax_t + + #if HAVE_LIMITS_H + # include + #endif + #ifndef CHAR_BIT + # define CHAR_BIT 8 + #endif + #define INTEGER_TYPE_SIGNED(t) ((t) -1 < 0) + #define INTEGER_TYPE_MINIMUM(t) \ + (! INTEGER_TYPE_SIGNED (t) ? (t) 0 : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)) + #define INTEGER_TYPE_MAXIMUM(t) (~ (t) 0 - INTEGER_TYPE_MINIMUM (t)) + + #ifdef ST_MTIM_NSEC + #define FILE_TIMESTAMP_HI_RES \ + (2147483647 < INTEGER_TYPE_MAXIMUM (FILE_TIMESTAMP) >> 31) + #else + #define FILE_TIMESTAMP_HI_RES 0 + #endif + + int main () { exit(FILE_TIMESTAMP_HI_RES ? 0 : 1); } + ], make_cv_hi_res_file_timestamp=yes, make_cv_hi_res_file_timestamp=no, + make_cv_hi_res_file_timestamp=no)]) + AC_MSG_RESULT($make_cv_hi_res_file_timestamp) + if test $make_cv_hi_res_file_timestamp = yes; then + val=1 + else + val=0 + fi + AC_DEFINE_UNQUOTED(HAVE_HI_RES_FILE_TIMESTAMP, $val, + [Define if files can have high resolution timestamps.]) + + if test $make_cv_hi_res_file_timestamp = 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 AC_SUBST(LIBOBJS) *** *** 73,86 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. --- 120,125 *** make-3.79.1/filedef.h.bak Tue Jun 20 16:00:16 2000 --- make-3.79.1/filedef.h Sat Jul 15 19:34:36 2000 *** *** 110,122 extern void notice_finished_file PARAMS ((struct file *file)); ! #ifdef ST_MTIM_NSEC ! # define FILE_TIMESTAMP_HI_RES \ ! (2147483647 < INTEGER_TYPE_MAXIMUM (FILE_TIMESTAMP) >> 31) # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \ file_timestamp_cons (fname, (st).st_mtime, (st).st_mtim.ST_MTIM_NSEC) #else - # define FILE_TIMESTAMP_HI_RES 0 # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \ file_timestamp_cons (fname, (st).st_mtime, 0) #endif --- 110,119 extern void notice_finished_file PARAMS ((struct file *file)); ! #if HAVE_HI_RES_FILE_TIMESTAMP # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \ file_timestamp_cons (fname, (st).st_mtime, (st).st_mtim.ST_MTIM_NSEC) #else # define FILE_TIMESTAMP_STAT_MODTIME(fname, st) \ file_timestamp_cons (fname, (st).st_mtime, 0) #endif *** *** 126,133 slightly decreasing the number of available timestamps.) With 64-bit FILE_TIMESTAMP, this stops working on 2514-
make-3.79.1 on glibc-2.1.91
Hi, make-3.79.1, built on a recent glibc snapshot, links with the shared library libutil, but doesn't any symbol from this library! Of course this costs startup time. The reason is the AC_FUNC_GETLOADAVG macro. It checks for getloadavg in -lutil. Now glibc-2.2 has getloadavg in libc, but it also has an (unrelated) libutil. This code from AC_FUNC_GETLOADAVG # Check for the 4.4BSD definition of getloadavg. AC_CHECK_LIB(util, getloadavg, [LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes]) ought to be changed to # Check for the glibc-2.2 definition of getloadavg. AC_CHECK_FUNC(getloadavg, [ac_have_func=yes]) # Check for the 4.4BSD definition of getloadavg. if test $ac_have_func = no; then AC_CHECK_LIB(util, getloadavg, [LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes]) fi This way, getloadavg is recognized as existent, but -lutil is not unnecessarily added to LIBS. Bruno
Re: make-3.79.1 on glibc-2.1.91 (2)
%% 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
| Hi, | | make-3.79.1, built on a recent glibc snapshot, links with the shared | library libutil, but doesn't any symbol from this library! Of course | this costs startup time. | | The reason is the AC_FUNC_GETLOADAVG macro. It checks for getloadavg | in -lutil. Now glibc-2.2 has getloadavg in libc, but it also has an | (unrelated) libutil. This code from AC_FUNC_GETLOADAVG | | # Check for the 4.4BSD definition of getloadavg. | AC_CHECK_LIB(util, getloadavg, | [LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes]) | | ought to be changed to | | # Check for the glibc-2.2 definition of getloadavg. | AC_CHECK_FUNC(getloadavg, [ac_have_func=yes]) | # Check for the 4.4BSD definition of getloadavg. | if test $ac_have_func = no; then | AC_CHECK_LIB(util, getloadavg, | [LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes]) | fi | | This way, getloadavg is recognized as existent, but -lutil is not | unnecessarily added to LIBS. | | Bruno I think the current Autoconf is right. It has this: # AC_FUNC_GETLOADAVG # -- AC_DEFUN([AC_FUNC_GETLOADAVG], [ac_have_func=no # yes means we've found a way to get the load average. ac_save_LIBS=$LIBS # Check for getloadavg, but be sure not to touch the cache variable. (AC_CHECK_FUNC(getloadavg, exit 0, exit 1)) && ac_have_func=yes # On HPUX9, an unprivileged user can get load averages through this function. AC_CHECK_FUNCS(pstat_getdynamic) # Solaris has libkstat which does not require root. AC_CHECK_LIB(kstat, kstat_open) test $ac_cv_lib_kstat_kstat_open = yes && ac_have_func=yes # Some systems with -lutil have (and need) -lkvm as well, some do not. # On Solaris, -lkvm requires nlist from -lelf, so check that first # to get the right answer into the cache. # For kstat on solaris, we need libelf to force the definition of SVR4 below. if test $ac_have_func = no; then AC_CHECK_LIB(elf, elf_begin, LIBS="-lelf $LIBS") fi if test $ac_have_func = no; then AC_CHECK_LIB(kvm, kvm_open, LIBS="-lkvm $LIBS") # Check for the 4.4BSD definition of getloadavg. AC_CHECK_LIB(util, getloadavg, [LIBS="-lutil $LIBS" ac_have_func=yes ac_cv_func_getloadavg_setgid=yes]) fi if test $ac_have_func = no; then # There is a commonly available library for RS/6000 AIX. # Since it is not a standard part of AIX, it might be installed locally. ac_getloadavg_LIBS=$LIBS LIBS="-L/usr/local/lib $LIBS" AC_CHECK_LIB(getloadavg, getloadavg, [LIBS="-lgetloadavg $LIBS"], [LIBS=$ac_getloadavg_LIBS]) fi # Make sure it is really in the library, if we think we found it, # otherwise set up the replacement function. AC_CHECK_FUNCS(getloadavg, [], [_AC_LIBOBJ_GETLOADAVG]) # Some definitions of getloadavg require that the program be installed setgid. dnl FIXME: Don't hardwire the path of getloadavg.c in the top-level directory. AC_CACHE_CHECK(whether getloadavg requires setgid, ac_cv_func_getloadavg_setgid, [AC_EGREP_CPP([Yowza Am I SETGID yet], [#include "$srcdir/getloadavg.c" #ifdef LDAV_PRIVILEGED Yowza Am I SETGID yet @%:@endif], ac_cv_func_getloadavg_setgid=yes, ac_cv_func_getloadavg_setgid=no)]) if test $ac_cv_func_getloadavg_setgid = yes; then NEED_SETGID=true AC_DEFINE(GETLOADAVG_PRIVILEGED, 1, [Define if the `getloadavg' function needs to be run setuid or setgid.]) else NEED_SETGID=false fi AC_SUBST(NEED_SETGID)dnl if test $ac_cv_func_getloadavg_setgid = yes; then AC_CACHE_CHECK(group of /dev/kmem, ac_cv_group_kmem, [ # On Solaris, /dev/kmem is a symlink. Get info on the real file. ac_ls_output=`ls -lgL /dev/kmem 2>/dev/null` # If we got an error (system does not support symlinks), try without -L. test -z "$ac_ls_output" && ac_ls_output=`ls -lg /dev/kmem` ac_cv_group_kmem=`echo $ac_ls_output \ | sed -ne ['s/[ ][ ]*/ /g; s/^.[sSrwx-]* *[0-9]* *\([^0-9]*\) *.*/\1/; / /s/.* //;p;']` ]) AC_SUBST(KMEM_GROUP, $ac_cv_group_kmem)dnl fi if test "x$ac_save_LIBS" = x; then GETLOADAVG_LIBS=$LIBS else GETLOADAVG_LIBS=`echo "$LIBS" | sed "s!$ac_save_LIBS!!"` fi AC_SUBST(GETLOADAVG_LIBS)dnl ])# AC_FUNC_GETLOADAVG
Re: make-3.79.1 on glibc-2.1.91 (2)
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)
%% 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)
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