11

I'm building a c++ project with GNU toolchain/gcc 4.9 on a new platform (debian stretch on a jetson K1 evalboard). The linker gives lots of messages like

usr/bin/ld: ../../../../lib/libsomething.so: invalid string offset 3118 >= 2767 for section `.strtab'

I don't even know whether this is an error, a warning or just some linker smalltalk. The project builds and runs, but this confuses me.

I've already built this project on a couple of ARM and intel platforms, with the same toolchain (but on Ubuntu or Debian Jessie), and never seen this stuff.

I've seen suggestions this could be related to parallel builds with make -j, but this also happens if I rebuild all libs without -j.

Please give me a hint what this is and how I can get rid of it.

Update:

  • The said libraries are compiled within the same project with the same toolchain
  • objdump doesn't list the .strtab section at all
Philippos
  • 284
  • 2
  • 14
  • Where does `../../../../lib/libsomething.so` come from? – Andrew Henle Aug 14 '17 at 09:22
  • Wild guess: your strtab section is to small for the data that are loaded into it. An embedded platform with hard memory constraints may by default be configured this way to ensure some remaining memory areas for the stack and other data. – grek40 Aug 14 '17 at 09:25
  • @AndrewHenle: `libsomething` and seven other libs are build within the project with the same toolchain. Each of them gives the linker message seven times with different offset values. – Philippos Aug 14 '17 at 11:44
  • @grek40: The board has 2 GB of RAM, more than enough for that project. And I didn't see the messages when compiling the project on a different platform with the same toolchain. Main difference: Now I'm on debian stretch instead of ubuntu or debian jessie. – Philippos Aug 14 '17 at 11:50
  • @Philippos *Main difference: Now I'm on debian stretch instead of ubuntu or debian jessie.* That's the kind of information that needs to be in the question from the very beginning. – Andrew Henle Aug 14 '17 at 12:06
  • I updated the question with all new findings. – Philippos Aug 16 '17 at 15:33
  • Is this a precompiled .SO or are you building it with the project? if they are built within the project can you check if its rebuilding them or actually linking against old ones? Can you manually clean those locations and rebuild? – Samer Tufail Aug 18 '17 at 15:25
  • @SamerTufail "*The said libraries are compiled within the same project with the same toolchain*". Their names are unique and can't be confused with system libraries. And I got the same messages after rebuilding from a clean build. The libs themselves are build without warnings, those messages come later when linking to those libs. – Philippos Aug 18 '17 at 15:30
  • Can you try setting the '--nmagic' flag in the ld to prevent it from page aligning to a wierd page size? – Samer Tufail Aug 18 '17 at 18:21

1 Answers1

0

There was a bug in ld.bfd prior to Binutils 2.33.

It tried to read ARM CMSE symbol names, but used .strtab instead of .dynstr. If symbols are stripped in a shared library, its .strtab section is shorter than .dynstr, so for some symbols in .dynsym, the offsets of their names (which actually reference .dynstr) exceed the size of .strtab. Thus, the linker issued the warning.

Here is the patch that fixed the issue if you need more details: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=baf46cd78048e1b959462567556e1de1ef6b9039.

Igor Kudrin
  • 16
  • 3
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/late-answers/30979438) – Ivan Feb 07 '22 at 14:55
  • This answer has nothing relevant to the question asked. – Chintan Pathak Apr 12 '22 at 00:01
  • 1
    OK, I've added some details. @ChintanPathak, do you have a better answer for the question? – Igor Kudrin Apr 13 '22 at 12:01
  • @IgorKudrin Thank you for the additional context in your answer. I came here looking for the answer. :) – Chintan Pathak Apr 13 '22 at 20:57
  • 1
    @ChintanPathak, so, what is the version of `ld` you use that issues the warning? Have you tried a more recent version? – Igor Kudrin Apr 14 '22 at 14:16
  • @IgorKudrin: Not sure if I found exactly what you asked for, but `ldd --version | head -n1 | cut -d" " -f2- # glibc version` gives me - `(Debian GLIBC 2.28-10+rpt2+rpi1) 2.28`. I am using Raspberry Pi 4 with `armv7l`. https://www.reddit.com/r/linux4noobs/comments/otsgxg/how_do_i_update_glibc_in_ubuntu/ says to not update glibc. How can I go about updating ld otherwise? – Chintan Pathak Apr 15 '22 at 00:20
  • 1
    @ChintanPathak, I mean `ld` (linker), not `ldd` (a utility that prints dependencies). But based on the version of `ldd`, I'd guess that `ld` is also not fresh enough on your system. If you cannot update the linker, or rebuild it manually with the patch applied, you may just ignore the warning, that is safe. – Igor Kudrin Apr 15 '22 at 09:23