I also noticed that just as with Mavericks the Paths aren't sticking in ML,
everytime I open a New terminal window I have to enter;
export PATH=/Developer/NVIDIA/CUDA-6.0/bin:$PATH
export DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-6.0/lib:$DYLD_LIBRARY_PATH
or the compiler can't find nvcc. This is starting to be annoying.

Uh, yes ... might try setting them permanently ... in your bash startup file.
https://www.digitalocean.com/community/tutorials/how-to-read-and-set-environmental-and-shell-variables-on-a-linux-vps

---

OSX Cuda toolkit 7.5 download is 1 GiB... this could take a little while, lol

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

toolkit samples building and running fine. next stop boinc libraries and Xbranch checkout

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

up to the same point, with missing INT_MIN and INT_MAX references. Will be able to go through the makefiles removing the dead file references, and then find where limits.h is supposed to be included and probably isn't.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I also noticed that just as with Mavericks the Paths aren't sticking in ML,
everytime I open a New terminal window I have to enter;
export PATH=/Developer/NVIDIA/CUDA-6.0/bin:$PATH
export DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-6.0/lib:$DYLD_LIBRARY_PATH
or the compiler can't find nvcc. This is starting to be annoying.

Uh, yes ... might try setting them permanently ... in your bash startup file.
https://www.digitalocean.com/community/tutorials/how-to-read-and-set-environmental-and-shell-variables-on-a-linux-vps

That's basically what Petri suggested. In Mavericks I have a file in the Home folder named .bashrc. When you enter nano ~/.bashrc it even pops up saying GNU nano 2.0.6 File: /Users/Tom/.bashrc and has the above path listed there. However I still get;
checking for nvcc... checking for nvcc... no
configure: error: NVCC compiler not found!
if I don't run the paths first. I suppose I'm missing some magic symbol(s) or something? Silly me just pasted the above lines in the file after creating the file.
BTW, /Developer/NVIDIA/CUDA-6.0/bin is even in the Configure line and the compiler Still can't find NVCC;
./configure --disable-graphics --disable-shared --enable-bitness=64 --enable-client --enable-static-client --enable-static --enable-dependency-tracking --enable-intrinsics --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-apple-darwin --with-boinc-platform=x86_64-apple-darwin --enable-fast-math CC="/usr/bin/clang" CPPFLAGS=" -DUSE_I386_OPTIMIZATIONS -DUSE_I386_XEON -DSETI7 -DUSE_SSE41 -O3 -I/Developer/NVIDIA/CUDA-6.0/bin -I/Users/Tom/sah_v7_opt/Xbranch/client/vector -I/usr/local/cuda/lib" LDFLAGS=" -mmacosx-version-min=10.8 -ldl /usr/lib/libz.1.dylib -mtune=core2 -march=core2 -fstrict-aliasing -framework Carbon" BOINCDIR="/Users/Tom/boinc"

While waiting for a CUDA App I decided to try this version 8 thing with OpenCL. I used the same configure line I used months ago on a fresh r3185 sah_v7_opt file I downloaded just after raistmer finished his last commit. I received MBv7_7.08r3185_ati5_ssse3_x86_64-apple-darwin, obviously a version 7 App. Is there also some magic needed to get a version 8 App?
Unfortunately MBv7_7.08r3185 isn't any faster than my old MBv7_7.08r2955 and still gives the same occasional Error, in fact, I believe it's Slower And gives more Errors, http://setiathome.berkeley.edu/result.php?resultid=4561265556

In el Capitan for command line building I had to create export entries in the .profile for the paths. For graphical samples that are dynamically linked I had to create an enviroment.plist file with setenv entries. For the running of an app itself (when it actually builds completely), then [graphical] applications can find the libraries. That won't do for standalone running of course, so eventually I'll work out how to add the origin into the exe (like before & on Linux)

First though a few things.
Near the top of x86_float4.h, there is an #if defined(__linux__) , that needs to become #if defined(__linux__) || ( defined(__APPLE__) && defined(__MACH__))
that one enables inclusion of the <climits> standard include

Next is a minor hamfist I injected fairly recently to print the driver version during Cuda initialisation. That api is only available on Windows, so needs disabling.

Last main thing is that depending on toolkit version the code generators present for old cuda devices ( compute capability 1.x ) will make the compile cack out. I may just switch to an older Cuda version in the morning, So I don;t have to deal with adding logic just yet. adding exceptions depending on if you're using Cuda 7+ or not will require some fiddling.

From there the CPU files seem to compile under clang here, and the first cuda file build, but then the build system starts trying to include something called 'Core Framework" which I'm not familiar with, and chokes nastily. I suspect some weird option somewhere, because the samples don;t do that. More digging tomorrow.

Can commit the minimal changes to get to that point, which may work on older XCode+Cuda already, after some rest (crossed eyes make for bad commits )

===================================================================
--- analyzeFuncs.cpp	(revision 3187)
+++ analyzeFuncs.cpp	(working copy)
@@ -70,7 +70,7 @@
 #endif
 #include "diagnostics.h"
 //#ifdef _WIN32
-#include "cuda/cudaAcc_utilities.h"
+//#include "cuda/cudaAcc_utilities.h"
 	#include "confsettings.h"
 //#endif //_WIN32
 // In order to use IPP, set -DUSE_IPP and one of -DUSE_SSE3, -DUSE_SSE2,
@@ -121,7 +121,7 @@
 #ifdef USE_CUDA 
    #include <cufft.h>
    #include <cuda_runtime_api.h>
-//   #include "cudaAcc_utilities.h"
+   #include "cuda/cudaAcc_utilities.h"
    #include "cuda/cudaAcc_data.h"
 #endif
 
Index: cuda/cudaAcceleration.cu
===================================================================
--- cuda/cudaAcceleration.cu	(revision 3187)
+++ cuda/cudaAcceleration.cu	(working copy)
@@ -41,8 +41,10 @@
 //#include "cudaAcc_CleanExit.h" // TODO: DELETE THAT, only for testing
 //#endif // not __linux__
 
-#include "cudaAcc_utilities.h"
+#include "cudaAcc_utilities.h"
+#ifdef _WIN32
 #include "nvapi_device.h"
+#endif
 
 unsigned cmem_rtotal = 0;
 
@@ -149,10 +151,11 @@
     if(numCudaDevices > 16) numCudaDevices = 16;
 
     fprintf(stderr, "setiathome_CUDA: Found %d CUDA device(s):\n", numCudaDevices);
-
+
+#ifdef _WIN32
 	nvGetDriverVersion();
 	fprintf(stderr,"nVidia Driver Version %s\n",ddverstring);
-
+#endif
     // Let's enumerate the CUDA devices avail and 
     // pick the best one.
     for(i=0; i < numCudaDevices; i++)
Index: vector/x86_float4.h
===================================================================
--- vector/x86_float4.h	(revision 3187)
+++ vector/x86_float4.h	(working copy)
@@ -39,7 +39,7 @@
 
 #include "x86_ops.h"
 
-#if defined(__linux__)
+#if defined(__linux__) || (defined(__APPLE__) && defined(__MACH__) )
 #include <climits>
 #include <cmath>
 #endif

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Thanks Jason, it appears we are making progress. I was going to build a version with cuda 6.0 for the older devices and test it with my GTS 250. Then I was going to try a version with cuda 6.5 and try it with my 750Ti, I have another 750Ti due in a couple days. When I try Petri's Modded files with cuda 6.0 I also receive errors saying the code is for Newer hardware, so, I suppose if the Mod actually works in OSX it can't be used with older devices. Oh well, time to buy a newer card I suppose.

I also noticed that just as with Mavericks the Paths aren't sticking in ML,
everytime I open a New terminal window I have to enter;
export PATH=/Developer/NVIDIA/CUDA-6.0/bin:$PATH
export DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-6.0/lib:$DYLD_LIBRARY_PATH
or the compiler can't find nvcc. This is starting to be annoying.

Uh, yes ... might try setting them permanently ... in your bash startup file.
https://www.digitalocean.com/community/tutorials/how-to-read-and-set-environmental-and-shell-variables-on-a-linux-vps

That's basically what Petri suggested. In Mavericks I have a file in the Home folder named .bashrc. When you enter nano ~/.bashrc it even pops up saying GNU nano 2.0.6 File: /Users/Tom/.bashrc and has the above path listed there. However I still get;

Yes you do! .bashrc is for a job shell [no terminal], not an interactive shell [yes terminal].
from link above about 3/4 of the way to the end

A session started as a login session will read configuration details from the /etc/profile file first. It will then look for the first login shell configuration file in the user's home directory to get user-specific configuration details.

It reads the first file that it can find out of ~/.bash_profile, ~/.bash_login, and ~/.profile and does not read any further files.

In contrast, a session defined as a non-login shell will read /etc/bash.bashrc and then the user-specific ~/.bashrc file to build its environment.

and perhaps "man bash"

---

From there the CPU files seem to compile under clang here, and the first cuda file build, but then the build system starts trying to include something called 'Core Framework" which I'm not familiar with, and chokes nastily. I suspect some weird option somewhere, because the samples don;t do that. More digging tomorrow.

A good bit of that is to support OSX
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/OSX_Technology_Overview/CoreServicesLayer/CoreServicesLayer.html
And the vast pile of it isn't needed for a *nix program, but if anything attempts to do anything like a normal Mac application then it gets included. IIRC there is a switch on xcode to tell it you are building a *nix program, not near my manuals to find it.

---

...It reads the first file that it can find out of ~/.bash_profile, ~/.bash_login, and ~/.profile and does not read any further files.

I don't see any of those files in my home folder, and I do have TinkerTool installed, so, I'll probably have to create a file later.

It's possible the configure line is used to specify a *nix App, I'm using,
./configure --disable-graphics --disable-shared --enable-bitness=64 --enable-client --enable-static-client --enable-static --enable-dependency-tracking --enable-intrinsics --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-apple-darwin --with-boinc-platform=x86_64-apple-darwin --enable-fast-math CC="/usr/bin/clang" CPPFLAGS=" -DUSE_I386_OPTIMIZATIONS -DUSE_I386_XEON -DSETI7 -DUSE_SSE41 -O3 -I/Developer/NVIDIA/CUDA-6.0/bin -I/Users/Tom/sah_v7_opt/Xbranch/client/vector -I/usr/local/cuda/lib" LDFLAGS=" -mmacosx-version-min=10.8 -ldl /usr/lib/libz.1.dylib -mtune=core2 -march=core2 -fstrict-aliasing -framework Carbon" BOINCDIR="/Users/Tom/boinc"

At one point it was trying to use Apple Accelerate and that was causing all sorts of addition thrashing, I removed that line and the thrashing stopped.

Yep, that seems likely, Since that Framework stuff looks totally gui/Apple stuff.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Yep, that seems likely, Since that Framework stuff looks totally gui/Apple stuff.

Book said best way was to start a new project in xcode, Mac OS application, command line tool. That will give you an empty hello world which you can use to compare all the build settings. Remember to hit the all button on the settings to see all of them. Hope that lets you find the one(s) that is being a PITA.

Wasn't paying super attention, but if it was a library, there is a blank template tool for that too.

@Tbar, yes you have to create the file. vi, vim, emacs, or some GUI tool.

---

Yeah, it looks like that may be the way to go. Will think about it. Not that many files when you leave out all the other platform bits

On a side note, poked at the nvcc coimpilaton lines to see if I could find what might be including the bogus framework.

nvcc -ccbin clang++ -I. -I.. -I../.. -I../../.. -I/Users/mac1/seti/Xbranch/db  -I/Users/mac1/seti/boinc/api -I/Users/mac1/seti/boinc/lib -m64  -Xcompiler -arch -Xcompiler x86_64  -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o cudaAcc_PowerSpectrum.o -c cudaAcc_PowerSpectrum.cu

Works fine to compile the one file to a .o ..... but ONLY after you comment out the cudaAcceleration.h include at the top of the source file first (otherwise same unrequested framework errors). So the gremlin blocking Cuda file compilation is in cudaAcceleration.h (or something included by it)

Will test a bit later hiow much easier a clean XCode project will be, and decide whether or not to fix the Mac part of the makefiles then. A lot will depend on what XCode feels like compared to the more or less fine but broken makefiles. Probably best I head straight toward gradle automation, ditching all the enviroments, lol, after v8 prelims are covered. Then can trigger from one set of gradle build files across the development fleet, and autoupload to a website while drinking beer (work setting up, but totally need that, lol )

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

n file included from analyzeFuncs.cpp:73: ./cuda/cudaAcc_utilities.h:4:37: error: unknown type name 'cudaError_t'
extern int cudaAcc_SafeCall_No_Sync(cudaError_t err, char* errMessage, char* file, int line);
^
./cuda/cudaAcc_utilities.h:5:34: error: unknown type name 'cudaError_t'
extern int cudaAcc_SafeCall_Sync(cudaError_t err, char* errMessage, char* file, int line);

I have added for my linux code some lines to the analyzeFuncs.cpp to get cudaError_t to be defined.

#define DO_SMOOTH

#if defined(__linux__)                 <<------ this here (needs __APPLE__)
#include <cuda_runtime_api.h>             <<--- gets the cudaErr_t and stuff
#include <unistd.h>                       <<--- stdlib linux stuff
#endif                                 <<------ ends here

#if defined(__APPLE__) || defined(__linux__) // Duplicate definitions in windows
  #include "version.h"
  const char *BOINC_PACKAGE_STRING="libboinc: "BOINC_VERSION_STRING;
//#else
#elif !defined(_WIN32) && !defined(__linux__)
   #include "config.h"
   const char *BOINC_PACKAGE_STRING="libboinc: "PACKAGE_STRING;
#endif


#undef PACKAGE_STRING
#undef PACKAGE

So maybe you need to #include <cuda_runtime_api.h> where ever you get compiler errors saying cudaErr_t not defined.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Yeah there was that (mostly because of a breakage I made putting some windows code in), then weird apple problems I've never seen before after that. .

I thought Apples were supposed to be all shiny and you just mash things with your forehead.... apparently not.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Looks like we'll be juggling and dodging v8 updates amidst the figuring out. Just something to factor into the process :)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I thought Apples were supposed to be all shiny and you just mash things with your forehead.... apparently not.

No, that's watermelons.

---

...Can commit the minimal changes to get to that point, which may work on older XCode+Cuda already, after some rest (crossed eyes make for bad commits )...

Any luck on some new commits? Should I just give up on CUDA Toolkit 6.0, the older hardware, and move on to 6.5?

...Can commit the minimal changes to get to that point, which may work on older XCode+Cuda already, after some rest (crossed eyes make for bad commits )...

Any luck on some new commits? Should I just give up on CUDA Toolkit 6.0, the older hardware, and move on to 6.5?

Status is juggling ready for v8 at the moment, which messes with the plan quite a bit.

Looking at some of the changes that Petri's put forward, some of which need to go straight into stock, 6.5 or newer would be a better choice where available (maybe 7+ if something he's going to be playing with soon works out). Will be isolating the midrange issues, putting those bits on hold along with my major infrastructure changes (for later).

We've been loosely comparing notes on various options from here. (of which there are many)

With preliminary v8 support enabled, and some tweaks in place, I'm hoping for simultaneous Mac+Linux+Win alpha, quickly followed by wider beta (at least for existing main v7 functionality). v8 support is going to depend on last minute changes at beta (Have been told there may be changes there, and could need to hold back until they iron out stock CPU + Splitters)

The Mac part is going to depend on if Xcode plays ball this week. For me, one more week of work before holidays start, then probably my once a year development burst can go from then until (hopefully) February. Since that burst didn't happen last year (for various reasons), most likely I'll stage the rampup. But historically practice is rapid incremental commits & alpha builds with a prescribed test sequence (rather than immediate deployment).

Will put a call out for specific cases that will need testing as things go, though for Mac-Cuda purposes the alpha test team probably amounts to you and I alone, as far as I can tell at the moment.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

...It reads the first file that it can find out of ~/.bash_profile, ~/.bash_login, and ~/.profile and does not read any further files.

Hmmm, ALL of those have the same effect. If I have one present the Compiler can Not find pkg-config and terminates immediately. Same thing in Mavericks and Mountain Lion. Wasted about 30 minutes trying to reinstall/fix pkg-config without any success, remove the file and it works the way it use to.

Now with CUDA Toolkit 6.5 I'm seeing about the same as with CUDA 6.0. In Mavericks I still get;

clang: error: no such file or directory: 'seti_cuda-analyzeFuncs_sse2.o'
clang: error: no such file or directory: 'seti_cuda-analyzeFuncs_sse3.o'
clang: error: no such file or directory: 'seti_cuda-analyzeFuncs.o'
clang: error: no such file or directory: 'cudaAcceleration.o'
clang: error: no such file or directory: 'cudaAcc_CalcChirpData.o'
clang: error: no such file or directory: 'cudaAcc_fft.o'
clang: error: no such file or directory: 'cudaAcc_gaussfit.o'
clang: error: no such file or directory: 'cudaAcc_PowerSpectrum.o'
clang: error: no such file or directory: 'cudaAcc_pulsefind.o'
clang: error: no such file or directory: 'cudaAcc_summax.o'
clang: error: no such file or directory: 'cudaAcc_transpose.o'
clang: error: no such file or directory: 'cudaAcc_utilities.o'
clang: error: no such file or directory: 'cudaAcc_autocorr.o'
make[2]: [seti_cuda] Error 1 (ignored)
...
/bin/cp seti_cuda setiathome_x41zc_x86_64-apple-darwin_cuda65
cp: seti_cuda: No such file or directory
make[2]: [setiathome_x41zc_x86_64-apple-darwin_cuda65] Error 1 (ignored)
strip setiathome_x41zc_x86_64-apple-darwin_cuda65
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: can't open file: setiathome_x41zc_x86_64-apple-darwin_cuda65 (No such file or directory)
make[2]: [setiathome_x41zc_x86_64-apple-darwin_cuda65] Error 1 (ignored)

In Mountain Lion the SSE errors are not there.
Also, with the Modified code it is just complaining about 'compute_10' now, but it has the same complaint with the Stock code;

/Developer/NVIDIA/CUDA-6.5/bin/nvcc -c cuda/cudaAcc_pulsefind.cu -o cudaAcc_pulsefind.o -Icuda -DHAVE_CONFIG_H -I. -I..  -I../db -I/Users/Tom/boinc -I/Users/Tom/boinc/api -I/Users/Tom/boinc/lib -I/Users/Tom/boinc/sched -I/Users/Tom/boinc/db --maxrregcount=32 -O3 --use_fast_math --ptxas-options="-v" --compiler-options "-g -O2 -I/Developer/NVIDIA/CUDA-6.5/include -ffast-math  -fno-common -DPIC -DHAVE_CONFIG_H  -fno-strict-aliasing" -m64  -gencode arch=compute_10,code=sm_10 -gencode arch=compute_11,code=sm_11 -gencode arch=compute_12,code=sm_12 -gencode arch=compute_13,code=sm_13 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=sm_21 -gencode arch=compute_20,code=compute_20 -I/Developer/NVIDIA/CUDA-6.5/include
nvcc fatal   : Unsupported gpu architecture 'compute_10'

So, is it possible to have it ignore 'compute_10'?
Also in Mavericks, I'm still getting the same Error with both codes;

In file included from analyzeFuncs.cpp:73:
./cuda/cudaAcc_utilities.h:4:37: error: unknown type name 'cudaError_t'
extern int cudaAcc_SafeCall_No_Sync(cudaError_t err, char* errMessage, char* file, int line);
                                    ^
./cuda/cudaAcc_utilities.h:5:34: error: unknown type name 'cudaError_t'
extern int cudaAcc_SafeCall_Sync(cudaError_t err, char* errMessage, char* file, int line);
                                 ^
./cuda/cudaAcc_utilities.h:6:43: error: unknown type name 'cudaError_t'
extern int cudaAcc_SafeCall_No_Sync_wExit(cudaError_t err, char* errMessage, char* file, int line);

make[2]: [cudaAcc_pulsefind.o] Error 1 (ignored)