GDB 8.3.1 gdbserver linker error: needs -lrt

GDB 8.3.1 gdbserver linker error: needs -lrt

[Paul Smith]

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...

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Simon Marchi]

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

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Paul Smith]

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!

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Simon Marchi]

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

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Eli Zaretskii]

> 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?

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Paul Smith]

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.

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Eli Zaretskii]

> 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.

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Paul Smith]

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.

Re: GDB 8.3.1 gdbserver linker error: needs -lrt

[Simon Marchi]

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