libgcc update ... to 4.9?

[Clemens Lang]

Hi,

> I still had the log from the attempt to install libgcc 4.9; it's attached.

As Joshua already told you, this doesn't contain the reason for not using
binary archives. In fact, since it picked up an unfinished build and
continued it, this may well be the reason for not using binaries.


> Surely, but how many such build systems does MacPorts carry?.

Hundreds of them. Even thousands.


> And in a sense I want the build system to be able to read my files. I
> no longer run `port install` as myself because too many ports need actual
> root privileges during install, but for the rest I like to have the build
> tree to be mine. For a number of ports (like kdelibs4), the work source
> directory is actually a symlink to a directory in one of my own working
> directories.

Correct, pretty much all ports currently use root privileges during
installation, because the change file owners and modes. That could only
prevented by using something like fakeroot, which would have to be ported to
OS X first.

Note that the sandboxing was specifically introduced to lower the risk in
doing that, because even with root privileges, build system can not modify
files outside of their destroot directory.


> Takes a bit of discipline (to avoid reverting my changes to stock) but it
> greatly increases turn-over once you master it. For cmake projects, I can
> simply do a make in the lowest build directory holding my changes that has
> a CMakeLists.txt, and then do a `make install/fast` from there to install
> the new files directly into ${prefix}.

Sounds like what you really want is a non-root installation of MacPorts. You
can configure MacPorts with --with-no-root-privileges.


> (I'm much more concerned about what could happen during an install, and not
> so much to my files but to system files. Which is why my whole /usr/local
> tree is owned by me and not by root, and why I ran `port install` as myself
> for so long.)

Did you mean "/opt/local" here, not "/usr/local"? And other than that, again,
sandboxing is there for exactly this reason, to reduce the risk of running
make install DESTDIR=$destroot with root privileges. And again, looking at
your requirements makes me think you should really use a non-root installation
of MacPorts.

-- 
Clemens Lang