------- Comment #38 from developer at sandoe-acoustics dot co dot uk 2009-09-25 10:54 ------- (In reply to comment #37) > I just noticed that I have been neglecting to pass > --enable-version-specific-runtime-libs to configure. What should be the impact > of that on the build (since I did get the expected libgcc-ext.10.4/5 files)? > Could that be related to the build failure on x86_64-apple-darwin10?
I don't think any of this stuff makes much sense w/out --enable-version-specific-runtime-libs; I always use this to enable multiple versions of gcc installed on the same machine. I don't know if that's the root of the D10 issue - somehow I doubt it (I try not to make assumptions about future systems - and probably excluded D10 somewhere ... but hopefully I'll look at that later). > Are you using... > make -k check RUNTESTFLAGS="--target_board=unix/-muse-shared-libgcc-ext" yes. should be listed in the test results. whether this is default or not can be determined trivially (Init(1)) as and when the approach is agreed with the relevant maintainers. > The option behavior should be -muse-static-runtimes instead. different objective not related to the _ext; mea culpa if that is present in the patch; FWIW: -muse-static-runtimes is designed to allow the building of statically linked (save libSystem) objects on Darwin (this is to assist in deployment of parallel jobs on clusters - or distibution of apps using more advanced features than are standard on a given rev) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
