OSX Rundown

[sakkaku]

Status: OpenCL kernel issue/detection?
Status: OpenCL header compile problem - resolved in git
Status: Mac endian.h missing - resolved in git
Status: --enable-cpumining doesn't link

Greetings. I had an OSX machine I had lying around and figured I would test it and point out any issues. The initial portion of this deals with building the latest tagged version in the repository. With the last segment covering issues building against HEAD.

Requirements / Building

First up the method. I chose to make a brew formula since it doesn't detect the system's curl.

checking for LIBCURL... no
configure: error: Missing required libcurl dev >= 7.18.2

HomeBrew has a curl package but it doesn't install globally to avoid conflicts. So I just made a formula for homebrew to get around that small issue with a forced breakpoint to test the binary incase it works.

Without the formula you can install all the dependencies with

brew install autoconf automake pkg-config libtool jansson yasm libusb

automake was missing from the dependencies list in the readme causing it to error out on aclocal being missing. Also the AMD APP SDK link is a 404 now so you may need to fix that.

CPU Mining

With cpumining enabled there is a linker error that I don't know how to fix. This happens when building with both clang and gcc-llvm.

GPUs

GPUs don't seem to work. I only have a shitty nvidia 9400 on this mac mini so I wasn't expecting much anyway. Upon connecting to a pool it throws:

[2012-12-16 16:17:31] Probing for an alive pool
[2012-12-16 16:17:32] Long-polling activated for http://mine.btcguild.com:8332/LP/
[2012-12-16 16:17:36] Pool 0 http://mine.btcguild.com:8332 alive
[2012-12-16 16:17:36] Error: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2012-12-16 16:17:36] Thread 0 failure, exiting
[2012-12-16 16:17:36] Disabling extra threads due to dynamic mode.
[2012-12-16 16:17:36] Tune dynamic intensity with --gpu-dyninterval
[2012-12-16 16:17:36] Error: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2012-12-16 16:17:36] Thread 1 failure, exiting
[2012-12-16 16:18:39] Device 0 idle for more than 60 seconds, GPU 0 declared SICK!

Then it loops those messages unless you explicitly disable the GPU. Since most OSX systems don't have a GPU worthwhile this isn't really necessary IMO.

HEAD Issues

When building against head there is an issue with the endian detection.

In file included from miner.c:55:
./miner.h:155:12: fatal error: 'endian.h' file not found
   #include <endian.h>

miner.h was fairly weird as it handles it fine around 122-127 with:

#if HAVE_BYTESWAP_H
  #include <byteswap.h>
#elif defined(USE_SYS_ENDIAN_H)
  #include <sys/endian.h>
#elif defined(__APPLE__)
  #include <libkern/OSByteOrder.h>

then fails starting at 146 with it falling back on endian.h by default.

#ifdef WIN32
  #ifndef __LITTLE_ENDIAN
    #define __LITTLE_ENDIAN 1234
    #define __BIG_ENDIAN    4321
  #endif
  #ifndef __BYTE_ORDER
    #define __BYTE_ORDER __LITTLE_ENDIAN
  #endif
#else
  #include <endian.h>

Also CL/cl.h produces a ton of errors. Starting with:

CC       bfgminer-miner.o
In file included from miner.h:22,
             from util.c:51:
CL/cl.h: In function ‘clCreateSubDevices’:
CL/cl.h:595: error: expected declaration specifiers before ‘CL_API_SUFFIX__VERSION_1_2’

or Clang

CC       bfgminer-miner.o
In file included from util.c:51:
In file included from ./miner.h:22:
    ./CL/cl.h:595:80: error: expected function body after function declarator
               cl_uint *                            /* num_devices_ret */) CL_API_SUFFIX__VERSION_1_2;

[luke-jr]

If it doesn't install cURL globally, where does it install it? The purpose of autoconf is to detect things like this, so it'd be nice to support it.

Regarding CPU mining, I'm guessing there's an ABI issue involving the leading underscore. CalcSha256_x64_sse4 is defined in x86_64/sha256_sse4_amd64.asm. Probably there's some GNUism we need to tell GCC not to use the leading underscore for the assembly functions.

Regarding OpenCL mining, did you try any of the GPU options, such as other kernels?

What do you consider "latest tagged" to be? There haven't been any changes to endian or OpenCL handling since 2.10.0.

[sakkaku]

Regarding OpenCL mining, did you try any of the GPU options, such as other kernels?

Doh. Yeah I went back and diablo worked fine. I assume the others are patched to take advantage of ATI cards hence the crashing.

If it doesn't install cURL globally, where does it install it? The purpose of autoconf is to detect things like this, so it'd be nice to support it.

haha. welcome to OSX. You will probably gag at this.

mithril:Formula sakkaku$ locate curl.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/include/curl/curl.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/curl/curl.h

and

/usr/bin/curl
/usr/bin/curl-config
/usr/lib/libcurl.3.dylib
/usr/lib/libcurl.4.dylib
/usr/lib/libcurl.dylib

the brew formula fixes this easily

What do you consider "latest tagged" to be? There haven't been any changes to endian or OpenCL handling since 2.10.0.

Doh, I was pulling against 2.3.1-2 as I didn't scroll down far enough to see the tag formats had changed >_<

Changing to 2.10 and 2.9.5 results in it stalling at

bash-3.2$ make
/usr/bin/make  all-recursive
Making all in lib
/usr/bin/make  all-recursive
make[4]: Nothing to be done for `all-am'.
Making all in ccan
make[2]: Nothing to be done for `all'.
Making all in libblkmaker
make[2]: *** No rule to make target `all'.  Stop.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

of course libblkmaker/ is empty >_< Anyway a git clone to fix that and we are back to CL/cl.h errors and endian issue.

[luke-jr]

I think they shouldn't patch unless an AMD card is detected, so maybe something to check into still... Can you post the OpenCL info for your card from --debug?

Looks like you didn't re-run autogen.sh after changing to newer tags. That uses git to populate libblkmaker. ;)

[sakkaku]

Ok to fix the endian issue add a line to detect OSX and do nothing.

#ifdef WIN32
  #ifndef __LITTLE_ENDIAN
    #define __LITTLE_ENDIAN 1234
    #define __BIG_ENDIAN    4321
  #endif
  #ifndef __BYTE_ORDER
    #define __BYTE_ORDER __LITTLE_ENDIAN
  #endif
#elif defined(__APPLE__)
  // do nothing as <libkern/OSByteOrder.h> has been included above
#else
  #include <endian.h>
#endif

[sakkaku]

Looks like you didn't re-run autogen.sh after changing to newer tags. That uses git to populate libblkmaker. ;)

It errors out because the zip files from the tags don't include the .git directory >_<

[luke-jr]

Yeah, don't grab zip files from GitHub... ;)
Official source packages are at http://luke.dashjr.org/programs/bitcoin/files/bfgminer/ (and have libblkmaker pre-populated)

Can you test this code:

#if !(defined(__BYTE_ORDER) && defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN))
  #ifdef WIN32
    #ifndef __LITTLE_ENDIAN
      #define __LITTLE_ENDIAN 1234
      #define __BIG_ENDIAN    4321
    #endif
    #ifndef __BYTE_ORDER
      #define __BYTE_ORDER __LITTLE_ENDIAN
    #endif
  #else
    #include <endian.h>
  #endif
#endif

[sakkaku]

Hmm that causes the file to be included still. Which means those symbols aren't added >_<

I'm gonna go jump off a cliff now and do some more research.

[sakkaku]

This works. For some reason __LITTLE_ENDIAN__ was defined but __BIG_ENDIAN__ was not.

#include <stdio.h>
#include <machine/endian.h>

#ifdef BYTE_ORDER
  #warning "Byte Order is Valid"
#endif

#ifdef BIG_ENDIAN
  #warning "Big Endian is Valid"
#endif

#ifdef LITTLE_ENDIAN
  #warning "Little Endian is Valid"
#endif

#define __LITTLE_ENDIAN LITTLE_ENDIAN
#define __BIG_ENDIAN BIG_ENDIAN
#define __BYTE_ORDER BYTE_ORDER

int main(void)
{
    printf("%i, %i, %i\n", __LITTLE_ENDIAN, __BIG_ENDIAN, __BYTE_ORDER);
}

Yay \o/

mithril:Desktop sakkaku$ gcc test.cpp 
test.cpp:5:4: warning: #warning "Byte Order is Valid"
test.cpp:9:4: warning: #warning "Big Endian is Valid"
test.cpp:13:4: warning: #warning "Little Endian is Valid"

mithril:Desktop sakkaku$ ./a.out 
1234, 4321, 1234

Thus this should work:

#if defined(WIN32)
  #ifndef __LITTLE_ENDIAN
    #define __LITTLE_ENDIAN 1234
    #define __BIG_ENDIAN    4321
  #endif
  #ifndef __BYTE_ORDER
    #define __BYTE_ORDER __LITTLE_ENDIAN
  #endif
#elif defined(__APPLE__)
  #include <machine/endian.h>
  #define __LITTLE_ENDIAN LITTLE_ENDIAN
  #define __BIG_ENDIAN BIG_ENDIAN
  #define __BYTE_ORDER BYTE_ORDER
#else
  #include <endian.h>
#endif

[sakkaku]

Is there a specific reason for CL/ being included with the project?

I would assume that Linux and OSX would have their own headers (though some it is of course OpenCL/cl.h on apple and CL/cl.h on other platforms).

Also looks like some copying of the header to driver-opencl.c and ocl.c. Either that or I can't read tonight (which is probable).

[luke-jr]

CL/ is included because it is a standard interface and the headers are not provided by operating systems (at least not Linux). AMD and nVidia have their own OpenCL headers, but BFGMiner is portable at runtime by dynamically linking to any compliant OpenCL implementation. If I compiled releases against AMD's headers/library, BFGMiner might not run without the same environment, and the binary might include AMD code in violation of the GPL terms. The current arrangement is GPL-compliant and does not use any non-free software to build.

[sakkaku]

https://gist.github.com/6533a4e260cea8fbd4e3/

Any idea what is going on here?

Looking at CL/cl.h and OpenCL/cl.h it looks like the stuff that errors isn't in the OS provided headers....

clCreateSubDevices, clRetainDevice, clReleaseDevice, clCreateImage, clCreateProgramWithBuiltInKernels, etc. All are OpenCL 1.2 specifications.

[sakkaku]

Oooh. CL_API_SUFFIX__VERSION_1_2 is not defined under the __APPLE__ conditional on line 48.

Here is the section of the header in the 10.8 API:

#ifdef __APPLE__
    #define CL_EXTENSION_WEAK_LINK       __attribute__((weak_import))
    #define CL_API_SUFFIX__VERSION_1_0                  AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER
    #define CL_EXT_SUFFIX__VERSION_1_0                  CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER
    #define CL_API_SUFFIX__VERSION_1_1                  AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
    #define GCL_API_SUFFIX__VERSION_1_1                 AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
    #define CL_EXT_SUFFIX__VERSION_1_1                  CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
    #define CL_EXT_SUFFIX__VERSION_1_0_DEPRECATED       CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_7
    #define CL_USE_DEPRECATED_OPENCL_1_1_APIS           1

    #ifdef AVAILABLE_MAC_OS_X_VERSION_10_8_AND_LATER
        #define CL_API_SUFFIX__VERSION_1_2              AVAILABLE_MAC_OS_X_VERSION_10_8_AND_LATER
        #define GCL_API_SUFFIX__VERSION_1_2             AVAILABLE_MAC_OS_X_VERSION_10_8_AND_LATER
        #define CL_EXT_SUFFIX__VERSION_1_2              CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_8_AND_LATER
        #define CL_EXT_SUFFIX__VERSION_1_1_DEPRECATED   CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_8
    #else
        #warning  This path should never happen outside of internal operating system development.  AvailabilityMacros do not function correctly here!
        #define CL_API_SUFFIX__VERSION_1_2              AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
        #define GCL_API_SUFFIX__VERSION_1_2             AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
        #define CL_EXT_SUFFIX__VERSION_1_2              CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
        #define CL_EXT_SUFFIX__VERSION_1_1_DEPRECATED   CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER
    #endif
#else
    #define CL_API_SUFFIX__VERSION_1_0
    #define CL_API_SUFFIX__VERSION_1_1
    #define CL_API_SUFFIX__VERSION_1_2
    #define CL_EXTENSION_WEAK_LINK
#endif

[luke-jr]

Hmm, does the OpenCL problem solve if you update the CL headers from http://www.khronos.org/registry/cl/ ?

[sakkaku]

Wow. That was a little hacky. In cl.h you have to change

#ifdef __APPLE__
  #include <OpenCL/cl_platform.h>
#else
  #include "CL/cl_platform.h"
#endif

to

#include "cl_platform.h"

It was still erroring on CL_EXT_PREFIX__VERSION_1_1_DEPRECATED until I caught that. >_<

Now we are back to the errors I was getting before I forcefully removed the copied headers from driver-opencl and ocl to use the system's opencl (of which that was a fairly bad idea as it didn't work heh).

*: error: redefinition of '*' as different kind of symbol

or if you enjoy GCCs error syntax.

ocl.c:41: error: ‘clGetPlatformIDs’ redeclared as different kind of symbol
CL/cl.h:569: error: previous declaration of ‘clGetPlatformIDs’ was here

https://gist.github.com/743354baace43ffd92c3/fbca133d2b648ce3cd84050a96e74fedb10e08a4

I assume the redefinitions inside driver_opencl.c and ocl.c will need to be updated to work with the newer opencl headers. It looks like you could throw both sets into one file with a preprocessor directive to omit extern for one set and help ease maintenance.

[luke-jr]

Does the OpenCL problem solve if you update the CL headers from http://www.khronos.org/registry/cl/ ?

Are the __BYTE_ORDER macros defined if you include <sys/param.h>? Can you post the output of this:

cpp -dM <<< '#include <sys/param.h>' | grep ENDIAN

[sakkaku]

Does the OpenCL problem solve if you update the CL headers from http://www.khronos.org/registry/cl/ ?

No. Specifically it causes a different set of problems which I think is do to the mismatch between the new headers and definitions in driver_opencl.c and ocl.c. The errors are posted here.

 mithril:Desktop sakkaku$ cpp -dM <<< '#include <sys/param.h>' | grep ENDIAN
 #define _I386__ENDIAN_H_ 
 #define _SYS__ENDIAN_H_ 
 #define __DARWIN_PDP_ENDIAN 3412
 #define __DARWIN_BYTE_ORDER __DARWIN_LITTLE_ENDIAN
 #define __DARWIN_BIG_ENDIAN 4321
 #define PDP_ENDIAN __DARWIN_PDP_ENDIAN
 #define BIG_ENDIAN __DARWIN_BIG_ENDIAN
 #define __DARWIN_LITTLE_ENDIAN 1234
 #define __LITTLE_ENDIAN__ 1
 #define _BSD_MACHINE_ENDIAN_H_ 
 #define LITTLE_ENDIAN __DARWIN_LITTLE_ENDIAN

mithril:Desktop sakkaku$ cpp -dM <<< '#include <sys/param.h>' | grep BYTE_ORDER
#define __DARWIN_BYTE_ORDER __DARWIN_LITTLE_ENDIAN
#define BYTE_ORDER __DARWIN_BYTE_ORDER

[luke-jr]

Please pull and check that the new endian/byteswap checks work on Mac.

[luke-jr]

Also please report on the updated CL/* in git too.

[sakkaku]

  CCLD     bfgminer
Undefined symbols for architecture x86_64:
  "_OSSwapInt32", referenced from:
      _share_diff in bfgminer-miner.o
      _submit_work_thread in bfgminer-miner.o
      _gen_stratum_work in bfgminer-miner.o
      _roll_work in bfgminer-miner.o
      _work_decode in bfgminer-miner.o
      _calc_diff in bfgminer-miner.o
      _calc_midstate in bfgminer-miner.o
      ...
  "_OSSwapInt64", referenced from:
      _share_diff in bfgminer-miner.o
      _gen_stratum_work in bfgminer-miner.o
      _calc_diff in bfgminer-miner.o
      _scrypt_outputhash in bfgminer-scrypt.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bfgminer] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Doesn't work >_<. Looks like it isn't linking to the byteswap functions.

The OpenGL stuff seems to have worked as it compiles if I use the miner.h header I had.

[luke-jr]

Looks like we're getting closer, though! Can you pastebin your config.log ?

[sakkaku]

Posting that into gist almost crashed my browser... I'll just post it to dropbox, config.log.

[luke-jr]

Hmm, this is odd. When configure links its test, it succeeds, but then not when the build system does it.
Please pastebin the output of: make AM_V_CCLD=''

[sakkaku]

Please pastebin the output of: make AM_V_CCLD=''

https://gist.github.com/3efe5ef1d8df348b701e

Doesn't seem to be anything diff

[luke-jr]

brew: superenv removed: -g -O2

Can you stop it from removing -O2? :)

[sakkaku]

Can you stop it from removing -O2? :)

Maybe. A lot of stuff is lolundocumented. I just recently found the --use-llvm and --use-clang flags so >_<

[luke-jr]

How about trying to build it without brew again?

./configure --enable-scrypt 'PKG_CONFIG_PATH=/usr/local/opt/curl/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/Library/ENV/pkgconfig/mountain_lion'

[sakkaku]

Same errors outside of brew even though that configure line worked.

https://gist.github.com/3efe5ef1d8df348b701e/

-O2 is an optimizer flag and not too important. Like omitting the radiator in a car, or never changing the oil; it still sorta runs right?

[luke-jr]

Can you post the config.log from that one? Looks different...

I am suspecting -O2 related in case of something weird going on with the function being inlined. Without optimization, inlines are ignored...

[luke-jr]

Really? I wasn't expecting it to be that easy! CPU mining actually works and all?
For testing, you can use -o luke.dashjr.org/tmp/code/earlyshare2.json -O x (if it works, you will see a Rejected share pretty quick)

[fabulouspanda]

I tested it with my p2pool node and got accepted shares and now with your url rejected shares so it should be working fine! It is a lot slower than poolers cpu miner though…

[ibd1279]

Cannot say I am as lucky:
git clean -xdf && git reset --hard && git fetch origin && git pull origin bfgminer && ./autogen.sh && ./configure --enable-cpumining --enable-scrypt PKG_CONFIG_PATH=/usr/local/opt/curl/lib/pkgconfig:/usr/local/opt/jansson/lib/pkgconfig && make
...
sha256_xmm_amd64.asm:317: error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers.

using yasm 1.2; what version should I be using?

[luke-jr]

@ibd1279 Does this patch help? http://codepad.org/p6fXPB9P

[ibd1279]

That gets me a little further, but then I get this one:
sha256_sse4_amd64.asm:239: error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers.

I tried adding the qword onto what I think is the problem on that one (g_4sha256_k -- yasm error messages seem especially unhelpful), but then I get:
sha256_sse4_amd64.asm:239: error: invalid size for operand 2

[luke-jr]

Are you using the latest git? Line 239 doesn't have any code in it...

[ibd1279]

https://github.com/luke-jr/bfgminer/blob/bfgminer/x86_64/sha256_sse4_amd64.asm#L239 ??

239 is the unroll. That is what I meant by the yasm error messages are not very helpful. Anything that happens in that macro gets spit out where the unroll happens. That is why I am not sure if I was putting the qword even in the right place.

[luke-jr]

Ah, nasty. I suppose you could manually unroll the loop (even just once should expose the error)?

[ibd1279]

sha256_sse4_amd64.asm:237: error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers.

line 237 is: movntdqa xmm1, g_4sha256_k[rax*4]

sha256_sse4_amd64.asm:237: error: invalid size for operand 2
line 237 is: movntdqa xmm1, qword g_4sha256_k[rax*4]

My assembly-fu is somewhere between "non-existant" and "I think I did a mov ax, bx thing once at band camp", but is this expected to use C-style pointer math? as in ((void*)((char*)g_4sha256_k) + (rax4)) or is it supposed to some weird assembly/pointer math thing like ((void)((char*)g_4sha256_k) + ((qword)(rax*4)). I always thought square brackets meant "fetch the value from this address", and I don't remember identifier[offset] syntax... but my assembly-fu just plain sucks.

Ugh, escaping the dereference/pointer op sucks.

[luke-jr]

Try this: http://codepad.org/TyaNGJIn

[ibd1279]

That builds, but it doesn't love it running:
[2013-05-31 00:51:24] "sse2_64" : benchmarking algorithm ...Segmentation fault: 11
when I specify -a sse4_64, I also get a segfault: 11.

[fabulouspanda]

Sorry to have misled you before - I'd compiled without yasm so it didn't kick up a fuss.

[fabulouspanda]

I was able to build bfgminer a few days ago from git with ./configure PKG_CONFIG_PATH=/Applications/MacMiner.app/Contents/Resources/curl/lib/pkgconfig:/Applications/MacMiner.app/Contents/Resources/jansson/lib/pkgconfig --enable-scrypt --enable-cpumining CPPFLAGS="-I/uthash-master/src/"
(without yasm) - but now i'm getting segfault 11 from compiled git or 3.1
I tried compiling without cpu, without avalon but no luck.

there were just a few errors during compilation, mostly unused variables, and
driver-avalon.c:939: warning: format ‘%06ld’ expects type ‘long int’, but argument 6 has type ‘__darwin_suseconds_t’

/usr/bin/ranlib: file: libgnu.a(dummy.o) has no symbols
ranlib: file: libgnu.a(dummy.o) has no symbols

[luke-jr]

@fabulouspanda Can you bisect this?

[fabulouspanda]

It was this commit that broke it:
564fa6e

[luke-jr]

Not if you compile without CPU... O.o

[fabulouspanda]

I was compiling without CPU. Go figure.

[fabulouspanda]

hang on, it seems like it works if I specifically state --disable-cpu although it says it's disabled after configure either way let me make sure i've not done something wrong here

[fabulouspanda]

Sorry I was running the wrong binary there probably. I just installed from git and it looks as though one of your recent commits has fixed it. Thanks!

[khera]

the 3.1.0 released tarball compile crashes with segfault every time I run it. Traced it down to this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000078c37108
0x00007fff8d7902f7 in flockfile ()
(gdb) where
#0 0x00007fff8d7902f7 in flockfile ()
#1 0x00007fff8d792b18 in fseek ()
#2 0x0000000100031a1b in file_contents (filename=0x7fff5fbfeb40 "poclbm130302.cl", length=0x7fff5fbfeaf4) at ocl.c:245
#3 0x000000010003275d in initCl (gpu=1606414192, name=0x7fff5fbfef70 "��_��", nameSize=140734799802224) at ocl.c:709
#4 0x000000010002f098 in opencl_thread_prepare (thr=0x0) at driver-opencl.c:1595
#5 0x00000001000170da in main (argc=1, argv=0x7fff5fbff9c0) at miner.c:9074
(gdb) quit

However, if I build from the git HEAD, it seemingly works fine.

I use brew to install all the dependencies and then configured with this:

env LIBCURL_LIBS="-L/usr/local/Cellar/curl/7.30.0/lib -lcurl" LIBCURL_CFLAGS=-I/usr/local/Cellar/curl/7.30.0/include ./configure

For what its worth, I have shared a brew for this, which is currently at 3.0.2 since 3.1.0 will not run. You can access it with "brew tap khera/homebrew-vick" then simply 'brew install bfgminer --HEAD' to get the latest from git. I try to keep it updated so normal brew upgrade should keep you up to date.

[caktux]

Getting Unable to open poclbm130302.cl or ./poclbm130302.cl for reading, I think open_bitstream() needs some attention.

[fabulouspanda]

I'm having trouble making 3.1.2

In file included from fpgautils.c:775: iospeeds.h: In function ‘tiospeed_t’: iospeeds.h:22: error: ‘B460800’ undeclared (first use in this function) iospeeds.h:22: error: (Each undeclared identifier is reported only once iospeeds.h:22: error: for each function it appears in.) iospeeds.h:23: error: ‘B921600’ undeclared (first use in this function) iospeeds.h:25: error: ‘B576000’ undeclared (first use in this function) iospeeds.h:26: error: ‘B1152000’ undeclared (first use in this function) iospeeds.h:28: error: ‘B1500000’ undeclared (first use in this function) iospeeds.h:29: error: ‘B3000000’ undeclared (first use in this function) iospeeds.h:31: error: ‘B500000’ undeclared (first use in this function) iospeeds.h:32: error: ‘B1000000’ undeclared (first use in this function) iospeeds.h:33: error: ‘B2000000’ undeclared (first use in this function) iospeeds.h:34: error: ‘B4000000’ undeclared (first use in this function) iospeeds.h:36: error: ‘B2500000’ undeclared (first use in this function) iospeeds.h:37: error: ‘B3500000’ undeclared (first use in this function) make[2]: *** [bfgminer-fpgautils.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

[ibd1279]

I was having the same problem as fabulouspanda, but it appears fixed in the latest pull.

[sakkaku]

I got my jalapeño in today. Only caveat is you need to manually specify the device(s) when starting.

You may also need to install the x64 drivers from here. I am not 100% on this though.

Seems to be getting fairly fast speeds while running cool.

[fabulouspanda]

You do need the ftdi usb serial drivers but the 3.1.3 version i pulled from github for the latest beta version of MacMiner (a few fixes from the released 3.1.3) allows you to use -S all rather than specifying the device, so if that doesn't work for you something's wrong in 3.1.4 - I haven't checked it yet though and not sure whether you tried that? I'm using a jala too.

[sakkaku]

-S all works. Yay

[sakkaku]

I'm gonna go ahead and close the super mega OSX thread.

Good job to all the devs for keeping OSX a usable platform.