Arch Linux

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.

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.

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

https://sourceware.org/bugzilla/show_bug.cgi?id=27360

same to me. I don't have the previous packages, I cannot downgrade :( How that can be fixed?

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

`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`.

Note that this also breaks `arm-linux-gnueabihf`, which is only an AUR package, but still.

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.

@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

Seeing as this breaks various other packages, why has this not been reverted to a safe state yet? It has been nearly a week.

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.

https://sourceware.org/bugzilla/show_bug.cgi?id=27360

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...

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.

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.

Fair enough. Later.

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.