Update: Macports does not work on recent Mountain Lion machines

[Clemens Lang]

On Sat, Sep 15, 2012 at 10:45:48AM -0600, John Daschbach wrote:
> I recently posted about my struggles to get macports to work on a 3
> year old iMac with a new clean hard drive and a fresh upgrade to
> Mountain Lion. The issue is that many subjobs called from tcl
> hang/die. This often happens during configure, but sometimes during
> build. Generally it is when clang is being called, but I have now
> seen it with other related sub processes like javac.

I've seen this being reported for a number of processes, e.g., sw_vers.
There's no much we can do about this, unless we get more information on
one of the hanging processes. I've previously helped debugging a similar
case and getting a trace sample showed the process was waiting for some
IPC[1].

> For things which use the standard GNU autoconf tool chain it is
> possible to install macports that fail by copying the command line
> which generated the failure from config.log and running it directly
> from the shell. This has never failed to work.

I'm not surprised this works well. Which user did you use to run this,
btw?

> Then, one edits the *.state file to show that the config phase
> completed.

This will not work correctly, if the configure phase actually didn't
finish correctly, so you shouldn't do that.

> Sometimes then a "port build" will work, and sometimes not, but the
> same basic procedure of running the command from the shell and editing
> the *.state file works. I have not yet had a failure in the port
> destroot or port install phase after this.

And yet you shouldn't do this. MacPorts sets quite a number of
environment variables affecting the build and people usually miss those
when running commands manually from command line. There's no way to be
sure what you're getting is what MacPorts expected.

> So on two perfectly clean new installs of Mountain Lion macports does
> not work for a majority of builds. The problem is somehow related to
> the subjobs called from tcl. A guess would be there is some setting in
> tcl on new Mountain Lion installs that is causing this. Since some
> builds work, but the same builds fail on two different machines in
> exactly the same place, my suspicion is there is either a subjob
> memory limit in the tcl environment, or some other restriction on tcl
> subjobs. It is hard to see how it is not due to tcl subjobs, as I have
> not had a failure running the same commands from a normal shell.

How do you run port? Do you use
  sudo port something,
or do you change to the superuser and run port like this:
  su
  port something?

To help diagnose the problem, please find a port where this breaks
reproducably (subversion from [1] might be a good example), use
top/htop/Activity Monitor to find the PID of the hanging process and run
  mkdir sysdiag
  sudo sysdiagnose -f sysdiag $PID
This will generate a tarball with information that might be useful in
tracking the problem.

[1] http://lists.macosforge.org/pipermail/macports-dev/2012-September/020312.html

-- 
Clemens Lang