For some reason I always compile some components as 64-bit...

Yves S. Garret yoursurrogategod at
Sat May 22 05:45:47 PDT 2010

This is the longest path that exists.


In there is a Frameworks directory.

I noticed something else, in the directory that it's crashing on, there are
two slashes.  "...destroot//opt/Library..."

On Sat, May 22, 2010 at 8:33 AM, Ryan Schmidt <ryandesign at>wrote:

> On May 21, 2010, at 21:21, Yves S. Garret wrote:
> > DEBUG: Executing proc-post-org.macports.destroot-destroot-0
> > DEBUG: couldn't read file
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_couchdb/work/destroot//opt/local/Library/LaunchDaemons/org.apache.couchdb.plist":
> no such file or directory
> > while executing
> > "exec /usr/bin/sed {s;^.*DYLD_LIBRARY_PATH.*$;;g} <
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_data..."
> Ok, it's having trouble running the reinplace command in the port's
> post-destroot procedure.
> > This is weird, but when I downloaded the code for couchdb and installed
> it, everything compiled without a problem.
> Not weird; when you build the code by hand, you're not running the
> reinplace command that's in the portfile.
> > Am I doing something wrong when using macports?
> Not necessarily. The port may be broken in same cases. Does the file
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_couchdb/work/destroot//opt/local/Library/LaunchDaemons/org.apache.couchdb.plist"
> exist? If not, what's the longest part of that path that does exist?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-users mailing list