Well, maybe, but something is causing the limits.h header file to not be processed. Some of those library files use a lot of macro tricks and it is possible someone has defined or undefined a reserved identifier they should not have. It might work with some compilers but not others!

You might want to ask on the Dev board as Charlie may have a correct fix for this.

Should be able to attempt to include cleaning up the OSX build situation as the v8 code goes in, adding in what you find. In a lot of cases the currently active codepaths don't ever use the functions in those cpu targeted files, so they can most likely in a number of cases come out of the build process entirely (and possibly be removed from the branch, as dead code).

The other helpful thing for distribution builds would be to add the switches into the makefile templates for adding the executable origin into the library search path of the executable. That's just so users don't need to install any Cuda toolkit(s)/ After build, that was using otool (or whatever it was called that I used, fair while back now), but should be injectable in the makefile linker settings instead."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.

/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $2 (); below.
Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
<limits.h> exists even on freestanding compilers. */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif

and see what happens (then if it helps, fix it properly later with other ifdefs). There could be other issues cascading from doing that, though I wouldn't expect limits.h to be too deep.

[Edit:]
#if defined(__STDC__) || defined(__clang__)
, or similar may work"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.

Well must be some other test inside limits.h, or the defines aren't there. Will be able to have a good look a bit later with beer stocks replenished.

[Edit:] note that by rights only the non sse named analyzefuncs has the Cuda code, and the required functions (though we build them with sse+ capability anyway, 64 bit having mandatory sse2 minimum). Something to go through the configure (and template makefile) lines and remove the dead file entries, as I did for Linux.

[Edit:] I am assuming later Cuda toolkit(s) and OSX environment switched over to clang entirely... something to verify that we aren't forced to using gcc if possible.

[Edit:] Confirmed for Cuda 7 onwards (at least), have to use clang+XCode

Well, maybe, but something is causing the limits.h header file to not be processed. Some of those library files use a lot of macro tricks and it is possible someone has defined or undefined a reserved identifier they should not have. It might work with some compilers but not others!

You might want to ask on the Dev board as Charlie may have a correct fix for this.

clang didn't exist afaik (or at least wasn't required by default on OSX + Cuda Toolkit). Will probably have to update the whole configure/make system to handle it correctly (now that I actually own a Mac)"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.

hahaha, well not at the time seti@home and the Cuda makefiles were setup. Now of course it's required on OSX+Cuda (unless you use a very old Cuda toolkit)

Clang came about, I believe roughly first release 2009 as a part of LLVM's success. Cuda started adopting LLVM components to replace the original compiler about Cuda 4. No idea when OSX+XCode switched from gcc to clang completely.

In any case, yeah this codebase is substantially older than Clang, even though primitive forms existed for later parts, they were far from 'standard'

Now it seems they are well ahead in adopting new C standards :D (that's a good thing and worthy migrating everything where practical)

[Edit:] note that gradle, as used mostly under android+java for now, could well pass popularity of the configure/make build tools, so that'll be another thing to consider integrating in time. [ ... at which point, if so, autosetup+configure+make would probably fall into a [further!] state of neglect, since gradle supports all the platforms, and detects compilers etc]"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.

Yes, clang is the issue. Their versions of headers are not the same as gcc/lvmm
I suspect a switch might be missing on the compile line or a macro requesting a specific handling is missing, so the wrong/incompatible library header files may be in use. Mind you I'm no expert.

gcc's version

/*
* Copyright (c) 1988, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)limits.h 8.3 (Berkeley) 1/4/94
*/
#ifndef _I386_LIMITS_H_
#define _I386_LIMITS_H_
#include <sys/cdefs.h>
#include <i386/_limits.h>
#define CHAR_BIT 8 /* number of bits in a char */
#define MB_LEN_MAX 6 /* Allow 31 bit UTF2 */
#if !defined(_ANSI_SOURCE) && (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))
#define CLK_TCK __DARWIN_CLK_TCK /* ticks per second */
#endif /* !_ANSI_SOURCE && (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */
/*
* According to ANSI (section 2.2.4.2), the values below must be usable by
* #if preprocessing directives. Additionally, the expression must have the
* same type as would an expression that is an object of the corresponding
* type converted according to the integral promotions. The subtraction for
* INT_MIN and LONG_MIN is so the value is not unsigned; 2147483648 is an
* unsigned int for 32-bit two's complement ANSI compilers (section 3.1.3.2).
* These numbers work for pcc as well. The UINT_MAX and ULONG_MAX values
* are written as hex so that GCC will be quiet about large integer constants.
*/
#define SCHAR_MAX 127 /* min value for a signed char */
#define SCHAR_MIN (-128) /* max value for a signed char */
#define UCHAR_MAX 255 /* max value for an unsigned char */
#define CHAR_MAX 127 /* max value for a char */
#define CHAR_MIN (-128) /* min value for a char */
#define USHRT_MAX 65535 /* max value for an unsigned short */
#define SHRT_MAX 32767 /* max value for a short */
#define SHRT_MIN (-32768) /* min value for a short */
#define UINT_MAX 0xffffffff /* max value for an unsigned int */
#define INT_MAX 2147483647 /* max value for an int */
#define INT_MIN (-2147483647-1) /* min value for an int */
#ifdef __LP64__
#define ULONG_MAX 0xffffffffffffffffUL /* max unsigned long */
#define LONG_MAX 0x7fffffffffffffffL /* max signed long */
#define LONG_MIN (-0x7fffffffffffffffL-1) /* min signed long */
#else /* !__LP64__ */
#define ULONG_MAX 0xffffffffUL /* max unsigned long */
#define LONG_MAX 2147483647L /* max signed long */
#define LONG_MIN (-2147483647L-1) /* min signed long */
#endif /* __LP64__ */
#define ULLONG_MAX 0xffffffffffffffffULL /* max unsigned long long */
#define LLONG_MAX 0x7fffffffffffffffLL /* max signed long long */
#define LLONG_MIN (-0x7fffffffffffffffLL-1) /* min signed long long */
#if !defined(_ANSI_SOURCE)
#ifdef __LP64__
#define LONG_BIT 64
#else /* !__LP64__ */
#define LONG_BIT 32
#endif /* __LP64__ */
#define SSIZE_MAX LONG_MAX /* max value for a ssize_t */
#define WORD_BIT 32
#if (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) || defined(_DARWIN_C_SOURCE)
#define SIZE_T_MAX ULONG_MAX /* max value for a size_t */
#define UQUAD_MAX ULLONG_MAX
#define QUAD_MAX LLONG_MAX
#define QUAD_MIN LLONG_MIN
#endif /* (!_POSIX_C_SOURCE && !_XOPEN_SOURCE) || _DARWIN_C_SOURCE */
#endif /* !_ANSI_SOURCE */
#endif /* _I386_LIMITS_H_ */

You have to admire the similarties despite the timespan on the dates. Mind you I also doubt there'd be any particular 'expert' familiar enough with both the differences and the seti codebase, but pretty confident (now I have some beer :) ) we can cobble something together."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.

Well the asmlib stuff is the awesome work by agner fog, which has no application in a Cuda only application. It'll be important in heterogeneous stuff, but for now you can safely say that it's a red herring"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.

You have to admire the similarties despite the timespan on the dates. Mind you I also doubt there'd be any particular 'expert' familiar enough with both the differences and the seti codebase, but pretty confident (now I have some beer :) ) we can cobble something together.

Well, they should be identical in effect as they are part of the language standard going back to K&R C. So seeing one of them undefined tends to mean something went horribly wrong. Perhaps the wrong language standards are being requested or are missing and I see a switch for a hosted vs. a cross platform compile in there as well.

As to _Bool, _int64, _int32 again these are reserved identifiers in the language standard. Something went wrong big time. Wrong language standard?

I'd suspect the make files first, or perhaps xcode default is overriding some compile time switch?

I'd suspect the make files first, or perhaps xcode default is overriding some compile time switch?

A combination of both seems likely to me. Will likely get a good chance to play with it soon. Well pre ansi K&R definitely had some major semantic differences, and Apple and NV seem to have their own ideas, so at this point I'd still keep options leaning towards anything's possible."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.

Well the asmlib stuff is the awesome work by agner fog, which has no application in a Cuda only application. It'll be important in heterogeneous stuff, but for now you can safely say that it's a red herring

It's possible that last Mountain Lion run was with Petri's Modded source, not sure but the list was from the config.log Not the compiler. I have switched over to ML, reinstalled the CUDA 6.0 Toolkit, and I noticed;

So, the Toolkit Works with GCC in ML.
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.

So, I ran the stock files with Clang and the compiler says;

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)

I ran the stock files with GCC and the results were;

checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for x86_64-apple-darwin-gcc... /usr/bin/gcc
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/gcc accepts -g... yes
checking for /usr/bin/gcc option to accept ISO C89... none needed
checking whether /usr/bin/gcc understands -c and -o together... yes
checking dependency style of /usr/bin/gcc... gcc3
...
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)

I guess that places the switchover of the toolkit to clang only, to more recent than I thought. Yes GCC and clang should compile the same code. Since it does so on Linux it'll just be a breakage in the darwin/osx/apple specific configuration. Not too hard to track down after work."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.