On Mar 16, 2014, at 11:51, Christopher Jones wrote: > Any reason you are using clang 3.3 though ? Have you tried a newer clang > version. Macports Clang 3.4 or 3.5 compilers ? I was unable to do this for my > issue, 3.3 was the only compiler I had available, but I would be very > interested to know if the issue goes away in a newer release.
For some reason I haven't been able to install MacPorts clang-3.4 yet, and when I built from source a while ago it didn't work. But the test I did under Linux was with clang-3.4, so I guess we're dealing with an issue that's inherent to clang here. It tooks about 1.5 hours to compile there, but without a comparison of the g++ numbers that's just an indication that an AMD C60 netbook is a slug :) > > Won’t work. There are many more differences than just resolving libraries at > the link step (Differences in the API of std::string classes for instance). > You have to compile *and* link against libc++, using the same compiler, which > means clang. Damn. Fortunately I just learned that gmic isn't central at all to Calligra (or even to its Krita component), so the easy way out in this particular case is to disable it when clang is used. But maybe one ought to file a report with Apple or the clang project, as I'm sure there are other cases where compiler memory usage become a serious obstacle. Heck, it even looks as if clang uses a single process that handles all the subsequent steps for which traditional compilers use different applications (and it's my experience that -pipe is rarely a good idea for big projects with parallel building). Thus, if it's the preprocessor that needs those 20GB of memory, the footprint continues to hurt performance of all subsequent steps, which would explain why I see a clang process that's sitting at 5-15% CPU usage for such a long time. Very annoying if the rest of the machine grinds to an almost halt when it's basically doing nothing! _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
