# [PATCH] Makefile: add NEEDS_LIBRT to optionally link with librt 5 messages from 2016-07-07 to 2016-07-11. Participants: Ronald Wampler, Junio C Hamano, Eric Wong, brian m. carlson. Thread: https://gitlist.dev/t/42799 ## Ronald Wampler, 2016-07-07 20:45 Subject: [PATCH] Makefile: add NEEDS_LIBRT to optionally link with librt Message-ID: <20160707204554.14961-1-rdwampler@gmail.com> URL: https://gitlist.dev/e/20160707204554.14961-1-rdwampler%40gmail.com ``` We unconditionally link with librt, when HAVE_CLOCK_GETTIME is defined. But clock_gettime() has been available in most libc implementations for some time now (e.g., for glibc since version 2.17) and no longer requires linking with librt. Furthermore, commit a6c3c63 (configure.ac: check for clock_gettime() and CLOCK_MONOTONIC) will automatically determined which library (libc or librt) is required for linking when checking for clock_gettime(). The assumption to unconditionally link with librt was OK, since either almost every Unix-like system provides a version of librt for backwards compatibility or other systems, namely Windows or OS X, never provided clock_gettime(). However, in the latest release of OS X (macOS Sierra), this function has been added to OS X libc version. As a result, when running the configuration script, HAVE_CLOCK_GETTIME is set and since librt is not present, it causes a linker error. This patches requires those not building via the configuration scripts to define NEEDS_LIBRT in addition to HAVE_CLOCK_GETTIME, if needed. Signed-off-by: Ronald Wampler --- I am not sure if this the correction solution. Another option I considered was to wrap the EXTLIBS += -lrt is an ifndef NO_RT and only defining NO_RT for Mac OS X in config.mak.uname. Makefile | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index de5a030..32f503e 100644 --- a/Makefile +++ b/Makefile @@ -351,9 +351,12 @@ all:: # Define GMTIME_UNRELIABLE_ERRORS if your gmtime() function does not # return NULL when it receives a bogus time_t. # -# Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt. +# Define HAVE_CLOCK_GETTIME if your platform has clock_gettime. # -# Define HAVE_CLOCK_MONOTONIC if your platform has CLOCK_MONOTONIC in librt. +# Define HAVE_CLOCK_MONOTONIC if your platform has CLOCK_MONOTONIC. +# +# Define NEEDS_LIBRT if your platform requires linking with librt (glibc version +# before 2.17) for clock_gettime and CLOCK_MONOTONIC. # # Define USE_PARENS_AROUND_GETTEXT_N to "yes" if your compiler happily # compiles the following initialization: @@ -1465,13 +1468,16 @@ endif ifdef HAVE_CLOCK_GETTIME BASIC_CFLAGS += -DHAVE_CLOCK_GETTIME - EXTLIBS += -lrt endif ifdef HAVE_CLOCK_MONOTONIC BASIC_CFLAGS += -DHAVE_CLOCK_MONOTONIC endif +ifdef NEEDS_LIBRT + EXTLIBS += -lrt +endif + ifdef HAVE_BSD_SYSCTL BASIC_CFLAGS += -DHAVE_BSD_SYSCTL endif -- 2.8.2.874.gcf4c2cf ``` ## Junio C Hamano, 2016-07-07 21:14 Subject: Re: [PATCH] Makefile: add NEEDS_LIBRT to optionally link with librt Message-ID: URL: https://gitlist.dev/e/xmqqwpkxnoae.fsf%40gitster.mtv.corp.google.com In-Reply-To: <20160707204554.14961-1-rdwampler@gmail.com> ``` Ronald Wampler writes: > I am not sure if this the correction solution. Another option I > considered was to wrap the EXTLIBS += -lrt is an ifndef NO_RT and only > defining NO_RT for Mac OS X in config.mak.uname. That alternative would make the resulting code noisier/uglier with nested ifdef, I would imagine, but it would be of less impact to the existing users. But my gut feeling is that the patch you sent is probably a better solution for the longer term. Thanks. ``` ## Eric Wong, 2016-07-10 22:16 Subject: [PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now Message-ID: <20160710221644.GA4927@whir> URL: https://gitlist.dev/e/20160710221644.GA4927%40whir In-Reply-To: ``` Junio C Hamano wrote: > Ronald Wampler writes: > > > I am not sure if this the correction solution. Another option I > > considered was to wrap the EXTLIBS += -lrt is an ifndef NO_RT and only > > defining NO_RT for Mac OS X in config.mak.uname. > > That alternative would make the resulting code noisier/uglier with > nested ifdef, I would imagine, but it would be of less impact to the > existing users. But my gut feeling is that the patch you sent is > probably a better solution for the longer term. That change broke my Debian wheezy LTS system, which isn't too out-of-date. I think having excessive linkage on newer systems is preferable to breaking the out-of-the-box experience. I don't know about other platforms, but I think the following will help users on older GNU/Linux systems for the next few years: -------8<------ Subject: [PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now My Debian wheezy LTS system is still on glibc 2.13; and LTS distros may use older glibc, still, so lets not unnecessarily break things out-of-the-box. We seem to assume Linux is using glibc in our Makefiles anyways, so I don't think this will introduce new breakage for users of alternative libc implementations. Signed-off-by: Eric Wong --- config.mak.uname | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index a88f139..22958a8 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -36,6 +36,8 @@ ifeq ($(uname_S),Linux) HAVE_DEV_TTY = YesPlease HAVE_CLOCK_GETTIME = YesPlease HAVE_CLOCK_MONOTONIC = YesPlease + # -lrt is needed for clock_gettime on glibc <= 2.16 + NEEDS_LIBRT = YesPlease HAVE_GETDELIM = YesPlease SANE_TEXT_GREP=-a endif -- EW ``` ## brian m. carlson, 2016-07-11 10:36 Subject: Re: [PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now Message-ID: <20160711103653.GA29598@vauxhall.crustytoothpaste.net> URL: https://gitlist.dev/e/20160711103653.GA29598%40vauxhall.crustytoothpaste.net In-Reply-To: <20160710221644.GA4927@whir> ``` On Sun, Jul 10, 2016 at 10:16:44PM +0000, Eric Wong wrote: > My Debian wheezy LTS system is still on glibc 2.13; and LTS > distros may use older glibc, still, so lets not unnecessarily > break things out-of-the-box. > > We seem to assume Linux is using glibc in our Makefiles anyways, > so I don't think this will introduce new breakage for users of > alternative libc implementations. This is a good idea. If it's broken with Debian wheezy, it will also be broken for RHEL/CentOS 6. People who really want the slimmest linkage can use the -Wl,--as-needed flag. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 ``` ## Junio C Hamano, 2016-07-11 18:44 Subject: Re: [PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now Message-ID: URL: https://gitlist.dev/e/xmqqmvlo9fqh.fsf%40gitster.mtv.corp.google.com In-Reply-To: <20160711103653.GA29598@vauxhall.crustytoothpaste.net> ``` "brian m. carlson" writes: > On Sun, Jul 10, 2016 at 10:16:44PM +0000, Eric Wong wrote: >> My Debian wheezy LTS system is still on glibc 2.13; and LTS >> distros may use older glibc, still, so lets not unnecessarily >> break things out-of-the-box. >> >> We seem to assume Linux is using glibc in our Makefiles anyways, >> so I don't think this will introduce new breakage for users of >> alternative libc implementations. > > This is a good idea. If it's broken with Debian wheezy, it will also be > broken for RHEL/CentOS 6. People who really want the slimmest linkage > can use the -Wl,--as-needed flag. Thanks all, will apply. ```