From: Paul Smith <psmith@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>, Simon Marchi <simark@simark.ca>
Cc: gdb@sourceware.org
Subject: Re: GDB 8.3.1 gdbserver linker error: needs -lrt
Date: Fri, 31 Jan 2020 16:48:00 -0000 [thread overview]
Message-ID: <2820a9d3d0c191d64f24565d583508db9c1b067f.camel@gnu.org> (raw)
In-Reply-To: <831rrgm5o8.fsf@gnu.org>
On Fri, 2020-01-31 at 09:44 +0200, Eli Zaretskii wrote:
> > From: Simon Marchi <simark@simark.ca>
> > Date: Thu, 30 Jan 2020 17:49:59 -0500
> >
> > > > That would work around the problem, but if you want to fix it
> > > > for good, for all users in the same situation, then it would
> > > > probably require a patch to configure.ac, to add "-lrt" to LIBS
> > > > when needed.
> > >
> > > Yes, definitely... that's why I posted the message :).
>
> Any reason why we don't use pkg-config for finding out these
> dependencies?
I'm not sure how pkg-config helps in this situation... isn't pkg-config
used for obtaining correct options for using another package?
In this case, we need a new library to link gdbserver directly, not
because of some other package that gdbserver depends on, so we don't
have a package that might contain a pkg-config we could use.
Maybe you mean, a pkg-config for libstdc++ static linking? I'm not
sure GCC installs such a thing.
I'm pretty sure there are a LOT of configure.ac files out there that
search for -lrt that could be used as. It's just that in this case we
didn't realize we needed it, because (a) it's needed by libstdc++.a but
probably not if you dynamically link libstdc++ (becase the .so probably
links librt.so) and (b) it's only needed with older GNU libc; I think
newer versions of GNU libc have moved clock_gettime etc. into the
normal library and -lrt is obsolete.
next prev parent reply other threads:[~2020-01-31 16:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 21:23 Paul Smith
2020-01-30 21:35 ` Simon Marchi
2020-01-30 22:17 ` Paul Smith
2020-01-30 22:50 ` Simon Marchi
2020-01-31 7:44 ` Eli Zaretskii
2020-01-31 16:48 ` Paul Smith [this message]
2020-01-31 17:17 ` Eli Zaretskii
2020-01-31 17:23 ` Paul Smith
2020-02-01 3:05 ` Simon Marchi
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=2820a9d3d0c191d64f24565d583508db9c1b067f.camel@gnu.org \
--to=psmith@gnu.org \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
--cc=simark@simark.ca \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).