Yes, I have the same problem, it tries to find the *.cl files in the current directory, should probably try to do basename argv[0] instead.

This leads me back to the issue that cgminer does not use ncurses output and segfaults on exit when run fromusr/local/bin/ which is where it installs itself (make install). Please correct me if I'm wrong, but the executable should look for the *.cl files in either its own directory (not the current user's directory) and/or using the system paths, no?

This was an idea, not something that is actually implemented. Currently, you need to create individual JSON configs for each pool and pass them with -c parameters.

I use a windows batch file to run it.

anyone windows can use it too.
pastes this into bat file you make inside the cgminer directory


I haven't been able to figure out kernel, work size GPU and CPU threads yet though.
I need to figure out how many threads my GPU has first though.

oh just figured out GPU threads and worksize. -g 10 -w 256

MAN, that works good!

I'm not having much luck compiling this on Fedora 15.  This is where make craps out:

make[2]: Entering directory `/usr/src/cgminer-1.3.1'
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing  -I./lib -I./lib  -DHAS_YASM -g -O2 -MT cgminer-main.o -MD -MP -MF .deps/cgminer-main.Tpo -c -o cgminer-main.o `test -f 'main.c' || echo './'`main.c
main.c: In function âload_configâ:
main.c:605:2: error: too many arguments to function âjson_load_fileâ
/usr/include/jansson.h:162:9: note: declared here
make[2]: *** [cgminer-main.o] Error 1
make[2]: Leaving directory `/usr/src/cgminer-1.3.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/cgminer-1.3.1'
make: *** [all] Error 2


I looked at the MakeFile and if I edit it as follows:

-#JANSSON_INCLUDES =
-JANSSON_INCLUDES = -I$(top_srcdir)/compat/jansson
+JANSSON_INCLUDES =
+#JANSSON_INCLUDES = -I$(top_srcdir)/compat/jansson


then I can compile successfully, but will get this upon running cgminer:

[2011-07-20 12:41:07] Error: Getting Device IDs (num)


I am running an nVidia card at the moment, but poclbm and phoenix can each access it.  Also, for the record, 'rpm -qfusr/include/jansson.h' returns these packages:

jansson-devel-1.2-1.fc13.x86_64
jansson-devel-1.2-1.fc13.i686


On a side note, cgminer seems to use a lot of CPU for GPU mining in Windows, and all found hashes get rejected.  Same nVidia card, and I know phoenix gets a lot of rejects too if I use BFI_INT.  I saw that BFI_INT is used in the original post, but I didn't see any way to disable it in the parameters.  Is it possible to disable it, or is this miner meant for ATI only?

Current version (d987006cd82900ecb1e6d9d2743d832a595b0c43) segfaults for me with two pools and --load-balance --no-longpoll:


It also seems that things get mixed up when one pool supports long polling, while the other one does not.

I suggest you don't give it a -g parameter at all. The default of 2 is often the best, but feel free to experiment.

Compile attempt on a Mac with the latest changes from git:

These cards weren't purchased for mining...  They are 9500GT cards (I know they won't do much, I am just experimenting), I experienced infinite rejects using the windows binary which I downloaded (as opposed to compiling myself), and was unable to test on Linux thus far (because it couldn't recognize the card), but when I use BFI_INT on phoenix, I also get infinite rejects, so I just figured it might be related, could be the age of the card and a lack of testing against it or something.

EDIT:  I see 100% of one core used by poclbm and phoenix in Linux, so if this does less than that when I get it working, that will be a plus.  rpcminer-cuda uses practically no cpu in Windows, but these cards don't get along with it (computer actually performs better with cgminer using more than 100% of one core [I've seen it up to 67% of two cores] than rpcminer-cuda with aggression set to 3.  I may try out the intensity level just to see, though.