Your message dated Sat, 17 Sep 2022 09:01:23 +0200 with message-id <[email protected]> and subject line Re: Bug#992796: dpkg-gensymbols should ignore version script tag symbols has caused the Debian Bug report #992796, regarding dpkg-gensymbols should ignore version script tag symbols to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 992796: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992796 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dpkg-dev Version: 1.20.9 Severity: normal GNU ld generates a nullptr absolute symbol for each version script tag. test.sym: LIBTEST_1 { }; clang -shared /dev/null -o example.so -Wl,--version-script=test.sym -fuse-ld=ld llvm-nm -D example.so: 0000000000000000 A LIBTEST_1@@LIBTEST_1 w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable w __cxa_finalize w __gmon_start__ LLVM's LLD (i.e. -fuse-ld=lld) does not. Many existing packages' symbols files however expect such symbols (e.g. systemd). This makes building them cleanly with LLD not possible. Rather than considering this a bug in LLD I think it would be more reasonable to fix this in dpkg because they're simply noise. 1. They are nullpointers and thus don't have any actual underlying implementation. 2. If they disappear, the whole section will have been deleted, so certainly other symbols will have also gone missing. I tried reading the binutils code for half an hour to understand where in the code and why they're being generated, but had no luck. Maintainers, does this seem reasonable? I would be willing to contribute a patch. -- Package-specific info: System tainted due to merged-usr-via-aliased-dirs. -- System Information: Debian Release: 11.0 APT prefers experimental APT policy: (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.10.0-8-amd64 (SMP w/32 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev depends on: ii binutils 2.37-4 ii bzip2 1.0.8-4 ii libdpkg-perl 1.20.9 ii make 4.3-4.1 ii patch 2.7.6-7 ii perl 5.32.1-5 ii tar 1.34+dfsg-1 ii xz-utils 5.2.5-2 Versions of packages dpkg-dev recommends: ii build-essential 12.9 ii build-essential-clang [build-essential 1:14.0.0+git20210821.d546c9aa1fc9-1 ii clang [c-compiler] 1:14.0.0+git20210821.d546c9aa1fc9-1 ii fakeroot 1.25.3-1.1 ii gcc [c-compiler] 4:10.2.1-1 ii gcc-10 [c-compiler] 10.2.1-6 ii gnupg 2.2.27-2 ii gpgv 2.2.27-2 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: pn debian-keyring <none> -- no debconf information
--- End Message ---
--- Begin Message ---Hi! On Sat, 2021-10-30 at 17:36:54 +0300, Raul Tambre wrote: > On 2021-09-10 06:10, Guillem Jover wrote: > > Before even considering applying something like this, the above would > > need to be clarified with GNU binutils maintainers. And either that > > deemed redundant (which I doubt) and to stop emitting them, or for LLD > > to start emitting them for compatibility with GNU ld and gold. > > I've now discussed this on the binutils mailing list > (<https://sourceware.org/pipermail/binutils/2021-October/thread.html#118179>). > It was guessed that this could likely be used for distinguishing whether a > library supports version XYZ symbols without knowing specific symbols from > that version. > > Thereafter I corresponded further with Fangrui and he declined adding > support for this feature to LLD due to the intent of the feature being > unclear. He also seemed hesitant in earlier emails as no real-world uses > have been found despite multiple notable distributions using LLD. > I have, with his permission, attached our full email thread. > > binutils maintainers since also declined to deprecate/remove this feature > (<https://sourceware.org/pipermail/binutils/2021-October/thread.html#118179>). > > Due to the absence of an upstream solution I see two possible paths forward: > 1. A patch for dpkg to ignore these > (<https://lists.debian.org/debian-dpkg/2021/08/msg00003.html>). > 2. A patch for LLD to match binutils's behaviour. > > Please let me know what you think of these options. Hmm, this situation is annoying, but I think as long as binutils does not deprecate/remove this, I'm going to be reluctant to do the same in dpkg. :/ My preference is still to get LLD to match binutils behavior TBH. With that, I think I'm going to be closing this report, but I'm happy to reconsider (and feel free to reopen) if the situation in upstream toolchains changes. Thanks, Guillem
--- End Message ---
