One failed test on OSX 10.5.8

[GoogleCodeExporter]

What steps will reproduce the problem?
1. make
2. make test

What is the expected output? What do you see instead?
See attached log output.

What version of the product are you using? On what operating system?
Lastest from **hg**

Please provide any additional information below.
$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Original issue reported on code.google.com by voidptr...@gmail.com on 22 Jun 2011 at 11:22

Attachments:

• filtered_re2_test.log

[GoogleCodeExporter]

I see this with r62 on Debian sid too
g++-4.6_4.6.1-2

Original comment by stefano.rivera on 7 Jul 2011 at 2:30

[GoogleCodeExporter]

This is odd.  The test is behaving like it is running old code.
What does make print when the test fails?
Which target does make say it failed to 'build'?
I bet it is shared-test, in which case the problem
is that the new test is finding an older shared
library that you've installed on your system.
make install should then make make test work.
Of course we should fix shared-test to ignore the
system libraries always, but I am not sure how.
It already does

@LD_LIBRARY_PATH=obj/so:$(LD_LIBRARY_PATH) ./runtests $(STESTS)

and honestly I thought that would be enough.

Original comment by rsc@swtch.com on 11 Jul 2011 at 12:16

• Changed state: WaitingForReply

[GoogleCodeExporter]

> What does make print when the test fails?

I see the same things that voidptrptr attached. Haven't looked into it at all

> I bet it is shared-test, in which case the problem
> is that the new test is finding an older shared
> library that you've installed on your system.

$ ldd obj/test/filtered_re2_test
    linux-vdso.so.1 =>  (0x00007fff717e7000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1e14d73000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e14af1000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1e148da000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1e146be000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e1433b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1e150a0000)

Nope. I'm not even building the shared library. I'm avoiding that until I can't 
possibly avoid it (e.g. a package starts linking to it or another distro starts 
shipping it as a shared library), because pretty much every upload is going to 
have an ABI break.

Also, this was in a clean chroot.

Original comment by stefano.rivera on 11 Jul 2011 at 2:19

[GoogleCodeExporter]

This issue was closed by revision 7007b2180a42.

Original comment by rsc@swtch.com on 22 Jul 2011 at 3:39

• Changed state: Fixed