Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 390323 - dev-util/valgrind-3.7.0: fails to run because of undefined strlen
Summary: dev-util/valgrind-3.7.0: fails to run because of undefined strlen
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: x86 Linux
: Normal major with 7 votes (vote)
Assignee: Anthony Basile
URL: https://bugs.kde.org/show_bug.cgi?id=...
Whiteboard:
Keywords:
: 214065 274771 413603 431970 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-12 23:03 UTC by Jean-Francois Ostiguy
Modified: 2020-05-16 01:26 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Francois Ostiguy 2011-11-12 23:03:20 UTC
Valgrind 3.7.0 emerges but fails to run. Downgrading to 3.6.1, makes the problem go away.

Output for valgrind ls with version 3.7.0

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

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.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux.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:  Cannot continue -- exiting now.  Sorry.





   

Reproducible: Always
Comment 1 Jean-Francois Ostiguy 2011-11-12 23:04:33 UTC
emerge --info
Portage 2.1.10.34 (default/linux/x86/10.0/developer, gcc-4.5.3, glibc-2.13-r4, 3.1.0-gentoo i686)
=================================================================
System uname: Linux-3.1.0-gentoo-i686-Intel-R-_Pentium-R-_4_CPU_3.20GHz-with-gentoo-2.1
Timestamp of tree: Sat, 12 Nov 2011 12:30:01 +0000
app-shells/bash:          4.2_p10
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.6.7-r2, 2.7.2-r3, 3.2.2
dev-util/cmake:           2.8.6-r3
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.1
sys-apps/openrc:          0.9.4
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.9.6-r3, 1.10.3, 1.11.1-r1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            3.4.6-r2, 4.2.4-r1, 4.3.6-r1, 4.4.6-r1, 4.5.3-r1, 4.6.2
sys-devel/gcc-config:     1.5-r2
sys-devel/libtool:        2.4-r4
sys-devel/make:           3.82-r3
sys-kernel/linux-headers: 2.6.39 (virtual/os-headers)
sys-libs/glibc:           2.13-r4
Repositories: gentoo kde-sunset sunrise sage-on-gentoo local-repo mingw32-repo
ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="*"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles multilib-strict news parallel-fetch protect-owned sandbox sfperms sign splitdebug strict test-fail-continue unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox"
FFLAGS=""
GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ ftp://ftp.gtlib.gatech.edu/pub/gentoo http://www.gtlib.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.chem.wisc.edu/gentoo/ "
LANG="en_US.UTF-8"
LDFLAGS="-Wl,--as-needed"
LINGUAS="en en_US fr"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/kde-sunset /var/lib/layman/sunrise /var/lib/layman/sage-on-gentoo /usr/local/portage /usr/i686-mingw32/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa apache2 berkdb bluetooth bzip2 cairo cdda cdr cleartype cli consolekit corefonts cpdflib cracklib crypt cups cxx dbus doc dri dts dv dvd dvdr emboss encode exif fam firefox flac fortran gcj gd-external gdbm gdu gif gnomedb gpm gtk iconv ieee1394 ipv6 java jpeg kde kdehiddenvisibility lcms ldap libnotify lm_sensors mad maildir mbox mmx mng modules mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pango pcre pdf php png policykit ppds pppd private-headers qt3support qt4 readline scanner sdl semantic-desktop session snmp spell sqlite sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype type1 type3 udev unicode usb vorbis wicd x264 x86 xcb xml xmlrpc xorg xulrunner xv xvid zlib" ALSA_CARDS="intel8x0 usb-audio" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev keyboard mouse virtualbox" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US fr" NETBEANS_MODULES="apisupport harness ide java nb gsf php websvccommon webcommon" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" SANE_BACKENDS="umax" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev virtualbox" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Comment 2 Rafał Mużyło 2011-11-13 05:09:15 UTC
Chances it's in one way or the other a dupe of bug 274771:
most likely you need glibc with FEATURES containing "splitdebug".
Comment 3 Jean-Francois Ostiguy 2011-11-13 13:17:21 UTC
In response to comment no 2:

FEATURES=splitdebug is enabled for glibc at the package level. This does not seem to help. Again 3.6.1 works just fine.
Comment 4 Jean-Francois Ostiguy 2011-11-13 16:57:25 UTC
A few more pieces of information:

Here is what I get when I search for the symbol strlen in the debug info:

# nm /usr/lib/debug/lib/ld-2.13.so.debug | grep str
0001796d t __strerror_r
00019260 t __strnlen
00017ad0 t __strsep
00017ad0 t __strsep_g
00017758 t __strtoul_internal
0001eec8 d capstr
0001d280 r errstring.9206
000084ab t expand_dynamic_string_token
000059fa t local_strdup
0001eec4 d max_capstrlen
0001eec0 d ncapstr
000190f0 t strchr
00019260 t strnlen
00017ad0 t strsep

Note that although "strnlen" is present, "strlen" is not.   
Sure enough, according to the gcc docs, strlen is one of the functions 
that may be optimized out (an equivalent built-in version is used). 

http://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/Other-Builtins.html#Other-Builtins

If a function is optimized out, there will be no external symbol. I tried to disable the optimization by passing -fno-builtin-strlen in CFLAGS, but this does not seem to work. Perhaps the ebuild ignores or removes some custom CFLAGS.  

Here is my custom config for glibc

cat  /etc/portage/env/sys-libs/glibc 

FEATURES="${FEATURES} splitdebug"
CFLAGS="${CFLAGS} -fno-builtin-strlen -g"
CXXFLAGS="${CFLAGS}"

Apparently, for x86, the presence of debug info for strlen was not strictly necessary in versions < 3.7.0 even though it was for other platforms (e.g.
x86_64).
Comment 5 Jean-Francois Ostiguy 2011-11-14 15:48:15 UTC
I have access to another gentoo box, this one running on x86_64
rather than x86. The gcc and glibc are the same versions as on the x86
box. Interestingly, I see that strlen has not been optimized out and 
valgrind 3.7.0 works as expected. 

The CFLAGS for the x86_64 box are 

CFLAGS="-march=core2 -O2 -pipe -fno-strict-aliasing"

so it would seem that the optimization is less "aggressive".  

nm /usr/lib/debug/lib64/ld-2.13.so.debug | grep str
0000000000014bb0 t __strerror_r
00000000000162d0 t __strnlen
0000000000014fe0 t __strsep
0000000000014fe0 t __strsep_g
0000000000014e00 t __strtoul_internal
000000000021fdd0 d capstr
000000000001c720 r errstring.10674
00000000000071c0 t expand_dynamic_string_token
0000000000004ce0 t local_strdup
000000000021fdc8 d max_capstrlen
000000000021fdc0 d ncapstr
0000000000016130 t strchr
00000000000161b0 t strcmp
00000000000161e0 t strlen
00000000000162d0 t strnlen
0000000000014fe0 t strsep
Comment 6 Anthony Basile gentoo-dev 2011-11-15 01:17:38 UTC
 
> Sure enough, according to the gcc docs, strlen is one of the functions 
> that may be optimized out (an equivalent built-in version is used). 
> 

Nasty!  Thanks for doing the leg work on this.  I haven't checked, but off the top of my head, does -O0 or -O1 fix this by not optimizing out strlen?
Comment 7 Jean-Francois Ostiguy 2011-11-16 04:07:33 UTC
(In reply to comment #6)
> > Sure enough, according to the gcc docs, strlen is one of the functions 
> > that may be optimized out (an equivalent built-in version is used). 
> > 
> 
> Nasty!  Thanks for doing the leg work on this.  I haven't checked, but off the
> top of my head, does -O0 or -O1 fix this by not optimizing out strlen?

I tried with just -O0 as  optimization flag (removed -march=native). No change,
strlen remains absent and valgrind does not work. 

That said, glibc has to be the most heavily called library ! ... so even if  -O0 or -O1 "fixed" the issue, this would not really bean acceptable solution. 

Ideally, I think the glibc build procedure should be modified so that ld.so (but perhaps not libc itself) gets compiled with the the -fno-builtin-strlen flag enabled. It looks like the CFLAGS actually passed to the glibc build are heavily filtered. It is not even clear to me that -O1 is getting honoured.  
I have not managed to determine where the filtering occurs, so I am not sure
how to proceed to try a fix based on -fno-builtin-strlen.
Comment 8 Anthony Basile gentoo-dev 2011-11-17 12:51:51 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > > Sure enough, according to the gcc docs, strlen is one of the functions 
> > > that may be optimized out (an equivalent built-in version is used). 
> > > 
> > 
> > Nasty!  Thanks for doing the leg work on this.  I haven't checked, but off the
> > top of my head, does -O0 or -O1 fix this by not optimizing out strlen?
> 
> I tried with just -O0 as  optimization flag (removed -march=native). No change,
> strlen remains absent and valgrind does not work. 
> 
> That said, glibc has to be the most heavily called library ! ... so even if 
> -O0 or -O1 "fixed" the issue, this would not really bean acceptable solution. 
> 
> Ideally, I think the glibc build procedure should be modified so that ld.so
> (but perhaps not libc itself) gets compiled with the the -fno-builtin-strlen
> flag enabled. It looks like the CFLAGS actually passed to the glibc build are
> heavily filtered. It is not even clear to me that -O1 is getting honoured.  
> I have not managed to determine where the filtering occurs, so I am not sure
> how to proceed to try a fix based on -fno-builtin-strlen.

We'd need some USE flag on glibc to do that.  When I have time I'll test to see if compiling glibc with -fno-builtin-strlen resolves the problem before asking the toolchain people do consider that option.
Comment 9 SpanKY gentoo-dev 2011-11-17 21:31:36 UTC
sounds like an issue valgrind peeps need to resolve.  this is going to hit every distro, not just Gentoo.
Comment 10 David Hallas 2011-11-25 09:53:12 UTC
It looks like it has been reported upstream: https://bugs.kde.org/show_bug.cgi?id=286864
Comment 11 Hubert Kowalski 2011-12-02 18:03:01 UTC
I am hitting this problem HARD. Currently, the only way for me to be able to work with Valgrind is to edit glibc ebuild to use flag "-fno-builtin-strlen". I wonder if this can be enabled in glibc ebuild as a flag (like "fix_for_valgrind_mess")
Comment 12 SpanKY gentoo-dev 2011-12-02 18:59:11 UTC
there's no need to edit the ebuild.  do something like this:
  # mkdir -p /etc/portage/env/sys-libs
  # echo 'CFLAGS+=" -fno-builtin-strlen"' > /etc/portage/env/sys-libs/glibc
Comment 13 Jean-Francois Ostiguy 2011-12-03 19:32:09 UTC
In response to (12)

In my original report, I mentioned I tried something more or less 
like what you are suggesting and that it did not work. Either 
portage or the glibc build system strips the -fno-builtin-strlen 
flag. For the form, I just tried emerging glibc again, with the 
exact syntax you suggest, in /etc/portage/env/sys-libs/glibc. 
It does not work.
Comment 14 Hubert Kowalski 2011-12-03 22:02:35 UTC
What You have to do is:

edit /usr/portage/sys-libs/glibc/files/eblits/common.eblit
find line saying "append-flags -O2 -fno-strict-aliasing" and change it to "append-flags -O2 -fno-strict-aliasing -fno-builtin-strlen"

Then update manifest for ebuild of specific glibc You want to install, install glibc and it's ready to use for valgrind.

Also, when reading comments above this line, You'll see why glibc filters out your -O0 or -O1

That said - this needs to be controlled either by useflag on glibc part, or upstream should do something about their bug https://bugs.kde.org/show_bug.cgi?id=286864
Comment 15 Hubert Kowalski 2011-12-03 22:07:46 UTC
(In reply to comment #12)
> there's no need to edit the ebuild.  do something like this:
>   # mkdir -p /etc/portage/env/sys-libs
>   # echo 'CFLAGS+=" -fno-builtin-strlen"' > /etc/portage/env/sys-libs/glibc

It won't work, as I found out later - after much digging I found out that EVERY flag possible is stripped and only specific ones are applied.

Summing up my comment #14 - either upstream fix, or useflag in glibc ebuild should be implemented.
Comment 16 Anthony Basile gentoo-dev 2011-12-03 22:35:29 UTC
(In reply to comment #15)
> (In reply to comment #12)
> > there's no need to edit the ebuild.  do something like this:
> >   # mkdir -p /etc/portage/env/sys-libs
> >   # echo 'CFLAGS+=" -fno-builtin-strlen"' > /etc/portage/env/sys-libs/glibc
> 
> It won't work, as I found out later - after much digging I found out that EVERY
> flag possible is stripped and only specific ones are applied.
> 
> Summing up my comment #14 - either upstream fix, or useflag in glibc ebuild
> should be implemented.

Or use 3.6.1 which is known stable until upstream resolves the issue.  Asking the toolchain folks to add a USE flag on glibc to accomodate one ~arch package where a known stable version exists is excessive.  With this bug hitting all the distros, upstream will have to act sooner or later if they want 3.7.0 to every get used.
Comment 17 Jean-Francois Ostiguy 2011-12-04 02:44:07 UTC
Sure, I can use 3.6.1 for now. BTW, emerge fails for valgrind-3.6.1 on recent 
3.X kernels because of this bug 

http://bugs.kde.org/show_bug.cgi?id=275278

so an updated ebuild would be useful.
Comment 18 Anthony Basile gentoo-dev 2011-12-04 18:32:35 UTC
(In reply to comment #17)
> Sure, I can use 3.6.1 for now. BTW, emerge fails for valgrind-3.6.1 on recent 
> 3.X kernels because of this bug 
> 
> http://bugs.kde.org/show_bug.cgi?id=275278
> 
> so an updated ebuild would be useful.

Both valgrind-3.6.1-r1 and valgrind-3.6.1-r2 have the r11796 svn patch and build against linux 3.* kernels.  They were added on Oct 24 and 27th.
Comment 19 Jean-Francois Ostiguy 2011-12-05 01:23:38 UTC
(In reply to comment #18)

> Both valgrind-3.6.1-r1 and valgrind-3.6.1-r2 have the r11796 svn patch and
> build against linux 3.* kernels.  They were added on Oct 24 and 27th.

You are correct. My mask meant to block 4.0 was inadvertently blocking 3.6.1-r1 and r2.
Comment 20 J.C. Wren 2012-01-19 05:03:57 UTC
Maybe I'm doing something wrong, but I've recompiled glibc-2.14.1-r2 with /etc/portage/env/sys-libs/glibc containing

CFLAGS+=" -fno-builtin-strlen"
FEATURES="${FEATURES} splitdebug"

along with recompiling valgrind 3.7.0-r2 (shouldn't be necessary), AND recompiling my application, and STILL get the error message.

I had also tried this with the FEATURES="${FEATURES} splitdebug" in /etc/make.conf, still no joy.

Advice? Any way to confirm the options glibc was built with?
Comment 21 Anthony Basile gentoo-dev 2012-01-19 12:03:22 UTC
(In reply to comment #20)
> Maybe I'm doing something wrong, but I've recompiled glibc-2.14.1-r2 with
> /etc/portage/env/sys-libs/glibc containing
> 
> CFLAGS+=" -fno-builtin-strlen"
> FEATURES="${FEATURES} splitdebug"
> 
> along with recompiling valgrind 3.7.0-r2 (shouldn't be necessary), AND
> recompiling my application, and STILL get the error message.
> 
> I had also tried this with the FEATURES="${FEATURES} splitdebug" in
> /etc/make.conf, still no joy.
> 
> Advice? Any way to confirm the options glibc was built with?

This doesn't work because of comment #15.  If you really want -fno-builtin-strlen in there, then you have to follow comment #14.  I'm not asking toolchain to add this since upstream should fix the issue and they are aware.  You can dump the symbols to see if strlen is in there --- read through the entire bug for examples.

BTW, if you do and it works for you, please comment back to this bug.  Also, tell us if you set -march, -mcpu or -mtune to any particular value.
Comment 22 J.C. Wren 2012-01-19 14:35:19 UTC
After emerging glibc-2.14.1-r2 the configuration described in #20

# ls -l /lib/libc*
-rwxr-xr-x 1 root root 1392676 Jan 18 18:27 /lib/libc-2.14.1.so
lrwxrwxrwx 1 root root      14 Jan 18 18:27 /lib/libc.so.6 -> libc-2.14.1.so
# ls -l /usr/lib/debug/lib/libc-*
-rw-r--r-- 1 root root 252374 Jan 18 18:27 /usr/lib/debug/lib/libc-2.14.1.so.debug
# nm /usr/lib/debug/lib/libc-2.14.1.so.debug | grep strl
00073560 t __GI_strlen
00075268 t __m128i_strloadu_tolower.clone.1
0007851d T __strlen_g
00073560 t __strlen_ia32
000793e0 t __strlen_sse2
000796c0 t __strlen_sse2_bsf
00073510 i strlen
#

The 'i' says this is an indirect function, although I'm not clear what that means. Checking 'strcpy' just for comparison, I see it's a 'T', which says there is code in the text section. Check for other 'i' functions, it seems that bcmp, bcopy, bzero, memcmp, memcpy, memmove, mempcpy, memset, strcasestr, strcmp, strcspn, strncmp, strpbrk, strspn and strstr are also indirects.

For the compiler flags, I'm running

  CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"

Normally I run -march=pentium4

I'll try the comment #14 patch a little later today.
Comment 23 J.C. Wren 2012-01-20 02:38:07 UTC
Following the Comment #14 instructions seem to do the trick. I left all the other parameters the same, modifying only the /usr/portage/sys-libs/glibc/files/eblits/common.eblit file.
Comment 24 Anthony Basile gentoo-dev 2012-01-20 12:33:54 UTC
(In reply to comment #23)
> Following the Comment #14 instructions seem to do the trick. I left all the
> other parameters the same, modifying only the
> /usr/portage/sys-libs/glibc/files/eblits/common.eblit file.

Thanks J.C.  We know what the problem is and now I know that you haven't hit a new issue.  Hopefully upstream will act before 3.7.0 is stabilized.
Comment 25 Dmitry Ivankov 2012-02-15 13:27:26 UTC
I hit this issue even with =dev-util/valgrind-3.6.1-r1. My ld.so.debug has no strlen function, glibc is 2.13-r4.

So the only workaround for now is patching glibc ebuild to have -fno-builtin-strlen?
Comment 26 Stefan Schmiedl 2012-04-20 07:28:07 UTC
I ran into this last night, found this bug and wondered why valgrind ran on my local machine but not on the server, where I had to debug something. Turns out that on my local box, the "gd" use flag was enabled.

I'm not sure what gd does for glibc, but emerging glibc with gd enabled allowed valgrind to run on the server, too.

My use flags for working valgrind are:

dev-util/valgrind-3.7.0-r3  USE="-mpi" 0 kB
sys-libs/glibc-2.14.1-r3  USE="gd (multilib) -debug -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB

s.
Comment 27 Ilia Pozhilov 2012-05-11 11:00:26 UTC
(In reply to comment #26)
> I ran into this last night, found this bug and wondered why valgrind ran on
> my local machine but not on the server, where I had to debug something.
> Turns out that on my local box, the "gd" use flag was enabled.
> 
> I'm not sure what gd does for glibc, but emerging glibc with gd enabled
> allowed valgrind to run on the server, too.
> 
> My use flags for working valgrind are:
> 
> dev-util/valgrind-3.7.0-r3  USE="-mpi" 0 kB
> sys-libs/glibc-2.14.1-r3  USE="gd (multilib) -debug -glibc-omitfp
> (-hardened) -profile (-selinux) -vanilla" 0 kB
> 
> s.

seems to be unrelated on my machine, recompiling with +gd doesn't help.
Comment 28 Pekka Paalanen 2012-07-01 08:36:23 UTC
Unlike mentioned in #214065, valgrind 3.6.1 is affected. I put a question upstream:
https://bugs.kde.org/show_bug.cgi?id=286864#c3
Comment 29 Rafał Mużyło 2012-07-01 10:51:04 UTC
It would seem the problem will get even bigger shortly, at least if I'm reading one of the later points of http://gcc.gnu.org/gcc-4.7/changes.html, section "General Optimizer Improvements".
Comment 30 Anthony Basile gentoo-dev 2012-07-23 19:49:24 UTC
*** Bug 413603 has been marked as a duplicate of this bug. ***
Comment 31 Andrew Savchenko gentoo-dev 2012-07-25 01:28:35 UTC
Oh, that's damn wornedrful: I can't use 3.6.1-r3 because of glibc-2.15 being unsupported and I can't use 3.7.0-r4, because glibc lacks strlen...

Now the only option is to hack glibc's eblit and keep patched version in sync for ages... What a mess...
Comment 32 Anthony Basile gentoo-dev 2012-07-25 15:35:55 UTC
(In reply to comment #31)
> Oh, that's damn wornedrful: I can't use 3.6.1-r3 because of glibc-2.15 being
> unsupported and I can't use 3.7.0-r4, because glibc lacks strlen...
> 
> Now the only option is to hack glibc's eblit and keep patched version in
> sync for ages... What a mess...

*valgrind-3.6.1-r4 (25 Jul 2012)

  25 Jul 2012; Anthony G. Basile <blueness@gentoo.org>
  +valgrind-3.6.1-r4.ebuild, +files/valgrind-3.6.1-glibc-2.15.patch:
  Allow valgrind-3.6.1 to build against glibc-2.15 so Andrew doesn't yell at
  me, bug #390323 comment #31
Comment 33 Anthony Basile gentoo-dev 2012-08-19 13:14:21 UTC
*** Bug 431970 has been marked as a duplicate of this bug. ***
Comment 34 Anthony Basile gentoo-dev 2012-08-19 13:15:16 UTC
(In reply to comment #33)
> *** Bug 431970 has been marked as a duplicate of this bug. ***

The undefined strlen problem persists into 3.8.0.
Comment 35 Anthony Basile gentoo-dev 2012-09-14 11:23:16 UTC
*** Bug 214065 has been marked as a duplicate of this bug. ***
Comment 36 Anthony Basile gentoo-dev 2012-09-14 11:30:40 UTC
*** Bug 274771 has been marked as a duplicate of this bug. ***
Comment 37 Anthony Basile gentoo-dev 2012-09-14 11:32:13 UTC
Note there is an upstream bug report for this:

    https://bugs.kde.org/show_bug.cgi?id=190429
Comment 38 Max Klinger 2012-11-20 11:45:57 UTC
Hey, can someone enlighten me please, if there is a workaround other than editing the /usr/portage/sys-libs/glibc/files/eblits/common.eblit ?
I believe i tried every suggestion made here and a couple of others, no dice.
The weird thing is i have a couple of installations with 

cat /etc/portage/env/sys-libs/glibc 
FLAGS="${CFLAGS} -ggdb"
FEATURES="${FEATURES} splitdebug"

and nothing done to the eblit or ebuilds and it works. Same arch (x86-64), (by now) same gcc (tried 4.5.4 and 4.6.3), same glibc version (2.15.3). One works, one doesn't. What else could be different?
Comment 39 Anthony Basile gentoo-dev 2012-11-20 13:13:33 UTC
(In reply to comment #38)
> Hey, can someone enlighten me please, if there is a workaround other than
> editing the /usr/portage/sys-libs/glibc/files/eblits/common.eblit ?
> I believe i tried every suggestion made here and a couple of others, no dice.
> The weird thing is i have a couple of installations with 
> 
> cat /etc/portage/env/sys-libs/glibc 
> FLAGS="${CFLAGS} -ggdb"
> FEATURES="${FEATURES} splitdebug"
> 
> and nothing done to the eblit or ebuilds and it works. Same arch (x86-64),
> (by now) same gcc (tried 4.5.4 and 4.6.3), same glibc version (2.15.3). One
> works, one doesn't. What else could be different?

Dudka's suggestion from upstream, to compile glibc with -fno-builtin-strlen, is the current working solution.  Its implementation in gentoo is comment #12.

Why you aren't hitting it, I don't know, but look at comment #4 for how you can check for strlen symbol.
Comment 40 Andreas Wallner 2013-02-25 13:21:32 UTC
As was written in #15, the solution in #12 does not work.

Upstream does not seem to care, maybe because it is basically gcc that is compiling the glibc in a way that it does not work with valgrind.

Before reading the comments I wanted to propose a USE flag for this case, but I understand your problem. How about just not stripping -fno-builtin-strlen (or future proof: -fno-builtin*) from the CFLAGS?
This way we do not have that much overhead, and we can use the solution from #12.

A nicer solution might be to add -fno-builtin-strlen to the safe flags, therefore not stripping it. (There are already a few -fno* flags in there so it would fit nicely) Since it only disables a new optimization it should be safe to do so?
Comment 41 Andrew Savchenko gentoo-dev 2013-02-25 18:27:10 UTC
(In reply to comment #40)
> As was written in #15, the solution in #12 does not work.
> 
> Upstream does not seem to care, maybe because it is basically gcc that is
> compiling the glibc in a way that it does not work with valgrind.

This is basically valgrind using symbol reference it should not use.

Aside from fixing valgirnd, the only solution is to disable builtin strlen, but doin this in glibc will really hamper performance and should be done as a last resort only.
Comment 42 Cody Schafer 2013-04-27 07:06:20 UTC
Actual upstream bug appears to be https://bugs.kde.org/show_bug.cgi?id=286864
Comment 43 Andrew Savchenko gentoo-dev 2013-12-29 06:26:21 UTC
Why not to add a patch from the upstream bug:
http://bugsfiles.kde.org/attachment.cgi?id=82043
?

Works fine here and I'm finally able to use valgrind on one of my ~amd64 boxes.
Comment 44 Benjamin Block 2014-03-31 13:57:20 UTC
(In reply to Andrew Savchenko from comment #43)
> Why not to add a patch from the upstream bug:
> http://bugsfiles.kde.org/attachment.cgi?id=82043
> ?
> 
> Works fine here and I'm finally able to use valgrind on one of my ~amd64
> boxes.

Works fine over here too.
Comment 45 Cody Schafer 2014-09-08 03:18:57 UTC
I'm seeing valgrind-3.9.0 with glibc-2.19-r1 working fine (not encountering this bug), was a workaround added to the ebuild or a was this fixed upstream?
Comment 46 Andrew Savchenko gentoo-dev 2014-09-08 10:44:29 UTC
At least with valgrind-3.9.0. and glibc-2.19 the bug is till here. I haven't tried 2.19-r1, thought. But be aware that this bug is floating and it may or may not appear on different setup with apparently similar configuration.
Comment 47 Michael Haubenwallner gentoo-dev 2014-10-13 14:03:39 UTC
(In reply to Andrew Savchenko from comment #46)
> But be aware that this bug is floating and it may or
> may not appear on different setup with apparently similar configuration.

Does this depend on FEATURES=nostrip (for sys-libs/glibc) eventually too?

Got it work here with this hack:
# cat /etc/portage/profile/profile.bashrc 
if [[ ${CATEGORY}/${PN} == 'sys-libs/glibc' ]]; then
        FEATURES="${FEATURES} nostrip"
fi
Comment 48 Bodo Thiesen 2015-07-19 06:18:56 UTC
Technically, I got a new problem, but it's the same anyways, so I'll just hijack this bug :P

dev-util/valgrind-3.10.1 fails on sys-libs/glibc-2.20-r2 - strlen ...

$ strace -o valgrind.strace /usr/bin/valgrind /bin/ls
[... known error message about strlen in ld-linux-x86-64.so.2 ...]
$ ls -l /lib/ld-linux-x86-64.so.2 
lrwxrwxrwx 1 root root 10 19. Jul 08:00 /lib/ld-linux-x86-64.so.2 -> ld-2.20.so
$ grep debug valgrind.strace | grep -v ENOENT
open("/usr/lib/debug/lib64/ld-2.20.so.debug", O_RDONLY) = 4
$ nm /usr/lib/debug/lib64/ld-2.20.so.debug | grep "\<strlen"
0000000000018ad0 t strlen

sys-libs/glibc gd USE flag already in effect.

Reemerged glibc with suggested
    append-flags -O2 -fno-strict-aliasing -fno-builtin-strlen
in /var/cache/portage/tree/sys-libs/glibc/files/eblits/common.eblit - no change

Even more shitty is now, that I can't even downgrade valgrind:

# emerge -1 =dev-util/valgrind-3.9.0
configure: error: Valgrind requires glibc version 2.2 - 2.17
# emerge -1 =dev-util/valgrind-3.9.0 "<sys-libs/glibc-2.18"
 * Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction

nice ...
Comment 49 Bodo Thiesen 2015-07-19 12:22:39 UTC
(In reply to Bodo Thiesen from comment #48)
> Technically, I got a new problem, but it's the same anyways, so I'll just
> hijack this bug :P
> 
> dev-util/valgrind-3.10.1 fails on sys-libs/glibc-2.20-r2 - strlen ...

I just got an intuition to test dropping installsources from FEATURES. Now valgrind works again.

Having compressdebug in FEATURES is no problem.
Comment 50 Bodo Thiesen 2015-07-19 19:09:45 UTC
(In reply to Bodo Thiesen from comment #49)
> (In reply to Bodo Thiesen from comment #48)
>> dev-util/valgrind-3.10.1 fails on sys-libs/glibc-2.20-r2 - strlen ...
> dropping installsources from FEATURES. Now valgrind works again.
> Having compressdebug in FEATURES is no problem.

And -fno-builtin-strlen is still needed in common.eblit.
Comment 51 foufou33 2020-03-13 16:07:49 UTC
still a problem,
glibc has a custom-cflags useflag that makes the file /etc/portage/env/sys-libs/glibc from comment #4 work
Comment 52 Ștefan Talpalaru 2020-05-16 01:26:35 UTC
A patched valgrind-3.15.0-r1 is available in my overlay: https://github.com/stefantalpalaru/gentoo-overlay

The patch simply removes all checks for a "strlen" symbol: https://github.com/stefantalpalaru/gentoo-overlay/commit/558048b43a17a2b5163295683e9a201ae9757962#diff-196a07cd7608fa13838a2697f1cc11f2