Native Quartz version of gnucash

[cory steers]

So, thanks a lot to all the help I've received so far.  "sudo port install
gnucash" ran to completion without incident:  However, when I try to run
gnucash, I get the following:
dyld: Library not loaded: /sw/lib/libintl.1.dylib
  Referenced from: /usr/local/lib/libgnc-backend-file-utils.0.dylib
  Reason: image not found
Trace/BPT trap


Running "sudo gnucash" get's it going, but with a small error and a whole
ton of logging spewing out in the Terminal window where I launched it from.

So, did I make a mistake running all the port commands with sudo, or did I
do something wrong to have to use sudo to run gnucash, or is that just how
it's supposed to work?

Thanks,



On Thu, May 21, 2009 at 4:58 PM, cory steers <madsteer at gmail.com> wrote:

> that makes sense.  I just kicked off another "port install gnucash" and
> it's rolling on with guile and various others packages.
> Thanks,
>
>
> On Thu, May 21, 2009 at 1:52 PM, Ryan Schmidt <ryandesign at macports.org>wrote:
>
>> On May 20, 2009, at 09:38, Lenore Horner wrote:
>>
>>  It looks to me like the patch itself worked, but something else got
>>> crazy.  I haven't seen this, so I don't know other than suggesting clean and
>>> then doing it again.
>>>
>>
>>
>>  On May 20, 2009, at 07:52 , cory steers wrote:
>>>
>>> mbp:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_goffi
>>>> ce/work cory $ sudo port install goffice
>>>>
>>>
>> You were in the port's temporary work directory when you started the port
>> command.
>>
>>
>>  --->  Building goffice
>>>> --->  Staging goffice into destroot
>>>> --->  Installing goffice @0.6.6_0
>>>> --->  Activating goffice @0.6.6_0
>>>> --->  Cleaning goffice
>>>>
>>>
>> The clean phase removes the work directory.
>>
>>
>>  couldn't change working directory to
>>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_goffice/work":
>>>> no such file or directory
>>>>    while executing
>>>> "cd $savedir"
>>>>    (procedure "foreachport" line 17)
>>>>    invoked from within
>>>> "foreachport $portlist {
>>>>        set target $action
>>>>
>>>>        # If we have a url, use that, since it's most specific
>>>>        # otherwise try to map the ..."
>>>>    (procedure "action_target" line 7)
>>>>    invoked from within
>>>> "$action_proc $action $portlist [array get global_options]"
>>>>    (procedure "process_cmd" line 86)
>>>>    invoked from within
>>>> "process_cmd $remaining_args"
>>>>    invoked from within
>>>> "if { [llength $remaining_args] > 0 } {
>>>>
>>>>    # If there are remaining arguments, process those as a command
>>>>
>>>>    # Exit immediately, by default, unless..."
>>>>    (file "/opt/local/bin/port" line 3247)
>>>>
>>>
>> When MacPorts has finished what it was doing, it tries to go back to the
>> directory you were in when you started the command, and gets confused and
>> prints the above (long) error if that directory no longer exists. Aside from
>> looking scary, it's harmless, though, and the command you ran should have
>> completed normally. The issue is filed here:
>>
>> http://trac.macports.org/ticket/17076
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090521/4930c8ae/attachment.html>