valgrind-3.8.1 on osx-10.8.2 is broken

[leifwalsh]

% /usr/local/Cellar/valgrind/3.8.1/bin/valgrind --version || echo "returned $?"
valgrind: Unknown/uninstalled VG_PLATFORM 'amd64-darwin'
returned 1
% </usr/local/Cellar/valgrind/3.8.1/INSTALL_RECEIPT.json
{"built_as_bottle":false,"HEAD":"dd210918cd8f37902b2b64d725c929c2ba5fb13d","time":1351005355,"tapped_from":"mxcl/master","used_options":[],"unused_options":[]}

If I build valgrind-3.8.1 from source on osx by myself, it works fine.

[jasonlfunk]

I am seeing this as well.

[jacknagel]

If you remove the << '--build=amd64darwin' bit from the formula, does it work?

[jasonlfunk]

No, I still get the same thing.

bash-3.2$ brew install valgrind
==> Downloading http://valgrind.org/downloads/valgrind-3.8.1.tar.bz2
Already downloaded: /Library/Caches/Homebrew/valgrind-3.8.1.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/valgrind/3.8.1 --enable-only64bit
==> make
==> make install
/usr/local/Cellar/valgrind/3.8.1: 278 files, 51M, built in 2.2 minutes
bash-3.2$ valgrind
valgrind: Unknown/uninstalled VG_PLATFORM 'amd64-darwin'

[Sharpie]

After a major OS release, Valgrind is usually in a semi-broken state until the developers update it. The Homepage lists support for 10.8 as "limited".

[leifwalsh]

And yet, building it vanilla works fine. This is not an upstream bug.

Sent from my iPhone

On Oct 23, 2012, at 23:46, Charlie Sharpsteen [email protected] wrote:

After a major OS release, Valgrind is usually in a semi-broken state until the developers update it. The Homepage lists support for 10.8 as "limited".

—
Reply to this email directly or view it on GitHub.

[adamv]

When in doubt, re-check what MacPorts is doing: https://trac.macports.org/browser/trunk/dports/devel/valgrind/Portfile

[jasonlfunk]

@adlaiff6 Are you using any flags to build it vanilla? I just downloaded from valgrind's website and built it and am getting the same error. If you got it to run, what did you have to do?

[leifwalsh]

Don't think so, just set the prefix.

Sent from my iPhone

On Oct 24, 2012, at 16:20, jasonlfunk [email protected] wrote:

@adlaiff6 Are you using any flags to build it vanilla? I just downloaded from valgrind's website and built it and am getting the same error. If you got it to run, what did you have to do?

—
Reply to this email directly or view it on GitHub.

[adamv]

Did the build turn out 32-bit or 64-bit or...?

[leifwalsh]

64-bit. Looks like the homebrew one just neglected to install some libs.

Adam Vandenberg [email protected] writes:

Did the build turn out 32-bit or 64-bit or...?

---

Reply to this email directly or view it on GitHub:
#15620 (comment)

Cheers,
Leif

[Sharpie]

And yet, building it vanilla works fine. This is not an upstream bug.

Well now... a twitchy build system certainly falls under "stuff that upstream is responsible for".

[leifwalsh]

I've used valgrind's build system successfully for several versions, on several operating systems, with repeatable results. I disagree that it's "twitchy".

Have you tried and failed to reproduce this bug?

Sent from my iPhone

On Oct 24, 2012, at 21:43, Charlie Sharpsteen [email protected] wrote:

And yet, building it vanilla works fine. This is not an upstream bug.

Well now... a twitchy build system certainly falls under "stuff that upstream is responsible for".

—
Reply to this email directly or view it on GitHub.

[MikeMcQuaid]

I can reproduce it. It is an upstream bug. We don't install or not install their libs; we use the upstream make install. We only pass arguments that are required for the build. You sound like you know the Valgrind build system better than us; perhaps you could indicate what we've broken and help with a patch?

@adamv @jacknagel @Sharpie for what it's worth I tried env :std but that doesn't build at all.

[leifwalsh]

Ok but I need help with homebrew. How can I run a formula in "debug"?

Sent from my iPhone

On Oct 25, 2012, at 5:35, Mike McQuaid [email protected] wrote:

I can reproduce it. It is an upstream bug. We don't install or not install their libs; we use the upstream make install. We only pass arguments that are required for the build. You sound like you know the Valgrind build system better than us; perhaps you could indicate what we've broken and help with a patch?

@adamv @jacknagel @Sharpie for what it's worth I tried env :std but that doesn't build at all.

—
Reply to this email directly or view it on GitHub.

[MikeMcQuaid]

brew install -dv valgrind

[leifwalsh]

What is the meaning of "brew: superenv removed:"?

On 25 Oct, 2012, at 6:36 AM, Mike McQuaid [email protected] wrote:

brew install -dv valgrind

—
Reply to this email directly or view it on GitHub.

Cheers,
Leif

[MikeMcQuaid]

That's a compiler flag that Homebrew removed.

[leifwalsh]

Well it looks like that's what's breaking it. Why is it doing that and how can I make it stop?

On 25 Oct, 2012, at 7:26 AM, Mike McQuaid [email protected] wrote:

That's a compiler flag that Homebrew removed.

—
Reply to this email directly or view it on GitHub.

Cheers,
Leif

[MikeMcQuaid]

Can you be more specific than "that's what is breaking it" please. What flag is being removed than needs to be there? You can disable superenv (the reason the flags are being removed) by adding env :std to the formula but that doesn't compile and doesn't give us the information we need to fix Valgrind and/or superenv.

[leifwalsh]

It's removing tons of flags, I don't know how to pick and choose which ones it removes, and if I did, I wouldn't want to be the one to figure out which subset makes the compile fail. Here's an example:

cc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_darwin=1 -DVGP_x86_darwin=1 -DVGPV_x86_darwin_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/Cellar/valgrind/3.8.1/lib/valgrind"\" -DVG_PLATFORM="\"x86-darwin\""   -arch i386 -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 -fno-pic -fno-PIC  -Wno-long-long  -Wno-pointer-sign -fno-stack-protector -MT libcoregrind_x86_darwin_a-m_clientstate.o -MD -MP -MF .deps/libcoregrind_x86_darwin_a-m_clientstate.Tpo -c -o libcoregrind_x86_darwin_a-m_clientstate.o `test -f 'm_clientstate.c' || echo './'`m_clientstate.c
brew: superenv removed: -I../coregrind -arch i386 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -Wno-long-long -Wno-pointer-sign

What I do know is that if I configure with the same options but build without homebrew, it doesn't do this superenv thing and it works fine. There are warnings if you use clang instead of gcc but it still builds and runs.

What is superenv trying to do here?

On 25 Oct, 2012, at 7:34 AM, Mike McQuaid [email protected] wrote:

Can you be more specific than "that's what is breaking it" please. What flag is being removed than needs to be there? You can disable superenv (the reason the flags are being removed) by adding env :std to the formula but that doesn't compile and doesn't give us the information we need to fix Valgrind and/or superenv.

—
Reply to this email directly or view it on GitHub.

Cheers,
Leif

[leifwalsh]

Yeah, if I'm reading the formula properly, I've done all the same things in a vanilla environment and they resulted in a successful installation. I don't think it's the formula's fault, I think it's something else in the homebrew system, and I think superenv is suspect (but I don't know what other spooky nonsense is going on in there).

If you have specific questions I can answer them but I don't have the time to keep leading this investigation. Thanks for your help so far.

[MikeMcQuaid]

Turns out it was nothing to do with superenv and is weirdness on behalf of upstream (checking libraries are executable or saying they can't be found). Perhaps not a upstream bug but definitely odd (and a regression I've now fixed in 273ebbe; @adamv FYI I reverted your commit).

[joshfrench]

Future googlers: This revert leaves valgrind unusable without the manual chmod +x ... fix originally reported in #2150.