Radioactive: Need a volunteer to compile OSX app

[zombie67]

http://radioactiveathome.org/boinc/forum_thread.php?id=35

There are apps for Linux and Windows, but not OSX. They don't have the HW or know-how. Do we have any team members or friends that can please do this?

They published the source code:

http://radioactiveathome.org/boinc/forum_thread.php?id=53

[Philadelphia]

http://radioactiveathome.org/boinc/forum_thread.php?id=35

There are apps for Linux and Windows, but not OSX. They don't have the HW or know-how. Do we have any team members or friends that can please do this?

They published the source code:

http://radioactiveathome.org/boinc/forum_thread.php?id=53

I'm quite sure this is above my pay grade, but if you/someone needs to 'run' something, I'd be happy to. If you/they need a coder, again, way above my pay grade.

[zombie67]

Bump!

[Slicker]

I'll take a look. Since the OS X is basically just an old version of GCC and setting up appropriate make files, it might not be too bad. Then again....
I don't have any way to test whether it works though as I don't have a sensor. Any OS X people available to help test?

[Fire$torm]

I'll take a look. Since the OS X is basically just an old version of GCC and setting up appropriate make files, it might not be too bad. Then again....
I don't have any way to test whether it works though as I don't have a sensor. Any OS X people available to help test?

Maybe someone with a sensor try a Virtualbox guest of Mac OS X Server?

[zombie67]

I have a sensor and a mac. If you can get me an app, I can test it. Oh, and an app_info.xml. I still can't figure out that thing after all these years.

[Slicker]

Compiled for x86_64 and OS X 10.5 or higher. Would have been nice if they had mentioned it needed files from libusb.org and that it needs the old version. Anyway, I hope it works...
The app can be found here:
http://boinc.thesonntags.com/collatz_test/download/radac_1.54_i686-apple-darwin.zip

[Fire$torm]

That was fast! :-bd

[Slicker]

That was fast! :-bd

OS X is really just BSD Unix with a custom GUI. The custom GUI part is what makes it a pain. Normally, since Apple uses the Gnu C Compiler (GCC) so generally, if it compiles on Linux and doesn't require graphics or low level system calls, OS X won't require too many changes. This one was a bit of a pain because of the USB devices and OS X uses their own USB API which isn't compatible with the code. Luckliy, someone had already written a generic USB library that interfaces with the OS X one (and likewise in Linux and Windows) and that is actually what the code uses. Would have been nice if that was mentioned somethere in their documentation. So I had to find, download, compile, and then figure out how to link it to a non-native OSX library. After doing that twice, I finally found the correct one. If it wasn't for that, it would have only taken and hour or two.

[Fire$torm]

OS X is really just BSD Unix with a custom GUI. The custom GUI part is what makes it a pain. Normally, since Apple uses the Gnu C Compiler (GCC) so generally, if it compiles on Linux and doesn't require graphics or low level system calls, OS X won't require too many changes. This one was a bit of a pain because of the USB devices and OS X uses their own USB API which isn't compatible with the code. Luckliy, someone had already written a generic USB library that interfaces with the OS X one (and likewise in Linux and Windows) and that is actually what the code uses. Would have been nice if that was mentioned somethere in their documentation. So I had to find, download, compile, and then figure out how to link it to a non-native OSX library. After doing that twice, I finally found the correct one. If it wasn't for that, it would have only taken and hour or two.

Cool. I take it that generic USB library is GPL? If so do you mind posting a link to it?

[zombie67]

Thanks! I'll give it a shot over the weekend!

[Slicker]

Cool. I take it that generic USB library is GPL? If so do you mind posting a link to it?

http://www.libusb.org

Note: The radioactive@home app uses the old 0.1 version, not the newer 1.0 version.

[Fire$torm]

http://www.libusb.org

Note: The radioactive@home app uses the old 0.1 version, not the newer 1.0 version.

Thank you. I'll give it a look at it and try to edjumacate myself. Lets see how long it take for that code to make my head spin.......

[zombie67]

Thanks! I'll give it a shot over the weekend!

Dang. I just tried it out, but got an immediate error. Here is the task:

http://radioactiveathome.org/boinc/result.php?resultid=161792


Stderr output

<core_client_version>6.12.35</core_client_version>
<![CDATA[
<message>
process exited with code 2 (0x2, -254)
</message>
<stderr_txt>

</stderr_txt>
]]>

[Slicker]

I may have to break down and buy a sensor in order to figure it out.

[zombie67]

I may have to break down and buy a sensor in order to figure it out.

I will be buying two more, when KK says go. I can lend you one at that time, if you like.

[Slicker]

Let's try this again....
I changed the c++ lib to be static.
I decided that even when linking to the .a file, it was really still using the dynamic library (.dylib file).
I named it correctly for OS X 10.5+

I included the libusb.dylib with its symbolic links. I think it should work in the project folder. If not, try putting them in /usr/local/lib. If that doesn't work, try otool -L to see what it reports.

http://boinc.thesonntags.com/collatz_test/download/radac_1.54_x86_64-apple-darwin

(Note: I deleted the previous one since it didn't work and the name changed)

[Slicker]

bump...
Tried the new version of the app yet?

[zombie67]

bump...
Tried the new version of the app yet?

Sorry! Will try it tomorrow.

[zombie67]

Let's try this again....
I changed the c++ lib to be static.
I decided that even when linking to the .a file, it was really still using the dynamic library (.dylib file).
I named it correctly for OS X 10.5+

I included the libusb.dylib with its symbolic links. I think it should work in the project folder. If not, try putting them in /usr/local/lib. If that doesn't work, try otool -L to see what it reports.

http://boinc.thesonntags.com/collatz_test/download/radac_1.54_x86_64-apple-darwin

(Note: I deleted the previous one since it didn't work and the name changed)

There is no new app_info.xml? Doesn't that need to change if the app name changes?

I made three changes. I replaced the file name in two places, and I changed the platform name to match what is in the new app name. Hope that is correct.


<app_info>
<app>
<name>radac</name>
<user_friendly_name>Radioactivity Monitor</user_friendly_name>
</app>
<file_info>
<name>radac_1.54_x86_64-apple-darwin</name>
<executable/>
</file_info>
<app_version>
<app_name>radac</app_name>
<version_num>154</version_num>
<platform>x86_64-apple-darwin</platform>
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>
<api_version>6.10.58</api_version>
<file_ref>
<file_name>radac_1.54_x86_64-apple-darwin</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

[zombie67]

Hmm. Still no joy.

http://radioactiveathome.org/boinc/result.php?resultid=171989


Stderr output
<core_client_version>6.12.35</core_client_version>
<![CDATA[
<message>
process exited with code 2 (0x2, -254)
</message>
<stderr_txt>

</stderr_txt>
]]>

[Slicker]

Since it isn't even getting to the first line of output which happens prior to anything else, my guess is that it can't find the usb library.

What do you get when you run:
otool -L <app_name>

[zombie67]

Since it isn't even getting to the first line of output which happens prior to anything else, my guess is that it can't find the usb library.

What do you get when you run:
otool -L <app_name>

% otool -L ./radac_1.54_x86_64-apple-darwin
otool: Command not found.

Maybe the command has a typo?

[Slicker]

snowleopard:Release jon$ otool -L ./radac_1.54_x86_64-apple-darwin
./radac_1.54_x86_64-apple-darwin:
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)


Maybe XCode needs to be installed or something to be able to use otool.

[zombie67]

Okay. I am downloading xcode now, and will let you know. 4gb+

[zombie67]

That helped some. At least the command works now.

%otool -L ./radac_1.54_x86_64-apple-darwin
./radac_1.54_x86_64-apple-darwin: is not an object file

[Slicker]

I think you are still testing the first version that was not an object file. Download the current one at http://boinc.thesonntags.com/collatz_test/download/radac_1.54_x86_64-apple-darwin.zip

[zombie67]

I think you are still testing the first version that was not an object file. Download the current one at http://boinc.thesonntags.com/collatz_test/download/radac_1.54_x86_64-apple-darwin.zip

I don't know how that would be possible, since they are different file names. x86_64 is the new one right? In any case, I will re-download it and try again.

Edit: Ah! This download has a lot more files. The second download (the one where you moved to x86_64) I tried earlier had only the executable. Did you rev it twice?

Edit 2: Working!


% !!
otool -L ./radac_1.54_x86_64-apple-darwin
./radac_1.54_x86_64-apple-darwin:
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

Edit 3:



Fri Jan 6 07:37:05 2012 | Radioactive@Home | update requested by user
Fri Jan 6 07:37:09 2012 | Radioactive@Home | Scheduler request completed: got 0 new tasks
Fri Jan 6 07:37:09 2012 | Radioactive@Home | No tasks sent
Fri Jan 6 07:37:09 2012 | Radioactive@Home | Message from server: Your app_info.xml file doesn't have a usable version of Radioactivity Monitor.


I noticed one line in the app_info.xml still had i686, so I tried changing that to x86_64. But that did not fix the issue.

[Slicker]

I noticed one line in the app_info.xml still had i686, so I tried changing that to x86_64. But that did not fix the issue.

Try taking out the platform completely. Since they have no OS X apps installed, it could be that the server is rejecting any OS X requests. So long as they have the anonymous platform enabled, you really don't need the platform element in the app_info.xml file.

It is hard to tell exactly how they have it configured since they have linux listed as nci but not windows. So, if that doesn't do it, try adding: <plan_class>nci</plan_class>

(for reference: http://boinc.berkeley.edu/wiki/Anonymous_platform)

[zombie67]

Ah, I see what is happening here. At start up, something is actually removing the app file! And it is happening at start up, not later when boinc requests work from the project. WTF? Why would BOINC delete a file like that?

--

Also, this message is further up (earlier) in the start up:

Fri Jan 6 11:53:41 2012 | Radioactive@Home | [error] State file error: missing application file usblib-0.1.4.dylib

I see that the actual file name included in the zip package is:

libusb-0.1.4.dylib

So I updated the app_info.xml to match the file name in a couple of places. Now the message says:

Fri Jan 6 12:06:14 2012 | Radioactive@Home | [error] State file error: missing application file libusb-0.1.4.dylib

[Slicker]

Ah, I see what is happening here. At start up, something is actually removing the app file! And it is happening at start up, not later when boinc requests work from the project. WTF? Why would BOINC delete a file like that?

--

Also, this message is further up (earlier) in the start up:

Fri Jan 6 11:53:41 2012 | Radioactive@Home | [error] State file error: missing application file usblib-0.1.4.dylib

I see that the actual file name included in the zip package is:

libusb-0.1.4.dylib

So I updated the app_info.xml to match the file name in a couple of places. Now the message says:

Fri Jan 6 12:06:14 2012 | Radioactive@Home | [error] State file error: missing application file libusb-0.1.4.dylib

Frakking dynamic libraries!

Try adding <copy_file/> to the <file_ref> element as shown here: http://boinc.berkeley.edu/trac/wiki/WrapperApp
That should cause it to copy the file to the slot folder so it can find it. I hope.

Another option is to put it where all the other dylib files are and then remove the reference from the app_info.xml

Didn't we run into this same issue with the Collatz CUDA app for OS X with the CUDA runtime dylib?

[zombie67]

Frakking dynamic libraries!

Try adding <copy_file/> to the <file_ref> element as shown here: http://boinc.berkeley.edu/trac/wiki/WrapperApp
That should cause it to copy the file to the slot folder so it can find it. I hope.

Another option is to put it where all the other dylib files are and then remove the reference from the app_info.xml

Didn't we run into this same issue with the Collatz CUDA app for OS X with the CUDA runtime dylib?

Heh. I don't recall. Maybe that was with crunch3r? Anyway, I am away for a few days. I will try your suggestions when I get back. And thanks for all the work on this. I know it's frustrating!

[zombie67]

I tried the <copy_file/>, but no success. No matter what, the app file gets deleted, the error message of "[error] State file error: missing application file libusb-0.1.4.dylib" shows in the event log.

Based on this:


% otool -L ./radac_1.54_x86_64-apple-darwin
./radac_1.54_x86_64-apple-darwin:
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

...I created the lib directory under /usr/local, and then just copied the three dylib files into that directory. No messing around with symbolic links.

Still no change in behavior. App deleted, error message in event log.

So I finally just removed the two sections in the app_info.xml that referenced the dylib. My app_info.xml now looks like this (includes the fix to the platform and the correction of the usblib/libusb typo) :


<app_info>
<app>
<name>radac</name>
<user_friendly_name>Radioactivity Monitor</user_friendly_name>
</app>
<file_info>
<name>radac_1.54_x86_64-apple-darwin</name>
<executable/>
</file_info>
<app_version>
<app_name>radac</app_name>
<version_num>154</version_num>
<platform>x86_64-apple-darwin</platform>
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>
<api_version>6.10.58</api_version>
<file_ref>
<file_name>radac_1.54_x86_64-apple-darwin</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>


...and it seems to be working! I am 8 minutes into a 30 min run time. If/when it validates, I will report back.

[zombie67]

Success!!!

http://radioactiveathome.org/boinc/result.php?resultid=196564

http://radioactiveathome.org/scripts/graph/draw.php?hostid=1168

One issue: The setting at the project is to run for .5 hours. It actually ran for 1.3 hours. Why would that be? I am running a second now to see if the issue is a one-off or not.

[zombie67]

One issue: The setting at the project is to run for .5 hours. It actually ran for 1.3 hours. Why would that be? I am running a second now to see if the issue is a one-off or not.


No change in run time with the second task. I will experiment with turning off various other projects, starting with Moo on the GPU.

[zombie67]

No change in run time with the second task. I will experiment with turning off various other projects, starting with Moo on the GPU.

No matter what, run time stays at 3x what it should. Very odd.

[Slicker]

Rather than check the actual time, the apps loops for a certain number of iterations. Maybe each iteration takes 3x as long on OS X. I don't know.

Since the usb dylib has to be manually installed, there's no way this can ever be set up as anything other than an opt app. Bummer.