https://sourceware.org/bugzilla/show_bug.cgi?id=18064
Bug ID: 18064
Summary: objcopy, add-gnu-debuglink and "cannot fill debug link
section"
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: noloader at gmail dot com
I added a recipe called 'symbols' to my makefile to create a two part
executable. When I attempt to use objcopy to embed the debug information file
in the executable:
$ make symbols
objcopy --only-keep-debug cryptest.exe cryptest.exe.debug
strip --strip-debug --strip-unneeded cryptest.exe
objcopy --add-gnu-debuglink=/usr/lib/debug/cryptest.exe.debug cryptest.exe
objcopy:stOV5Ij1: cannot fill debug link section
`/usr/lib/debug/cryptest.exe.debug': No such file or directory
make: [symbols] Error 1
And:
objcopy --only-keep-debug libcryptopp.so libcryptopp.so.debug
strip --strip-debug --strip-unneeded libcryptopp.so
objcopy --add-gnu-debuglink=/usr/lib/debug/libcryptopp.so.debug
libcryptopp.so
objcopy:stLaJYWV: cannot fill debug link section
`/usr/lib/debug/libcryptopp.so.debug': No such file or directory
make: [symbols] Error 1
It seems objcopy requires the referenced path to exist in advance. The man
pages don't discuss the behavior, so I'm not sure if its expected or not. And I
was not able to locate an option to ignore non-existent paths.
This causes a problem in practice because I'm still the building software. And
when it comes time to install the software, `make install` MUST NOT build
anything (according to Stallman's GNU Make). Collectively, `make && sudo make
install` is effectively not working as expected.
I also build GDB and LLDB on occasion, so I try not depend on the GDB and
LLDB's built-in debug information directories being a correct. In fact, I'm not
sure GDB is configured correctly when using the distro's package. `show
debug-file-directory` is missing paths that the distro uses, like
`/usr/lib/debug/lib/x86_64-linux-gnu`.
*****
I think two or three things would be helpful. First, discuss the expected
behavior in the man pages under the --add-gnu-debuglink section.
Second, change the behavior of --add-gnu-debuglink to allow a reference to a
non-existent debug information file in anticipation of an install. This may be
undesirable for those who expect a failure to stop a script.
Third, add another option that provides an override to --add-gnu-debuglink's
existing behavior. That is, allow it to reference a non-existent debug
information file in anticipation of an install. This may be the best solution
moving forward even though the option will not be available to downlevel
versions of binutils.
Are there any other options?
*****
$ apt-cache showpkg binutils
Package: binutils
Versions:
2.24-5ubuntu3.1
(/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty-updates_main_binary-amd64_Packages)
(/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_trusty-security_main_binary-amd64_Packages)
(/var/lib/dpkg/status)
Description Language:
File:
/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty_main_binary-amd64_Packages
MD5: fde49b4cfeaad346a6e094f973da28d7
Description Language: en
File:
/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty_main_i18n_Translation-en
MD5: fde49b4cfeaad346a6e094f973da28d7
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
