Valgrind missing strlen in ld-linuxx86_64.so.2

[cassadio]

On Manjaro Unstable - valgrind does not work because strlen is missing in ld-linuxx86_64.so.2. Any advice would be helpful. TIA

[zbe]

ld-linuxx86_64.so.2 doesn’t exist. Post actual error with preformatted text: [HowTo] Post command output and file content as formatted text

[wolfseifert]

I have the same problem using Manjaro Unstable:

$ valgrind ls
==74681== Memcheck, a memory error detector
==74681== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==74681== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==74681== Command: ls
==74681== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

In the past this problem was caused by a version mismatch between Manjaro’s and Arch’s glibc version.

Therefore a upgrade

$ sudo downgrade glibc glibc-locales lib32-glibc

to a newer version helped.

But this time both use glibc 2.39-1.

[zbe]

@wolfseifert

But this time both use glibc 2.39-1.

Well, Manjaro builds its own glibc, so who knows. I installed arch one for fun and valgrind works with that.

If you’re interested in arch vs manjaro PKGBUILDs diff:

❯ diff glibc.manjaro glibc.arch
8d7
< # Manjaro: We keep the EAC way to still support older games
14c13
< pkgrel=1.1
---
> pkgrel=1
25d23
<         reenable_DT_HASH.patch
34,35c32
<         '214e995e84b342fe7b2a7704ce011b7c7fc74c2971f98eeb3b4e677b99c860addc0a7d91b8dc0f0b8be7537782ee331999e02ba48f4ccc1c331b60f27d715678'
<         '35e03ed912e1b0cd23783ab83ce919412885c141344905b8b67bbad4a86c48cf3e893806060e48d5737514ff80cea0b58b0e1f15707c32224579c416dcd810c0')
---
>         '214e995e84b342fe7b2a7704ce011b7c7fc74c2971f98eeb3b4e677b99c860addc0a7d91b8dc0f0b8be7537782ee331999e02ba48f4ccc1c331b60f27d715678')
43,46d39
<   # Re-enable `--hash-style=both` for building shared objects due to issues with EPIC's EAC
<   # which relies on DT_HASH to be present in these libs.
<   # reconsider 2023-01
<   patch -Np1 -i "${srcdir}"/reenable_DT_HASH.patch
53c46
<       --with-bugurl=https://gitlab.manjaro.org/packages/core/glibc/-/issues
---
>       --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/issues
143,147d135
<   _skip_test tst-resolv-aliases      resolv/Makefile
<   _skip_test tst-resolv-basic        resolv/Makefile
<   _skip_test tst-resolv-edns         resolv/Makefile
<   _skip_test tst-resolv-invalid-cname  resolv/Makefile
<   _skip_test tst-resolv-search       resolv/Makefile

[cassadio]

How would one go about installing glibc from the Arch repos? Really appreciate the help.

[wolfseifert]

According to this

How can I add archlinux repositories?

Wise decision When you choose to build packages from AUR you need to know that every time you update your Manjaro system - there is a chance that your AUR packages will need rebuild and therefore - when an AUR package acts weird after an update - rebuilding said package is often the solution. You cannot - and most importantly you should not as it will cause irreparable damage to your system files. Manjaro repos is drawn from Arch and synced several times a day from Arch stable. Except…

you cannot and you should not install glibc from Arch into Manjaro.

So you have to wait for some Manjaro folks to fix it and/or use a linux distro where valgrind works (e.g. Kubuntu 23.10) alternatively/temporarily.

[cassadio]

I think I may have a weird solution. If one were to grab the files from Arch repos and compile it, we’d technically have the .so file. Now what if we were to place the .so file in a specific location and add that as into the path for the current bash session? This is purely hypothetical but should not do any lasting damage to the system.

[zbe]

Why not take valgrind PKGBUILD and build that on your system? That should work. Arch glibc works at this moment. But when other packages get updated you’ll end with broken system.

[MrLavender]

@cassadio

How would one go about installing glibc from the Arch repos? Really appreciate the help.

Terrible idea. It might work right now but as @zbe says you will end up with a broken system in the not too distant future.

If valgrind is an essential daily requirement for you then unfortunately Manjaro is not the solution. Even on unstable branch it will break sometimes as you’ve seen, and the only way that will ever change is if Manjaro provides their own debuginfod server instead of using the Arch Linux one. Use Arch itself or some other distro that provides that - elfutils debuginfod services

[cassadio]

Do you mean take valgrind from the Manjaro repos and build it with debug symbols?

[zbe]

Huh? No. Valgrind is taken from Arch. Take their PKGBUILD and build it yourself.

[cassadio]

It is daily requirement for me, unfortunately I’ll have to finish the current phase of my work and then shift to Arch. I’m looking for a quick fix at the moment, installing another OS is fine but I’d have to set up everything from scratch. Thanks for your help.

[cassadio]

My bad, I meant glibc. Sorry about that.

[zbe]

Eh, nevermind. That won’t work. I’m not thinking straight.

[cassadio]

Found a workaround to the problem

1. Get glibc from the arch repos.
   (Arch Linux / Packaging / Packages / glibc · GitLab)
   That is, clone it and put it in a directory like Downloads, Documents etc
   git clone “Arch Linux / Packaging / Packages / glibc · GitLab”

2. Go to makepkg and edit the line options - add (!strip debug).
   Earlier the line would have looked like
   options=(staticlibs !lto)
   now after the edit
   options=(staticlibs !lto debug !strip)

3. Put in your locale to the locale.gen.txt file at the very end
   if US English - en_US.UTF-8 UTF-8

4. Now run makepkg --skipchecksums
   This should build the .so files and libraries.

5. The .so files should be built. At this point install patchelf from pacman
   sudo pacman -S patchelf.

6. Go to the target program for valgrind and run the following command

patchelf --set-interpreter /path/where/newly/compiled/ld-linux-x86-64.so/lives /path/of/target/executable

7. Valgrind should work

[cassadio]

I think I may have a temporary workaround that I just added in the thread.

[zbe]

Ok, but then you’re debugging whatever on a different library than your system actually runs on.

[cassadio]

True, it’s a temporary solution at best. Just thought I’d put it out there in case anyone was on the same situation as me.

Also, would it be possible to request the package maintainers to keep glibc with debug symbols? Do you think that’s a good idea?