Opened 10 years ago

Last modified 8 years ago

#13060 closed defect

Valgrind complains about glibc 2.15 — at Version 17

Reported by: jpflori Owned by: tbd
Priority: major Milestone: sage-5.13
Component: packages: optional Keywords: valgrind spkg
Cc: iandrus, jpflori, schilly Merged in:
Authors: Jean-Pierre Flori Reviewers:
Report Upstream: Fixed upstream, but not in a stable release. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jpflori)

Valgrind configure script complains about glibc version 2.15 (which is shipped e.g. with Ubuntu 12.04).

The usual solution is to treat this version as the previous one: see commit r12323 in the valgrind svn, or tickets on different distribution bug tracker.

Furthermore, the autogen.sh scripts fails with recent automake version. This is commit r12396.

A further fix has been applied to test if the compiler supports the -arch flag. This is needed to build the spkg on OSX with the FSF gcc provided by Sage which does not support this Apple specific flag.

It is known that some tests of the testsuite fail.

An updated spkg including these two commits on top of 3.7.0 is available at http://perso.telecom-paristech.fr/~flori/sage/valgrind-3.7.0.p0.spkg

Change History (22)

comment:1 Changed 10 years ago by jpflori

After applying the diff of the above commit, one has to rebuild the configure scripts with autogen.sh (which is available in the svn, not in the usual tarballs). This basically calls auto* stuff, but the current input *.am files are incompatible with the current automake tool... See r12396 in valgrind svn.

comment:2 Changed 10 years ago by jpflori

  • Description modified (diff)
  • Status changed from new to needs_review

Here comes a slightly updated spkg: http://perso.telecom-paristech.fr/~flori/sage/valgrind-3.7.0.p0.spkg

I've applied the two mentioned patches and rerun autogen.sh to regenerate the build system files. The package installs and seems functional with my Sage installation.

Another solution whould be to properly package a recent valgrind svn version, although I'd prefer to use this light solution and wait for a proper stable release to make a real update to valgrind. Feel free to disagree and rant here.

Changed 10 years ago by jpflori

Spkg diff, for review only.

comment:3 Changed 10 years ago by jpflori

There might be something wrong with valgrind testsuite. I'm looking into this right now.

comment:4 Changed 10 years ago by jpflori

  • Status changed from needs_review to needs_work

In fact, the current spkg is not functional at all.

It builds correctly, but fails to pass its test suite and Sage does not launch with the -valgrind flag.

comment:5 Changed 10 years ago by jpflori

The startup problem seem to be caused by strlen being inlined and its symbol not found by valgrind which fails to start.

comment:6 Changed 10 years ago by jpflori

  • Authors set to Jean-Pierre Flori
  • Work issues set to testsuite fails

Installing the debug version of libc6 (libc6-dbg) on my Ubuntu installation solves both the startup problem. Nonetheless, it might be useful to actually print something when valgrind fails for this reason. Currently running "sage -valgrind" exits without complaining although tunning directly valgrind from the local/bin folder provides some hints.

comment:7 follow-up: Changed 10 years ago by jpflori

On a debian installation on top of recent hardware (corei7-avx) I'm able to install the old spkg (debian currently ships eglibc 2.13), but get a SIGILL when launching sage, which comes as no surprise: https://bugs.kde.org/show_bug.cgi?id=273475

The latest svn version is enough to let sage starts.

On the same install, the test suite with the old spkg yields

== 599 tests, 77 stderr failures, 56 stdout failures, 0 stderrB failures, 1 stdoutB failure, 3 post failures ==

the one proposed here yields

== 599 tests, 77 stderr failures, 56 stdout failures, 0 stderrB failures, 1 stdo
utB failure, 3 post failures ==

which was expected. With the latest svn version (you can test it by replace p0 by jp in the above url):

== 545 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdo
utB failure, 0 post failures ==

On the ubuntu install mentioned above, with the

== 591 tests, 79 stderr failures, 57 stdout failures, 0 stderrB failures, 0 stdo
utB failure, 3 post failures ==

and with the latest svn version

== 534 tests, 4 stderr failures, 1 stdout failures, 0 stderrB failures, 1 stdo
utB failure, 0 post failures ==

Whatsoever, I'm not sure that the problem of dealing with avx instructions should be dealt with here. We surely should wait for a proper release by the valgrind team, the tested development version is completely arbitrary.

About the test suite failure, I'm not convinced it should prevent including the updated p0 spkg proposed here, if they were present before. I must admit I do not remember seeing errors when dealing with #7766, but we potentially forgot to run the testsuite all along.

If we expect these failures to be fixed, I can definitely not take care of this with my little knowledge of valgrind.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 10 years ago by iandrus

Replying to jpflori:

About the test suite failure, I'm not convinced it should prevent including the updated p0 spkg proposed here, if they were present before. I must admit I do not remember seeing errors when dealing with #7766, but we potentially forgot to run the testsuite all along.

I know I ran the test suite last time at least once, but I think I saw a few failures on my Mac. Now trying to install it on Sage 5.0 neither will even build. I should have thought to build it when I was testing the betas. The old spkg gives

...
make  all-recursive
Making all in include
make[2]: Nothing to be done for `all'.
Making all in VEX
make  all-am
gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1 -DVGPV_amd64_darwin_vanilla=1 -Ipriv   -arch x86_64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -mmacosx-version-min=10.5 -fno-stack-protector -Wbad-function-cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-long-long  -Wno-pointer-sign -fno-stack-protector -MT libvex_amd64_darwin_a-main_globals.o -MD -MP -MF .deps/libvex_amd64_darwin_a-main_globals.Tpo -c -o libvex_amd64_darwin_a-main_globals.o `test -f 'priv/main_globals.c' || echo './'`priv/main_globals.c
gcc: error: x86_64: No such file or directory
gcc: error: unrecognized option ‘-arch’
make[3]: *** [libvex_amd64_darwin_a-main_globals.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Error building Valgrind 3.7.0
...

So it looks like the former is a problem with the new gcc package:

sage -sh -c 'which gcc'
/Users/gvol/SageStuff/sage-5.0.rc0/local/bin/gcc

And the spkg for review here gives.

...
checking for a sed that does not truncate output... /usr/bin/sed
checking for perl... /usr/bin/perl
checking for gdb... /usr/bin/gdb
checking dependency style of gcc... gcc3
checking for diff -u... yes
checking for a supported version of gcc... ok (4.6.3)
configure: error: cannot run /bin/sh ./config.sub
Error configuring Valgrind 3.7.0
...

Here config.sub is a symlink to /usr/share/automake-1.11/config.sub. This probably has something to do with you running ./autogen.sh, but I'm not an expert in how to fix that. If I run ./autgen.sh myself then it configures fine but runs into the -arch problem as before.

comment:9 in reply to: ↑ 8 Changed 10 years ago by jpflori

Replying to iandrus:

Here config.sub is a symlink to /usr/share/automake-1.11/config.sub. This probably has something to do with you running ./autogen.sh, but I'm not an expert in how to fix that. If I run ./autgen.sh myself then it configures fine but runs into the -arch problem as before.

Oh, I didn't realize that... I've uploaded a new spkg obtained with autoreconf -fi rather than autogen.sh which has no symlinks.

I'll look into the arch stuff but have no apple stuff to test it.

comment:10 Changed 10 years ago by jpflori

Just a reminder for myself: indeed the apple gcc supports -arch, but the fsf one does not.

comment:11 Changed 10 years ago by iandrus

Replying to jpflori:

Replying to iandrus:

Here config.sub is a symlink to /usr/share/automake-1.11/config.sub. This probably has something to do with you running ./autogen.sh, but I'm not an expert in how to fix that. If I run ./autgen.sh myself then it configures fine but runs into the -arch problem as before.

Oh, I didn't realize that... I've uploaded a new spkg obtained with autoreconf -fi rather than autogen.sh which has no symlinks.

Cool, thanks. I just tried it (in the same place) and got the same error though. Perhaps, it's in a different place?

I'll look into the arch stuff but have no apple stuff to test it.

I think if you can force sage to use the gcc spkg it would exhibit the same problem, unless you are already using it. What does sage -sh -c 'which gcc' return?

It might be worth asking Jeroen (or on sage-devel) since he knows it a lot better.

comment:12 follow-up: Changed 10 years ago by jpflori

The spkg is up now, I was a little slow to upload it.

About the gcc -arch problem, I think the problem is with Valgrind configure script which adds this flag as soon as it detects that its run on OSX because it assumes that someone on OSX will be using an Apple gcc. That's the reason why I get no problem on Linux with the FSF gcc, the Ubuntu one or the Sage one.

comment:13 Changed 10 years ago by jpflori

Oh and valgrind.org seems down, so I don't have access to their svn anymore to see if anythig was commited about this gcc thingy lately.

We should maybe look into what Fink does: http://osdir.com/ml/fink-users-osx-unix/2011-11/msg00168.html although once more I'm no Apple user so don't have access or am used to such things.

comment:14 in reply to: ↑ 12 Changed 10 years ago by iandrus

Replying to jpflori:

The spkg is up now, I was a little slow to upload it.

No problem. It works now—except for actually building. :-)

About the gcc -arch problem, I think the problem is with Valgrind configure script which adds this flag as soon as it detects that its run on OSX because it assumes that someone on OSX will be using an Apple gcc. That's the reason why I get no problem on Linux with the FSF gcc, the Ubuntu one or the Sage one.

Ah, now I see it. I guess we'll have to patch that, or ask them to do it upstream.

Fink simply disabled mpicc http://fink.cvs.sourceforge.net/fink/dists/10.7/stable/main/finkinfo/devel/valgrind.info?view=markup which was the FSF compiler rather than gcc.

comment:15 Changed 10 years ago by jpflori

Valgrind website is back up. After a quick search trhough the svn log and the bug tracker, I found nothing related to the -arch flag. I guess we have to report upstream and/or provide a patch to the configure/build system.

comment:16 Changed 10 years ago by jpflori

  • Status changed from needs_work to needs_review

I've included some autotools magic to test if the -arch i386/x86_64 flag is supported and fall back to the -m32/64. Could you test the updated spkg at the same address as usual (at least the spkg still build on my linux)?

I've put the diffs into the patches directory (although they are already applied because we have to run autoreconf) and will upload them here for review purpose.

Changed 10 years ago by jpflori

Diff for upstream svn commit r12323; accept glibc 2.15.

Changed 10 years ago by jpflori

Diff for upstream svn commit r12396; accept automake 1.11.2 and later.

Changed 10 years ago by jpflori

Diff for configure.in; test -arch flag.

Changed 10 years ago by jpflori

Diff for Makefile.all.am; test for -arch flag.

comment:17 Changed 9 years ago by jpflori

  • Description modified (diff)
  • Work issues testsuite fails deleted
Note: See TracTickets for help on using tickets.