Jack Howarth <[EMAIL PROTECTED]> writes: > On Mon, Nov 24, 2008 at 11:59:03AM +0000, IainS wrote: > > 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 > > Iain, > The use of the system libgcc simply won't work on Mac OS X 10.4. > The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib > and not libgcc_s.10.4.dylib...
Replacing or modifying the system libgcc is not recommended and may break in the next version of Mac OS X. It's not clear to me what this will mean for GCC development. You can see the exact commands the regression tester used in the build log file at <http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip>; basically, + /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/tbox/objs --target=powerpc-apple-darwin8.5.0 + make -j2 bootstrap + make -j2 -k check No extra flags, no moving stuff around, nothing added or deleted from the GCC source tree; that would defeat the purpose of the regression tester, which is to test the actual GCC in the repository. There is some strangeness in the system configuration: GMP and MPFR are installed in /usr/local as static libraries, and I seem to remember the system is running with a modified kernel, containing a patch which makes dejagnu work, which is why it's running 10.4.5. 10.4.11 is significantly different from 10.4.5 and from 10.5. I believe it adds a shared libgcc and libstdc++. It may be that GCC does not work on 10.4.11. You can find the exact scripts the tester uses to run the build in contrib/regression in the GCC source tree. The tester checks out the tree and runs the scripts from the checkout.
