All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ronald Wampler <rdwampler@gmail.com>,
	git@vger.kernel.org, mackyle@gmail.com, reubenhwk@gmail.com,
	sunshine@sunshineco.com
Subject: [PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now
Date: Sun, 10 Jul 2016 22:16:44 +0000	[thread overview]
Message-ID: <20160710221644.GA4927@whir> (raw)
In-Reply-To: <xmqqwpkxnoae.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> wrote:
> Ronald Wampler <rdwampler@gmail.com> 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 <e@80x24.org>
---
 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

  reply	other threads:[~2016-07-10 22:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07 20:45 [PATCH] Makefile: add NEEDS_LIBRT to optionally link with librt Ronald Wampler
2016-07-07 21:14 ` Junio C Hamano
2016-07-10 22:16   ` Eric Wong [this message]
2016-07-11 10:36     ` [PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now brian m. carlson
2016-07-11 18:44       ` Junio C Hamano

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=20160710221644.GA4927@whir \
    --to=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mackyle@gmail.com \
    --cc=rdwampler@gmail.com \
    --cc=reubenhwk@gmail.com \
    --cc=sunshine@sunshineco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.