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

[Yves S. Garret]

This is the longest path that exists.

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_couchdb/work/destroot/opt/local/Library

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 macports.org>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: <http://lists.macosforge.org/pipermail/macports-users/attachments/20100522/fe735f5b/attachment.html>