From: Paul Smith <psmith@gnu.org>
To: Simon Marchi <simark@simark.ca>, gdb@sourceware.org
Subject: Re: GDB 8.3.1 gdbserver linker error: needs -lrt
Date: Thu, 30 Jan 2020 22:17:00 -0000 [thread overview]
Message-ID: <d67c570a8d2f2a5f4775891ff7b858365c868382.camel@gnu.org> (raw)
In-Reply-To: <49c1cc4a-fe1b-8e35-b16b-76d9faec2173@simark.ca>
On Thu, 2020-01-30 at 16:35 -0500, Simon Marchi wrote:
> GDBSERVER_LIBS is a variable in gdb/gdbserver/Makefile, but I don't
> think it's meant to be overriden from the command line.
Sure, but even if it's not meant to be overridden it should be possible
to do so. make always obeys variable overrides on the command line,
and also passes those overrides along to sub-makes; the only way to
avoid that is do to odd things with make recursion.
> It would probably work to set LIBS while configuring gdbserver:
>
> ./configure LIBS="-lrt"
When you say "configuring gdbserver" I'm not sure what you mean, but
definitely doing this in the root of the GDB distribution does not
work. The root makefile will have LIBS=-lrt in it, but that variable
is not passed on.
Further, the link line for gdbserver doesn't include that variable;
it's just:
gdbserver$(EXEEXT): $(sort $(OBS)) ${CDEPS} $(LIBGNU) $(LIBIBERTY)
$(SILENCE) rm -f gdbserver$(EXEEXT)
$(ECHO_CXXLD) $(CC_LD) $(INTERNAL_CFLAGS) $(INTERNAL_LDFLAGS) \
-o gdbserver$(EXEEXT) $(OBS) $(LIBGNU) $(LIBIBERTY) \
$(GDBSERVER_LIBS) $(XM_CLIBS)
None of the "normal" libs variables are listed in this link line.
That's why I chose GDBSERVER_LIBS.
The link line for libinproctrace.so is even less configurable:
$(IPA_LIB): $(sort $(IPA_OBJS)) ${CDEPS}
$(SILENCE) rm -f $(IPA_LIB)
$(ECHO_CXXLD) $(CC_LD) -shared -fPIC -Wl,--soname=$(IPA_LIB) \
-Wl,--no-undefined $(INTERNAL_CFLAGS) $(INTERNAL_LDFLAGS) \
-o $(IPA_LIB) ${IPA_OBJS} -ldl -pthread
> 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 :).
Cheers!
next prev parent reply other threads:[~2020-01-30 22:17 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 [this message]
2020-01-30 22:50 ` Simon Marchi
2020-01-31 7:44 ` Eli Zaretskii
2020-01-31 16:48 ` Paul Smith
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=d67c570a8d2f2a5f4775891ff7b858365c868382.camel@gnu.org \
--to=psmith@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