FS#69567 - [binutils] missing libctf.so.0

Attached to Project: Arch Linux
Opened by sailslack (sailslack) - Saturday, 06 February 2021, 15:55 GMT
Last edited by Allan McRae (Allan) - Friday, 19 February 2021, 03:50 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 30
Private No


The last update of binutils 2.36.3 is lacking of libctf.so.0 (a symlink to libctf.so.0.0.0 which is missing too) that should be placed under /usr/lib. This makes impossible to download programs into the Arduino board with the "connect" function of the Arduino IDE that complains about the missing library. All the 2.36.x versions in the archive are unusable as the only previous version where libctf.so.0 is present (2.36.1-1) raises the error reported (and solved with the 2.36-2 version of binutils) in  FS#69529 .
The last usable version of binutils with Arduino IDE is 2.35.1-1.

Additional info:
Arduino IDE 1.18.13
binutils 2.36.x

Steps to reproduce:
From the Arduino IDE (1.18.13) and press connect icon
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 19 February 2021, 03:50 GMT
Reason for closing:  Upstream
Comment by Rémi Berthoz (remiberthoz) - Saturday, 06 February 2021, 16:35 GMT
I'm facing the same issue when using avr-gcc (10.2.0-1) to compile for Arduino. I have version 2.36-3 of binutils. To reproduce the bug described here one can simply try to compile an empty file with avr-gcc.
Comment by Arne Wörner (riddicc) - Saturday, 06 February 2021, 17:35 GMT
same here, but when linking something for an ATtiny84 with avr-ld.
workaround: downgrade to binutils-2.35-2-x86_64 and ignore binutils, when upgrading with pacman.
Comment by Damián Barberón (damian01w) - Sunday, 07 February 2021, 13:49 GMT
Same here.
avr-ld: error while loading shared libraries: libctf.so.0: cannot open shared object file: No such file or directory

* avr-binutils 2.35.1-1
* binutils 2.36-3
Comment by Allan McRae (Allan) - Sunday, 07 February 2021, 14:08 GMT Comment by Mik (aleextra) - Sunday, 07 February 2021, 15:19 GMT
same to me. I don't have the previous packages, I cannot downgrade :( How that can be fixed?
Comment by sailslack (sailslack) - Sunday, 07 February 2021, 15:38 GMT
Mik you may want to check at https://archive.archlinux.org/packages/ where you can find all the previous version of packages.
For my system using binutils 2.35.1-1 or 2.35.2 as Arne said, will do. Don't forget to add IgnorePkg=binutils in /etc/pacman.conf
Comment by Kevin Morris (kevr) - Sunday, 07 February 2021, 20:19 GMT
`same to me. I don't have the previous packages, I cannot downgrade :( How that can be fixed?`

aleextra, you can build through a repo fetched with the `asp` tool.

Personally, I ran `asp checkout avr-binutils`, then I checked out avr-binutils to the following commit:

commit 41cab1afc826c22d5e1049f1bb60ab9e9b714f7e (HEAD)
Author: anatolik <anatolik@9fca08f4-af9d-4005-b8df-a31f2cc04f65>
Date: Sun Oct 13 20:12:24 2019 +0000

upgpkg: avr-binutils 2.33.1-1

git-svn-id: file:///srv/repos/svn-community/svn@515328 9fca08f4-af9d-4005-b8df-a31f2cc04f65

After checking out to a previous commit, I proceed to building the package inside of the `trunk` directory.

`cd trunk && makepkg -sci`

Full process:

$ asp checkout avr-binutils
$ cd avr-binutils
$ git checkout 41cab1afc826c22d5e1049f1bb60ab9e9b714f7e
$ cd trunk
$ makepkg -sci

You can use the same process with any Arch Linux package hosted in their standard repositories, like `binutils`.
Comment by J. A. Dirks (smallAndSimple) - Tuesday, 09 February 2021, 10:15 GMT
Note that this also breaks `arm-linux-gnueabihf`, which is only an AUR package, but still.
Comment by B.T. (bebenlebricolo) - Wednesday, 10 February 2021, 14:55 GMT
Hi all, I stumbled upon the same issue and found that libctf* and related includes are removed from the package right after building succeeds.
This was implemented in [this commit](https://github.com/archlinux/svntogit-community/commit/3915bd823d782d42a0813d1d03deecdfb165a8a5#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a).
I don't know the reasons behind this choice, but I'd suppose it was done like this to prevent conflicts between files ?

On my side I've done the following :
1. clone the [svntogit-community repo](https://github.com/archlinux/svntogit-community)
$ git clone https://github.com/archlinux/svntogit-community
2. Checkedout the `packages/avr-binutils` branch
$ git checkout packages/avr-binutils
3. Changed directory to "trunk" and opened up PKGBUILD
$ cd trunk
$ <editor> PKGBUILD
4. Went to [gnu ftp host page for binutils](https://ftp.gnu.org/gnu/binutils/)
5. Downloaded the binutils-2.36.1.tar.bz2 (or any other of them)
6. Computed the sha1sum for this particular package
$ sha1sum <archive file>
7. Copied the sha1sum in place of the first key of sha1sums=( on line 19 of PKGBUILD (to check package when download is finished)
8. Changed the pkgver variable to 2.36.1 (in my case)
9. (Added the 13F... gpg finger print)
$ gpg --recv-keys 13F....
10. Commented out the lines 85 and 86
# rm -r "${pkgdir}"/usr/lib/libctf*
# rm -r "${pkgdir}"/usr/include/{ctf.h,ctf-api.h}
11. Ran makepkg and hopefully everything builds fine (!)

When the build was finished, could verify that libs were there (find -name libctf* -type f) in the pkg/ folder.
Then with :
export LD_LIBRARY_PATH=<svntogit-community/trunk/pkg/avr-binutils/usr/lib>:<svntogit-community/trunk/pkg/avr-binutils/usr/x86_64-pc-linux-gnu/avr/lib>
(e.g. export LD_LIBRARY_PATH=../lib:../x86_64-pc-linux-gnu/avr/lib for me)
and `ldd svntogit-community/trunk/pkg/avr-binutils/usr/bin/avr-ld` shows that all shared libraries are found by avr-ld

I did the trick for me, I don't know if this will be compatible with the package development, there might be a reason I'm missing.
Comment by Joel Elkins (joelelkins) - Wednesday, 10 February 2021, 16:35 GMT
@bebeniebricolo You could just use asp for the checkout steps...

$ asp update avr-binutils
$ asp export avr-binutils
$ cd avr-binutils
$ <editor> PKGBUILD
<delete lines>
$ makepkg -s
Comment by Kevin Morris (kevr) - Saturday, 13 February 2021, 03:05 GMT
Seeing as this breaks various other packages, why has this not been reverted to a safe state yet? It has been nearly a week.
Comment by Allan McRae (Allan) - Saturday, 13 February 2021, 04:07 GMT
The binutils package is not being downgraded as that causes other problems. The libctf shared library can only be added to the latest package by removing some security CFLAGS/LDFLAGS from the build, which has been denied. Waiting on upstream to fix the linking.


In addition, libctf has a known unstable ABI and will be bumped to .so.1 when it is done. I'm surprised anything is linking to the shared version and not the static one...
Comment by Kevin Morris (kevr) - Saturday, 13 February 2021, 04:26 GMT
Thank you for the clarification, Allan. In particular, the package that I'm running into issues with regarding this is `avr-binutils`, in the `avr-ld` tool.

What worries me a bit more than upstream messing up is: how does this not get caught when the packages are being updated? I do understand that now that we're at this state, people do not want to downgrade because that cascades over to a ton of packages that have been through a testing stage, however... the initial upgrades introduced this bug. Is it a case of "most people don't use tool x, so we're not going to cater to the 1% that do"?

Frankly, if I cannot depend on Arch packages to work, I cannot rely on Arch Linux for serious machines. I'd prefer to, because I love Arch's train of thought (and its community). This whole thing makes me wonder what the true goals of maintainership on the distro are.
Comment by Allan McRae (Allan) - Saturday, 13 February 2021, 06:32 GMT
This did not get caught because no-one spotted it early enough. That is the problem with issues that affect 1% of users.

Welcome to the joys of a bleeding edge rolling release distro. Sometimes you bleed... You can either downgrade using the archive mirrors to the day before this happened, wait for the fix, or use another distro. Up to you - no-one else really cares.
Comment by Kevin Morris (kevr) - Saturday, 13 February 2021, 07:14 GMT
Fair enough. Later.
Comment by Allan McRae (Allan) - Friday, 19 February 2021, 03:50 GMT
Security team won't let me build it without the problem CFLAGS/LDFLAGS, so this can only be fixed upstream. Closing as not my problem.