Nordlöw
Nordlöw

Reputation: 12138

Cannot build GDB master Jul 9 2020 on Ubuntu 20.04

Trying to build gdb master (e79eb02f2f09baecffb144bac6804f975065466f from July 9, 2020) via

./configure && make -j4

errors during the final linking of gdb as

  CXXLD  gdb
init.c:215: error: undefined reference to '_initialize_ser_hard()'
init.c:236: error: undefined reference to '_initialize_tui_()'
init.c:244: error: undefined reference to '_initialize_array_vie()'
init.c:249: error: undefined reference to '_initialize_copy_bit()'
init.c:253: error: undefined reference to '_initialize_function_vie()'
init.c:263: error: undefined reference to '_initialize_rsp_lo()'
init.c:267: error: undefined reference to '_initialize_string_vie()'
init.c:287: error: undefined reference to '_initialize_break_catch_thro()'
init.c:297: error: undefined reference to '_initialize_corelo()'
init.c:307: error: undefined reference to '_initialize_d()'
init.c:309: error: undefined reference to '_initialize_d()'
init.c:311: error: undefined reference to '_initialize_d()'
init.c:312: error: undefined reference to '_initialize_d()'
init.c:323: error: undefined reference to '_initialize_frame_un()'
init.c:334: error: undefined reference to '_initialize_inflo()'
collect2: error: ld returned 1 exit status

Is this a known issue?

What's the problem?

Update

I've traced the error to gdb/init.c (generated by the build) that contains seemly truncated-from-the-end symbols. For instance, regarding the symbol _initialize_ser_hard used as

...
extern initialize_file_ftype _initialize_ser_hard;
...
void
initialize_all_files (void)
{
  ...
  _initialize_ser_hard ();
...

in gdb/init.c. But _initialize_ser_hard cannot be found in the rest of source tree. However the symbol _initialize_ser_hardwire is defined in the file gdb/ser-unix.c. I presume the same goes for the remaining missing symbols. So my conclusion is that generation of gdb/init.c is faulty.

Upvotes: 1

Views: 960

Answers (4)

Henrik Nordström
Henrik Nordström

Reputation: 11

Ran into the same issue with _initialize_ser_hard trying to build gdb-10.1 on Fedora, and it's a locale issue.

The culpit is this sed statement in gdb/Makefile

@-for f in $(INIT_FILES); do \
    sed -n -e 's/^_initialize_\([a-z_0-9A-Z]*\).*/\1/p' \
        $(srcdir)/$$f 2>/dev/null; \

this assumes a-z expands to all ASCII characters between a and z, but at least sv_SE.UTF-8 and maybe Danish and some other languages do not include w in the above pattern, and _initialize_ser_hardwire becomes ser_hard instead of the expected ser_hardwire.

Adding a LC_COLLATE=C guard on the sed command gives the expected result.

I do not know if this is expected or correct, but I do know that the status of w in the Swedish language have a twisted history and was not an official character until quite recently, and is often sorted the same as v making no distinction between v and w.

Upvotes: 1

Christian Joensson
Christian Joensson

Reputation: 11

Well, me too, FWIW.

On fedora 32 x86_64.

I do notice that in the genrated gdb/Makefile, I get a warning "Sucpisious line 593", in my case, saving in emacs. This is the section of Makefile, and the last line is the empty or tabbed only line 593:

INTERNAL_CPPFLAGS = $(CPPFLAGS) - I/usr/include/guile/2.0 -pthread -I/usr/include/\python3.8 -I/usr/include/python3.8 \

Notice the continuation ""

Upvotes: 1

V-R
V-R

Reputation: 1401

I've checked it as follows and found no such inherent problem with GDB master on Ubuntu 20.04, so it must be system-specific, as the other answer suggested.

First I've checked it with today's latest GDB master (2020-08-04):

$ docker run -ti ubuntu:20.04
...
# apt-get update && apt-get install bison flex binutils git make g++ texinfo
...
# git clone git://sourceware.org/git/binutils-gdb.git
...
# cd binutils-gdb
# mkdir build && cd build
# CC=gcc ../configure
...
# make -j4
... ... ... ...
# gdb/gdb --version
GNU gdb (GDB) 10.0.50.20200804-git
...

Then found the latest commit id from Jul 9 2020 and it worked too:

# cd ..
# git checkout f37e5866aa72e76f2199155fb838ffc25c78a26e
...
# mkdir build-20200709 && cd build-20200709
# CC=gcc ../configure
...
# make -j4
... ... ... ...
# gdb/gdb --version
GNU gdb (GDB) 10.0.50.20200709-git
...

... Then noticed that you mentioned the actual commit id, and it worked too:

# cd ..
# git checkout e79eb02f2f09baecffb144bac6804f975065466f
...
# mkdir build-e79eb02f2f09baecffb144bac6804f975065466f
# cd build-e79eb02f2f09baecffb144bac6804f975065466f
# CC=gcc ../configure
...
# make -j4
... ... ... ...
# gdb/gdb --version
GNU gdb (GDB) 10.0.50.20200725-git
...

Upvotes: 1

Employed Russian
Employed Russian

Reputation: 213935

What's the problem?

There is no _initialize_break_catch_thro() anywhere in GDB, but there is _initialize_break_catch_throw() here.

It looks like you have a corrupt .o file somewhere, which somehow got a lot of functions missing their last character.

I have no idea how this could happen, but removing the entire build directory and doing a fresh rebuild would be my first step.

Update:

LD=ld.bfd ./configure
Now I get the build error

The build error you got could not possibly come from using a different linker.

Either your system is sick in some way (I would fsck all the disks and reboot), or you are omitting some relevant info and/or making other changes.

Upvotes: 0

Related Questions