> On 14 Jan 2019, at 13:53, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > > "MCC CS" <mc...@gmx.com> writes: > >> I've been running the testsuite on my macOS, on which >> it is especially unbearable. I want to (at least try to) > > that problem may well be macOS specific: since at least macOS 10.13 > (maybe even 10.12; cannot currently tell for certain) make -jN check > times on my Mac mini skyrocketed with between 60 and 80% system time. > It seems this is due to lock contention on one specific kernel lock, but > I haven't been able to find out more yet.
this PR mentions the compilation, but it’ even more apparent on test. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257 * Assuming SIP is disabled. Some testing suggests that each DYLD_LIBRARY_PATH entry adds around 2ms to each exe launch. So .. when you’re doing something that’s a lot of work per launch, not much is seen - but when you’re doing things with a huge number of exe launches - e.g. configuring or running the test suite, it bites. A work-around is to remove the RPATH_ENVAR variable setting in the top level Makefile.in (which actually has the same effect as running things with SIP enabled) === Possible solution (partial hacks locally, not ready for posting) My current investigations (targeted at GCC 10 time frame, even if they are subsequently back-ported) is to replace all use of absolute pathnames in GCC libraries with @rpath/xxx and figure out a way to get the compiler to auto-add the relevant rpaths to exes (so that a fixed installation of GCC behaves the same way as it does currently). === DejaGNU on macOS... DejaGNU / expect are not fantastic on macOS, even given the comments above - it’s true. Writing an interpreter/funnel for the testsuite has crossed my mind more than once. However, I suspect it’s a large job, and it might be more worth investing any available effort in debugging the slowness in expect/dejaGNU - especially the lock contention that Rainer mentions. > There's no such problem on other targets, not even e.g. on Mac OS X 10.7. indeed. Iain
