On Sunday March 16 2014 09:56:47 Ryan Schmidt wrote: >This was an older version of clang, on older hardware with limited memory; I >haven’t noticed any such problems on my new machine which has gobs of memory >and the current versions of things.
Not even when compiling the gmic port? I don't know how OS X (10.6) limits VM usage, and from what I hear 10.9's virtual memory subsystem has gotten substantially better, but comparing the total scores on my OS X and Linux systems I have the impression that clang could have taken even more memory if it had been able to (with 20GB swap taken I have only 20GB left on my OS X root partition). > Whether or not MacPorts uses the -pipe flag is controlled by the > configurepipe setting in macports.conf. If changing it to no makes the build > work better, please let us know. We changed the default of that setting from > no to yes several years ago, presumably because we thought it would perform > better, but I think that was before we were using clang. This is becoming difficult to assess, because recent documentation suggests -fno-pipe is required to deactivate the behaviour ... and I don't seem to have that flag. In any case, I *think* that on a multi-core SMP system where you use -jN to adapt the number of builder threads/processes to the number of cores, -fno-pipe makes more sense ... esp. if you're working on an SSD where the difference between file IO and pipe IO must be minimal. I'll check my setting, though. It's been awhile already that I've seen messages about emergency paging appear in the kernel.log when I'm updating ports from source. > clang 3.5 and later require C++11, and will say so if you try to install them > on a system without C++11. Effectively, this means clang 3.5 and later > require OS X 10.9 Mavericks or later. Hmmm, I thought clang supported C++11 ; I presume you're referring to a system-dependent C++11 runtime that is not (or cannot) be provided by clang itself? Out of curiosity, how does this work on Linux? I hate it when generic programming languages or their features become dependent on an OS. I can more or less accept that for ObjC because like .Net it is so closely related to an OS-specific GUI framework. But much less so for C++ ... isn't there some kind of standards committee that could avoid this from happening? _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
