OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[The00Dustin]

You must specify your install directory with --prefix= and compile it yourself if you want to install it somewhere specific.

In case you were responding to me, I wasn't clear.  I am fine with the default install path.  However, historically the default install path has been /usr/local/bin and for some reason, the default install path is /usr/bin on 1.6.1, but I get the error about cgminer not being in /usr/local/bin.  This is after I install (and before, obviously), and I did manually compile from source (hence the comment about configure not checking the JSON version and dealing with it appropriately [using the included source if the installed source is too old]).  I will try with --prefix, and I imagine that will solve the problem, but I didn't do anything different for 1.6.1 than I did for 1.5.8.  1.5.8 installed in /usr/local/bin again after I uninstalled 1.6.1 and re-installed 1.5.8, so something it seems like is different about this version that causes that error if --prefix isn't provided in Fedora 15.

[1713980846]

1713980846

[1713980846]

1713980846

[-ck]

You must specify your install directory with --prefix= and compile it yourself if you want to install it somewhere specific.

In case you were responding to me, I wasn't clear.  I am fine with the default install path.  However, historically the default install path has been /usr/local/bin and for some reason, the default install path is /usr/bin on 1.6.1, but I get the error about cgminer not being in /usr/local/bin.  This is after I install (and before, obviously), and I did manually compile from source (hence the comment about configure not checking the JSON version and dealing with it appropriately [using the included source if the installed source is too old]).  I will try with --prefix, and I imagine that will solve the problem, but I didn't do anything different for 1.6.1 than I did for 1.5.8.  1.5.8 installed in /usr/local/bin again after I uninstalled 1.6.1 and re-installed 1.5.8, so something it seems like is different about this version that causes that error if --prefix isn't provided in Fedora 15.

That's because it has to have some default prefix if none is specified, and (perhaps foolishly) I chose /usr since most distros install everything there (even though most configure scripts default to /usr/local, I know). Ideally it should have a custom location for kernels, in something like $prefix/lib/cgminer or share/cgminer or some other crap, but I couldn't decide where would work cross platform and my care factor dropped to negative levels once I got it working at all.

[The00Dustin]

That's because it has to have some default prefix if none is specified, and (perhaps foolishly) I chose /usr since most distros install everything there (even though most configure scripts default to /usr/local, I know). Ideally it should have a custom location for kernels, in something like $prefix/lib/cgminer or share/cgminer or some other crap, but I couldn't decide where would work cross platform and my care factor dropped to negative levels once I got it working at all.

Fair enough, and I know very little about coding, but if you chose that default and I didn't override it, shouldn't the software be looking there instead of failing by looking at the distro's default?  Or alternatively, if it knows the distro's default after compile, why couldn't that be imported during configure?  Additionally, couldn't it check the CWD before checking/looking up the default directory?  You don't have to explain/answer any of that, I just figured I'd put it all out there in case it made you think of a way to deal with that.  In the meantime (or indefinitely), I have no problem using --prefix.

[-ck]

Because the least work and most portable was to add the --prefix value to the directories cgminer checks. If you grab the precompiled binary it will be set to /usr, if you don't set --prefix it will be set to /usr, if you set --prefix it will be wherever you choose and it ends up when you do 'make install'. The last part was the most important.

[ancow]

When I make cgminer 1.6.1 and try to run it from the source directory (and after running make install), it returns this error:

Code:

-bash: /usr/local/bin/cgminer: No such file or directory

I'd like to point out that this is bash not finding cgminer where it expects it to. This has nothing to do with cgminer.
I'm not sure why bash would keep looking in the old location - perhaps it's somehow caching where it found it previously? Anyway, you should probably ask in some Fedora/bash forum.
You might try opening another instance of bash/whichever terminal you're using and see whether it finds cgminer in its current location then.

[-ck]

Indeed as ancow said, I completely ignored that fact. bash DOES cache the location and if you remove it after you've already used it, it will stupidly continue to try and use that one.

[The00Dustin]

Indeed as ancow said, I completely ignored that fact. bash DOES cache the location and if you remove it after you've already used it, it will stupidly continue to try and use that one.

Nice...  I'll try some stuff tomorrow and report back.

[sharky112065]

Anyone been able to get a log file on Windows 7?

I put "2>log.txt" at the end of my launch string/cmd line and all I get is  a zero sized log.txt file. The file has nothing in it even after exit.

[RvdE]

Hi ckolivas,

I can confirm the high number of rejects (100% on my boxes) with CPU mining has been fixed. The only algo that wouldn't generate rejects for me was the sse2_64. So great work.

Compiling 1.6.1 is a different story though. I notice the configure script checks for curl_easy_init and after that does the pkg-config check for libcurl. Since it doesn't know where to look for curl yet, the former check obviously fails. Also, you use LIBCURL_CPPFLAGS, but on FreeBSD (and possibly other systems), pkg-config only returns LIBCURL_CFLAGS. Since they should be the same, could you change it to make use of CFLAGS instead of CPPFLAGS ?

Thanks in advance.

[nebiki]

the queued items in the bottom part of the logs won't get updated. using the 1.6.1 windows-binary on win7x64

[sharky112065]

Anyone been able to get a log file on Windows 7?

I put "2>log.txt" at the end of my launch string/cmd line and all I get is  a zero sized log.txt file. The file has nothing in it even after exit.

Did you launch from the actual command line or from some
sort of shortcut ? If the latter, you might want to try the former,
i.e. open an actual shell (a command prompt) and type the launch
command in there.

I have tried it both ways.

I did get it to write on one of my miners today when a GPU locked up (It then wrote all info from the time I started up Cgminer to when I closed it). Spoke with ckolivas on IRC and he thinks he knows what it is. Will probably be fixed on a future release.

[-ck]

the queued items in the bottom part of the logs won't get updated. using the 1.6.1 windows-binary on win7x64

Interesting. The queued value is truly the "number of items this specific device queued" and there are other ways the queue is kept full that mean this device may not ever really request work on its own. So, strictly speaking, it's still correct under that description, but I can see why it looks odd.

[The00Dustin]

Indeed as ancow said, I completely ignored that fact. bash DOES cache the location and if you remove it after you've already used it, it will stupidly continue to try and use that one.

Nice...  I'll try some stuff tomorrow and report back.

I tested this morning, and I concur, it has to do with bash caching.  I was able to launch by using an exclusive path (/usr/bin/cgminer and/or ./cgminer), but subsequently still unable to launch without an exclusive path (regardless of CWD).  I started a new session and it launched fine from the new path while the CWD was my home folder.  Given those results, I don't need to, and won't be testing with --prefix (since the problem wasn't with the cgminer source at all to begin with).  Thanks,
Dustin

[jones]

awesome tool. thank you for your contribution!

[-ck]

Just as a quick data point, I am now recommending dedicated mining rigs use -I 9 instead of -I 8. Changes in the last few versions seem to make for a very small rise in throughput on 69xx cards with the higher intensity. As always, test for yourself as your mileage may vary. 

[teflone]

Does not work on Win 7 64 for me..

[iopq]

Does not work on Win 7 64 for me..

what doesn't work? the executable doesn't start? the kernel doesn't compile? you gotta give some more details

[polymorpher]

Today at my computer CGMiner can't connect to any pool other than a local server, but I am having no problem with phoenix so it is not a networking problem. Is there anyone having the same problem?

[polymorpher]

Today at my computer CGMiner can't connect to any pool other than a local server, but I am having no problem with phoenix so it is not a networking problem. Is there anyone having the same problem?

Changing URL (btcguild.com:8332) to a fixed IP in their cluster fixed the problem. It seems they have a cluster now - each time I ping the server btcguild.com it would give a different ip address in network 78.46/16

Perhaps CGMiner stored the IP address resolved at the first place, expecting response from this IP address, but performed a reconnection and got a different IP address before retrieving initial work, therefore get confused? Just my guess.

[kripz]

Why intensity 9 now?

And what does this mean?

Don't leak work to backup pools when primary pool is lagging