help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sudo fink install octave-atlas still running after 24 hours


From: Alexander Hansen
Subject: Re: sudo fink install octave-atlas still running after 24 hours
Date: Mon, 07 Jan 2013 21:41:53 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 1/7/13 9:13 PM, Ben Abbott wrote:
> 
> On Jan 7, 2013, at 11:02 PM, Richard Shinn wrote:
>> On Jan 6, 2013, at 9:55 AM, Benjamin Abbott <address@hidden> wrote:
>>
>>> On Jan 6, 2013, at 10:21 AM, Richard Shinn <address@hidden> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm trying to install octave on Mountain Lion on an Intel Core 2 Duo 
>>>> MacBook Pro . I  followed the instructions on this page. web page:
>>>>
>>>> www.finkproject.org/download/srcdist.php
>>>>
>>>> After doing the following and entering the last command to install, my 
>>>> machine was still, apparently installing (at 100% CPU capacity) 24 hours 
>>>> later. I finally killed the install. Can you help me figure out what when 
>>>> wrong? I can't believe the install could possibly take that long, even on 
>>>> my old Core Duo.
>>>>
>>>> $ xcode-select -switch /Applications/Xcode.app/Contents/Developer
>>>> $ sudo xcodebuild -license
>>>> $ cd $HOME/Downloads
>>>> # Downloaded the tar ball
>>>> $ tar -xvf fink-0.34-4.tar.gz
>>>> $ cd fink-0.34.4
>>>> $ ./bootstrap
>>>> $ /sw/bin/pathsetup.sh
>>>> $ fink selfupdate-rsync
>>>> $ fink index -f
>>>> # This command was still running 24 hours later at full CPU capacity
>>>> $ sudo fink install octave-atlas
>>>>
>>>> Thanks very much.
>>>>
>>>> Rich Shinn
>>>
>>> Fink displays a lot info to keep the user informed as it is doing its work. 
>>>  What was being displayed when you killed it?
>>>
>>> Ben
>>
>> Ben,
>>
>> I've attached a sample of the output. Just reams and reams of what looks to 
>> me like "typical" build output. It literally ran at 100% cpu capacity for 
>> well over 25 hours. Is it conceivable it could take that long? I'm thinking 
>> it got into some kind of loop in the build script that just kept trying to 
>> build it over and over again instead of erroring out properly.
>>
>> Thanks very much for any help you can provide. I'd very much like to get 
>> this working.
>>
>> Rich Shinn
> 
> I don't see anything unusual there.  I had a mac mini with a Intel Core 2 
> Duo, but it died last week.  So, I'm not able to check. 
> 
> I recommend you try again.  What you showed me doesn't look to have gotten to 
> Octave yet.  The good news is that many dependencies have probably already 
> been built, so the build you terminated isn't a total waste.
> 
> Ben
> 
> 

We tend to use the same build operations that you'd use when building a
package by hand, and those essentially never involve a loop.  However,
gcc47 _can_ look like a loop is occurring, because it repeats operations
in multiple stages.  And it takes a long time to build.  atlas is
another package that can look "loopy" and also takes a while.  Even so,
the build failure mode for both packages is to error out rather than to
continue indefinitely.

As I said before, builds can take a long time, depending on your
hardware, and you really need only be concerned if the build sits on
_one_ line for an extended period of time since there are failure modes
where an operation can lock up and never error out.  If things are
scrolling up, then be patient because the build is proceeding along.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]