Hello Jack,
On 21 Nov 2008, at 18:35, Jack Howarth wrote:
On Fri, Nov 21, 2008 at 03:57:15PM +0000, IainS wrote:
When 'make checking', I conventionally move the built libgcc_s.
1.dylib
and libgcc_s.10.4.dylib to one side prior to testing (so that the
Apple-supplied system version is used).
__Unwind_GetIPInfo is not present in the stock:
<snip>
Since the libgcc can contain new symbols which older libgcc's
may not
and libstdc++ is built against this newer libgcc, I wouldn't expect
it to
necessarily work.
OK.
I would note that the recommended approach for building llvm-gcc42
is for the FSF gcc's libstdc++-v3 to be removed from the source
tree so that the system copy is used. I wouldn't be surprised if the
Whilst this is true of the Apple open source distribution, I don't
think it's what the regression tester at
http://gcc.gnu.org/regtest/HEAD/
is doing since there seem to be test results produced for libstdc++ etc.
I tried the removal step, just to make sure - and it caused a whole
different set of FAILs....
---
Do you have (or know where to find) the scripts that are used by
"regress" ? -- I still can't 100% replicate the results on 8.11 with
the exact command line options from the regress test_summary log file.
---
Other than the comment above, I think that the main source of
differences I see are to do with using " --enable-version-specific-
runtime-libs " and then running make check without installing the
compiler to its final position (there are differences in the embedded
rpaths in libstdc++, and libgfortran, gomp etc). I haven't got to
the bottom of this yet.. it all takes time, which is ever in short
supply.
cheers,
Iain
