* GDB 8.3.1 gdbserver linker error: needs -lrt @ 2020-01-30 21:23 Paul Smith 2020-01-30 21:35 ` Simon Marchi 0 siblings, 1 reply; 9+ messages in thread From: Paul Smith @ 2020-01-30 21:23 UTC (permalink / raw) To: gdb Hi all; I was trying to compile the latest GDB for my system and the link of gdbserver failed: .../lib64/libstdc++.a(chrono.o):function std::chrono::_V2::system_clock::now(): error: undefined reference to 'clock_gettime' .../lib64/libstdc++.a(chrono.o):function std::chrono::_V2::steady_clock::now(): error: undefined reference to 'clock_gettime' As you can see I compile with static libstdc++. Also, I'm building against a pretty old version of GNU/Linux with an older GNU libc (CentOS 6.5 or so). The problem is that on systems this old you need to add -lrt to the link line in order to get clock_gettime(), and the configure script doesn't look for this. This causes both gdbserver and libinproctrace.so to fail to link, unless I hack the makefiles. Gdb itself links properly because I'm linking with lzma and those libs happen to include -lrt: LIBLZMA = .../lib/liblzma.a -lrt Oddly enough, adding GDBSERVER_LIBS="-ldl -lrt" to the top GDB make command doesn't work (even for gdbserver: libinproctrace.so has no equivalent customizable library). I didn't look through the build system to figure out how my command line overrides are being lost but that's also something that should be fixed... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-30 21:23 GDB 8.3.1 gdbserver linker error: needs -lrt Paul Smith @ 2020-01-30 21:35 ` Simon Marchi 2020-01-30 22:17 ` Paul Smith 0 siblings, 1 reply; 9+ messages in thread From: Simon Marchi @ 2020-01-30 21:35 UTC (permalink / raw) To: psmith, gdb On 2020-01-30 4:23 p.m., Paul Smith wrote: > Hi all; > > I was trying to compile the latest GDB for my system and the link of > gdbserver failed: > > .../lib64/libstdc++.a(chrono.o):function std::chrono::_V2::system_clock::now(): error: undefined reference to 'clock_gettime' > .../lib64/libstdc++.a(chrono.o):function std::chrono::_V2::steady_clock::now(): error: undefined reference to 'clock_gettime' > > As you can see I compile with static libstdc++. Also, I'm building > against a pretty old version of GNU/Linux with an older GNU libc > (CentOS 6.5 or so). > > The problem is that on systems this old you need to add -lrt to the > link line in order to get clock_gettime(), and the configure script > doesn't look for this. > > This causes both gdbserver and libinproctrace.so to fail to link, > unless I hack the makefiles. > > Gdb itself links properly because I'm linking with lzma and those libs > happen to include -lrt: > > LIBLZMA = .../lib/liblzma.a -lrt > > > Oddly enough, adding GDBSERVER_LIBS="-ldl -lrt" to the top GDB make > command doesn't work (even for gdbserver: libinproctrace.so has no > equivalent customizable library). I didn't look through the build > system to figure out how my command line overrides are being lost but > that's also something that should be fixed... > GDBSERVER_LIBS is a variable in gdb/gdbserver/Makefile, but I don't think it's meant to be overriden from the command line. It's just an internal variable to simplify the Makefile, as well as an autoconf variable (not sure if that's the right term) that gets replaced in Makefile.in. It would probably work to set LIBS while configuring gdbserver: ./configure LIBS="-lrt" 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. Simon ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-30 21:35 ` Simon Marchi @ 2020-01-30 22:17 ` Paul Smith 2020-01-30 22:50 ` Simon Marchi 0 siblings, 1 reply; 9+ messages in thread From: Paul Smith @ 2020-01-30 22:17 UTC (permalink / raw) To: Simon Marchi, gdb 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! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-30 22:17 ` Paul Smith @ 2020-01-30 22:50 ` Simon Marchi 2020-01-31 7:44 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Simon Marchi @ 2020-01-30 22:50 UTC (permalink / raw) To: psmith, gdb On 2020-01-30 5:17 p.m., Paul Smith wrote: > 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. Hmm right, the list of things passed down is explicit, and LIBS is not part of that. I don't really know if passing down LIBS would be the right thing to do or not. > 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) > When I suggested that, I expected that LIBS would be set in the environment when gdbserver's configure would run, and so it would pick it up and add it to the link line, given that `./gdb/gdbserver/configure --help` says: Some influential environment variables: ... LIBS libraries to pass to the linker, e.g. -l<library> That part seems to work. When I do ./configure LIBS="-lpopt" directly in gdbserver's source directory, popt ends up listed as: XM_CLIBS = -lpopt in the generated Makefile. XM_CLIBS is included in the link line for gdbserver, but it's not in the IPA's. I have no idea what XM_CLIBS stands for. > 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 :). Sorry I can't be of more help, I'm probably as (or more) confused by the situation as you are. Simon ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-30 22:50 ` Simon Marchi @ 2020-01-31 7:44 ` Eli Zaretskii 2020-01-31 16:48 ` Paul Smith 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2020-01-31 7:44 UTC (permalink / raw) To: Simon Marchi; +Cc: psmith, gdb > 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 :). > > > Sorry I can't be of more help, I'm probably as (or more) confused by the > situation as you are. Any reason why we don't use pkg-config for finding out these dependencies? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-31 7:44 ` Eli Zaretskii @ 2020-01-31 16:48 ` Paul Smith 2020-01-31 17:17 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Paul Smith @ 2020-01-31 16:48 UTC (permalink / raw) To: Eli Zaretskii, Simon Marchi; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-31 16:48 ` Paul Smith @ 2020-01-31 17:17 ` Eli Zaretskii 2020-01-31 17:23 ` Paul Smith 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2020-01-31 17:17 UTC (permalink / raw) To: psmith; +Cc: simark, gdb > From: Paul Smith <psmith@gnu.org> > Cc: gdb@sourceware.org > Date: Fri, 31 Jan 2020 11:48:49 -0500 > > > 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. Sorry, I thought liblzma needed -lrt. Apologies if I was confused. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-31 17:17 ` Eli Zaretskii @ 2020-01-31 17:23 ` Paul Smith 2020-02-01 3:05 ` Simon Marchi 0 siblings, 1 reply; 9+ messages in thread From: Paul Smith @ 2020-01-31 17:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: simark, gdb On Fri, 2020-01-31 at 19:17 +0200, Eli Zaretskii wrote: > > 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. > > Sorry, I thought liblzma needed -lrt. Apologies if I was confused. Oh I see the confusion. No, you're absolutely right, liblzma DOES need -lrt. And indeed, we DO use pkg-config to get info about liblzma. And that's why linking of gdb itself succeeds: it links lzma with its pkg-config options and that causes -lrt to be linked, as a side-effect. However, I'm whinging about gdbserver (and libinproctrace.so), and liblzma is not not linked into those, and so neither is -lrt. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB 8.3.1 gdbserver linker error: needs -lrt 2020-01-31 17:23 ` Paul Smith @ 2020-02-01 3:05 ` Simon Marchi 0 siblings, 0 replies; 9+ messages in thread From: Simon Marchi @ 2020-02-01 3:05 UTC (permalink / raw) To: psmith, Eli Zaretskii; +Cc: gdb On 2020-01-31 12:23 p.m., Paul Smith wrote: > On Fri, 2020-01-31 at 19:17 +0200, Eli Zaretskii wrote: >>> 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. >> >> Sorry, I thought liblzma needed -lrt. Apologies if I was confused. > > Oh I see the confusion. > > No, you're absolutely right, liblzma DOES need -lrt. And indeed, we DO > use pkg-config to get info about liblzma. > > And that's why linking of gdb itself succeeds: it links lzma with its > pkg-config options and that causes -lrt to be linked, as a side-effect. > > However, I'm whinging about gdbserver (and libinproctrace.so), and > liblzma is not not linked into those, and so neither is -lrt. I have tried to reproduce the build failure using a Docker container of Centos 6.10. I used the gcc 8 toolchain from softwarecollections.org, and didn't see the undefined reference to clock_gettime. This is despite the system running glibc 2.12, and the clock_gettime man page saying that -lrt is needed to use clock_gettime for glibc < 2.17. Anyway, I suppose adding this to gdbserver's configure.ac would help, could you try? AC_SEARCH_LIBS ([clock_gettime], [rt]) Simon ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-02-01 3:05 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-30 21:23 GDB 8.3.1 gdbserver linker error: needs -lrt 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 2020-01-31 17:17 ` Eli Zaretskii 2020-01-31 17:23 ` Paul Smith 2020-02-01 3:05 ` Simon Marchi
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).