Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 712. (Read 5805728 times)

newbie
Activity: 28
Merit: 0
Hi!

I'm just trying to build this on OsX 10.7.2 but get stuck in an error at
./configure if i'm using CFLAGS="-O2 -Wall -march=native" ./configure like in the Readme file.

Code:
noname:cgminer Matthias$ ./autogen.sh
configure.ac:52: installing `./compile'
configure.ac:17: installing `./config.guess'
configure.ac:17: installing `./config.sub'
configure.ac:22: installing `./install-sh'
configure.ac:22: installing `./missing'
ccan/Makefile.am: installing `./depcomp'
noname:cgminer Matthias$ CFLAGS="-O2 -Wall -march=native" ./configure
checking build system type... x86_64-apple-darwin11.2.0
checking host system type... x86_64-apple-darwin11.2.0
checking target system type... x86_64-apple-darwin11.2.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/Matthias/Desktop/Coins/btc/cgminer':
configure: error: C compiler cannot create executables
See `config.log' for more details

If I use ./configure without CFLAGS i get an error at make:
./configure :
Code:
noname:cgminer Matthias$ ./configure
checking build system type... x86_64-apple-darwin11.2.0
checking host system type... x86_64-apple-darwin11.2.0
checking target system type... x86_64-apple-darwin11.2.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking whether gcc needs -traditional... no
checking whether gcc and cc understand -c and -o together... yes
checking for ranlib... (cached) ranlib
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for stdint.h... (cached) yes
checking for mprotect... yes
checking for sigaction... yes
checking for sigaltstack... yes
checking for siginterrupt... yes
checking for mmap... yes
checking for MAP_ANONYMOUS... yes
checking whether memchr works... yes
checking whether memmem is declared... yes
checking for memmem... yes
checking whether memmem works... no
checking for C/C++ restrict keyword... __restrict
checking for uid_t in sys/types.h... yes
checking for inline... inline
checking whether the preprocessor supports include_next... yes
checking whether system header files limit the line length... no
checking for wchar_t... yes
checking for unsigned long long int... yes
checking for long long int... yes
checking whether stdint.h conforms to C99... no
checking sys/inttypes.h usability... no
checking sys/inttypes.h presence... no
checking for sys/inttypes.h... no
checking sys/bitypes.h usability... no
checking sys/bitypes.h presence... no
checking for sys/bitypes.h... no
checking for bit size of ptrdiff_t... 64
checking for bit size of size_t... 64
checking for bit size of sig_atomic_t... 32
checking for bit size of wchar_t... 32
checking for bit size of wint_t... 32
checking whether sig_atomic_t is signed... yes
checking whether wchar_t is signed... yes
checking whether wint_t is signed... yes
checking for ptrdiff_t integer literal suffix... l
checking for size_t integer literal suffix... ul
checking for sig_atomic_t integer literal suffix...
checking for wchar_t integer literal suffix...
checking for wint_t integer literal suffix...
checking whether memmem is declared without a macro... yes
checking whether mempcpy is declared without a macro... no
checking whether memrchr is declared without a macro... no
checking whether rawmemchr is declared without a macro... no
checking whether stpcpy is declared without a macro... yes
checking whether stpncpy is declared without a macro... yes
checking whether strchrnul is declared without a macro... no
checking whether strdup is declared without a macro... yes
checking whether strncat is declared without a macro... yes
checking whether strndup is declared without a macro... yes
checking whether strnlen is declared without a macro... yes
checking whether strpbrk is declared without a macro... yes
checking whether strsep is declared without a macro... yes
checking whether strcasestr is declared without a macro... yes
checking whether strtok_r is declared without a macro... yes
checking whether strerror_r is declared without a macro... yes
checking whether strsignal is declared without a macro... yes
checking whether strverscmp is declared without a macro... no
checking for memmem... (cached) yes
checking whether memmem works... (cached) no
checking for struct sigaction.sa_sigaction... yes
checking for volatile sig_atomic_t... yes
checking for sighandler_t... no
checking whether sigaction is declared without a macro... yes
checking whether sigaddset is declared without a macro... yes
checking whether sigdelset is declared without a macro... yes
checking whether sigemptyset is declared without a macro... yes
checking whether sigfillset is declared without a macro... yes
checking whether sigismember is declared without a macro... yes
checking whether sigpending is declared without a macro... yes
checking whether sigprocmask is declared without a macro... yes
checking for sigprocmask... yes
checking whether NULL can be used in arbitrary expressions... yes
checking for ANSI C header files... (cached) yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for OpenCL... yes
checking for pthread_create in -lpthread... yes
checking for json_loads in -ljansson... no
checking for ADL_SDK/adl_sdk.h... no
checking for library containing addstr... -lncurses
checking for addstr in -lncurses... yes
checking for addstr in -lpdcurses... no
checking for yasm... /opt/local/bin/yasm
checking if yasm version is greater than 1.0.1... yes
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBCURL... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating compat/Makefile
config.status: creating compat/jansson/Makefile
config.status: creating x86_64/Makefile
config.status: creating x86_32/Makefile
config.status: creating ccan/Makefile
config.status: creating lib/Makefile
config.status: creating config.h
config.status: executing depfiles commands



------------------------------------------------------------------------
cgminer 2.1.1
------------------------------------------------------------------------


Configuration Options Summary:

  OpenCL...............: FOUND. GPU mining support enabled
  ADL..................: SDK NOT found, GPU monitoring support DISABLED
  ASM.(for CPU mining).: true

Compilation............: make (or gmake)
  CPPFLAGS.............:
  CFLAGS...............: -g -O2
  LDFLAGS..............: 
  LDADD................:  -L/opt/local/lib -lcurl   compat/jansson/libjansson.a -lpthread -framework OpenCL -lncurses   -lm

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local


make :
Code:
noname:cgminer Matthias$ make
make  all-recursive
Making all in lib
  GEN    arg-nonnull.h
  GEN    c++defs.h
  GEN    warn-on-use.h
  GEN    signal.h
  GEN    stdint.h
  GEN    string.h
make  all-recursive
  CC     dummy.o
  CC     memmem.o
  AR     libgnu.a
/usr/bin/ranlib: file: libgnu.a(dummy.o) has no symbols
ranlib: file: libgnu.a(dummy.o) has no symbols
Making all in compat
Making all in jansson
  CC     dump.o
  CC     hashtable.o
  CC     load.o
  CC     strbuffer.o
  CC     utf.o
  CC     value.o
  CC     memory.o
  CC     error.o
  AR     libjansson.a
make[3]: Nothing to be done for `all-am'.
Making all in ccan
  CC     helpers.o
  CC     opt.o
  CC     parse.o
  CC     usage.o
  AR     libccan.a
Making all in x86_64
/opt/local/bin/yasm -f elf64 sha256_xmm_amd64.asm
/opt/local/bin/yasm -f elf64 sha256_sse4_amd64.asm
  AR     libx8664.a
ranlib: warning for library: libx8664.a the table of contents is empty (no object file members in the library define global symbols)
  CC     cgminer-main.o
  CC     cgminer-util.o
  CC     cgminer-ocl.o
  CC     cgminer-findnonce.o
  CC     cgminer-sha256_generic.o
  CC     cgminer-sha256_4way.o
  CC     cgminer-sha256_via.o
  CC     cgminer-sha256_cryptopp.o
  CC     cgminer-sha256_sse2_amd64.o
  CC     cgminer-sha256_sse4_amd64.o
  CC     cgminer-sha256_sse2_i386.o
  CC     cgminer-sha256_altivec_4way.o
  CC     cgminer-adl.o
  CC     cgminer-sha2.o
  CC     cgminer-api.o
api.c:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘sock’
api.c:359: error: expected ‘)’ before ‘c’
api.c:452: error: expected ‘)’ before ‘c’
api.c:487: error: expected ‘)’ before ‘c’
api.c:520: error: expected ‘)’ before ‘c’
api.c:553: error: expected ‘)’ before ‘c’
api.c:615: error: expected ‘)’ before ‘c’
api.c:642: error: expected ‘)’ before ‘c’
api.c:688: error: expected ‘)’ before ‘c’
api.c:718: error: expected ‘)’ before ‘c’
api.c:743: error: expected ‘)’ before ‘c’
api.c:757: error: expected ‘)’ before ‘c’
api.c:771: error: expected ‘)’ before ‘c’
api.c:773: error: expected ‘)’ before ‘c’
api.c:788: error: expected ‘)’ before ‘char’
api.c:789: warning: no semicolon at end of struct or union
api.c:790: error: ‘apiversion’ undeclared here (not in a function)
api.c:790: warning: excess elements in struct initializer
api.c:790: warning: (near initialization for ‘cmds[0]’)
api.c:791: error: ‘devstatus’ undeclared here (not in a function)
api.c:791: warning: excess elements in struct initializer
api.c:791: warning: (near initialization for ‘cmds[1]’)
api.c:792: error: ‘poolstatus’ undeclared here (not in a function)
api.c:792: warning: excess elements in struct initializer
api.c:792: warning: (near initialization for ‘cmds[2]’)
api.c:793: error: ‘summary’ undeclared here (not in a function)
api.c:793: warning: excess elements in struct initializer
api.c:793: warning: (near initialization for ‘cmds[3]’)
api.c:794: error: ‘gpuenable’ undeclared here (not in a function)
api.c:794: warning: excess elements in struct initializer
api.c:794: warning: (near initialization for ‘cmds[4]’)
api.c:795: error: ‘gpudisable’ undeclared here (not in a function)
api.c:795: warning: excess elements in struct initializer
api.c:795: warning: (near initialization for ‘cmds[5]’)
api.c:796: error: ‘gpurestart’ undeclared here (not in a function)
api.c:796: warning: excess elements in struct initializer
api.c:796: warning: (near initialization for ‘cmds[6]’)
api.c:797: error: ‘gpudev’ undeclared here (not in a function)
api.c:797: warning: excess elements in struct initializer
api.c:797: warning: (near initialization for ‘cmds[7]’)
api.c:798: error: ‘cpudev’ undeclared here (not in a function)
api.c:798: warning: excess elements in struct initializer
api.c:798: warning: (near initialization for ‘cmds[8]’)
api.c:799: error: ‘gpucount’ undeclared here (not in a function)
api.c:799: warning: excess elements in struct initializer
api.c:799: warning: (near initialization for ‘cmds[9]’)
api.c:800: error: ‘cpucount’ undeclared here (not in a function)
api.c:800: warning: excess elements in struct initializer
api.c:800: warning: (near initialization for ‘cmds[10]’)
api.c:801: error: ‘doquit’ undeclared here (not in a function)
api.c:801: warning: excess elements in struct initializer
api.c:801: warning: (near initialization for ‘cmds[11]’)
api.c:805: error: expected ‘)’ before ‘c’
api.c: In function ‘tidyup’:
api.c:834: error: ‘sock’ undeclared (first use in this function)
api.c:834: error: (Each undeclared identifier is reported only once
api.c:834: error: for each function it appears in.)
api.c:834: error: ‘INVSOCK’ undeclared (first use in this function)
api.c: In function ‘api’:
api.c:856: error: ‘SOCKETTYPE’ undeclared (first use in this function)
api.c:856: error: expected ‘;’ before ‘c’
api.c:862: error: storage size of ‘serv’ isn’t known
api.c:863: error: storage size of ‘cli’ isn’t known
api.c:883: error: ‘sock’ undeclared (first use in this function)
api.c:884: error: ‘INVSOCK’ undeclared (first use in this function)
api.c:885: error: ‘SOCKERRMSG’ undeclared (first use in this function)
api.c:895: error: ‘INVINETADDR’ undeclared (first use in this function)
api.c:941: error: ‘c’ undeclared (first use in this function)
api.c:949: warning: assignment makes pointer from integer without a cast
api.c:954: warning: assignment makes pointer from integer without a cast
api.c:1029: error: ‘struct CMDS’ has no member named ‘func’
make[2]: *** [cgminer-api.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Here are the dependencies i installed previously (I hope there is nothing missing):
Code:
noname:cgminer Matthias$ port installed
The following ports are currently installed:
  autoconf @2.68_2 (active)
  automake @1.11.2_0 (active)
  curl @7.23.1_0+ssl (active)
  curl-ca-bundle @7.23.1_0 (active)
  expat @2.0.1_1 (active)
  gdbm @1.10_1 (active)
  gettext @0.18.1.1_2 (active)
  glib2 @2.30.2_2 (active)
  gperf @3.0.4_2 (active)
  help2man @1.40.4_1 (active)
  jansson @2.1_0 (active)
  libffi @3.0.10_2 (active)
  libiconv @1.14_0 (active)
  libidn @1.22_0 (active)
  m4 @1.4.16_0 (active)
  ncurses @5.9_1 (active)
  ncursesw @5.8_0 (active)
  openssl @1.0.0e_1 (active)
  p5.12-locale-gettext @1.50.0_6 (active)
  perl5 @5.12.3_1+perl5_12 (active)
  perl5.12 @5.12.3_3 (active)
  pkgconfig @0.26_1 (active)
  xz @5.0.3_0 (active)
  yasm @1.1.0_0 (active)
  zlib @1.2.5_0 (active)

Can anyone help me please? I'd really like to get this running.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Done, updated git tree so the primary pool is not considered lagging if the donation pool falls over.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Yes when the donation pool is down it leaks the failed work requests to other pools so that's the intended behaviour. Perhaps I should make it specifically use whatever is considered the current pool instead.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Just reporting, after upgrading to 2.1.0 my reject rate has been lower over the last 3 hours average. Now between 0.7% and 1.2% instead of 3%-7%. Much better. Thanks!
Thanks for the feedback. This reject problem was a difficult bug to track and only affected people with multiple pools set up (which most of us do).
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
Just reporting, after upgrading to 2.1.0 my reject rate has been lower over the last 3 hours average. Now between 0.7% and 1.2% instead of 3%-7%. Much better. Thanks!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Donation site is completely down for the moment so if it works through this then all is well. I consider this bugfix big enough to warrant a new version entirely.
member
Activity: 266
Merit: 36
The donor pool had two short outages today so you would have noticed a difference with the new code by now.

"Today"?  I've been running the new code since Jan 4. 23:17 GMT without problems.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
The donor pool had two short outages today so you would have noticed a difference with the new code by now.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
The git tree should now have a fix for this issue in it.

Got it running now on the machine I compile on and re-enabled donations on it, will let you know if I see any problems.
Thanks a lot. This all assumes the donor pool actually has trouble, so I've put it back to the one that has been unstable lately just now (which means you'd have to restart the miner, sorry). Funny how for a change I'm wishing for pool instability (shh! no one tell the admin  Wink)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
The git tree should now have a fix for this issue in it.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
Would a 64-bit cgminer benefit in any way? I thought if I had some free time, I could try to compile in MinGW-W64
None whatsoever unless you're CPU mining, and even then you'd need to port the assembly code to make it work properly. Also mingw 64 is still much buggier than 32 bit and people have lots of problems with it.
Never had any problems with it. I compiled SDL(Simple DirectMedia Layer) under it. As well as the current litecoin miners(the improved ones).
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Would a 64-bit cgminer benefit in any way? I thought if I had some free time, I could try to compile in MinGW-W64
None whatsoever unless you're CPU mining, and even then you'd need to port the assembly code to make it work properly. Also mingw 64 is still much buggier than 32 bit and people have lots of problems with it.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
Would a 64-bit cgminer benefit in any way? I thought if I had some free time, I could try to compile in MinGW-W64
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Thanks guys, I now have a postulated mechanism for failure with donations on which is why I came up with the idea. I've since moved again to a different pool for donations but I realise it also provides a bug mechanism (though harder to hit) without donations, so I'll work on a fix. Nothing like discovering a hard to find bug  Grin
legendary
Activity: 2688
Merit: 1240
From my experience it really depends on the PSU you use how far you can push a card and it stays there stable.

I had some rigs with el-cheapo-800w PSU where I could barely overlock a 5870 to 900 MHz and it would get SICK or DEAD every 2nd day, after one of the PSU died i replaced it by a Corsair TX850 and since then I could overclock the cards even to 950 MHz without any problems, they are running for months stable now.

I swapped the second PSU also and hat the same effect..

Dont save at the wrong end Smiley
sr. member
Activity: 252
Merit: 250
Which doesn't change the fact that hardware errors are quite rare.  On 16 GPU I have never had a single HW error logged in over time 9 months. 
Your high overclock likely has something to do with it.

Absolutely, I was just replying to ckolivas's assumption that hardware errors will lock the card or make it 'dead'. It's possible to overclock "just right" so the gain in mhashes is worth the few hardware errors, while keeping the uptime at 100%.
sr. member
Activity: 349
Merit: 250
BTCPak.com - Exchange your Bitcoins for MP!
It appears that you can easily change the donation pool (it is pulling the information from a website).  Before we all jump on the turning off donation bandwagon, maybe it would be easier to change the donation pool to something more stable for the time being. 

I bet donations have a tendency to stay off. 
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
When I switched to cgminer a couple months back I noticed that I always had a much higher reject rate. I get typically 3-7% rejects regardless of pool, Ars, Eligius, BTCGuild and others. Not sure what causes this and haven't tried to debug yet. I just let it be because I like the interface and monitoring in cgminer but it would be nice to track this down and see why the rejects are high. Before, same HW/OS setup, I used to get more like 0.7%.

Should I turn LP off? I thought that was to help reduce rejects.
There was a bug that would cause higher rejects with multipool setups that was fixed in 2.1.0. We're only turning LP off at the moment to debug a network connectivity issue.
Could it be related to high latency? I have about a 350mS round-trip to me here in Thailand. But that was the same on the previous miner (phoenix 1.6.2). I basically just stopped phoenix and ran cgminer instead with a bit of fiddling with the config.

Edit: Trying 2.1.0 now. Will see how it goes.
hero member
Activity: 518
Merit: 500
I'm thinking this may all be related to my donation pool being flaky lately with the move and nothing to do with the new version.

In support of that theory: I only had one instance of the connection bug so far, and that was when I turned on donations and happened more or less simultaneously for two instances of cgminer. I turned donations off again and have been sailing smoothly since New Year's Eve (which is when the bug occurred for me).
Anyway, I'm back to donating manually.

On hindsight I think the problems began when I enabled donations as well. How ironic, donators being 'punished'. Ill turn it off as well and see what happens.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Hardware Errors=0 even though one card is "DEAD" ?
Hardware errors are very different to a card becoming unresponsive under load. Usually hardware errors occur if someone has unlocked the shaders in a card that has faulty shaders, or they are overclocking beyond reliable levels but below crash levels. Hitting hardware errors without a hardware hang/dead card is actually quite rare.

Mmmm... no, not really:

RAM: 325
CPU: 1040
Mhash/s: 337,2
Accepted: 289690
Accept/min: 4,51
Hardware: 523
Hardware %: 0,18

As you can see, a uptime of 1,5 months (since I restarted cgminer). The card never haged or went dead.


Which doesn't change the fact that hardware errors are quite rare.  On 16 GPU I have never had a single HW error logged in over time 9 months. 

Your high overclock likely has something to do with it.
Jump to: