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

[induktor]

The BTC difficulty is increasing because more and more people are buying newer and newer hardware. The network doesn't just increase by 500x in a one year span without people buying the hardware, and mining on them. CGMiner is at the forefront of running those millions of dollars of hashrate, BTW.

And as far as your ASICs are concerned, it's not Con's fault people bought a bunch of BEs or a Jalapeno and realized they're too expensive / hard to maintain to successfully mine any coins from them. Those ASICMiner devices have always been overpriced. ASICMiner and Avalon units consume way too much power. Those BFL Singles are decent devices. Those AntMiners look very promising. KNC or BitFury are amazing devices. I dare you to ask anyone who has any of those and see if they're losing money.

I know how difficult is calculated, I have been on this for almost a year, as I said before, i build several farms (5, one is mine, the other as a consultant/technician for investors) and the only ones making real money are the altcoins, the only way to make real money mining bitcoin is buying the chips and produce the rigs yourself before anyone else, or better.... design the chips yourself and don't sell them, use them.
I will get ROI with my Fury's probably between febrary and march, I already achieved ROI with my Blades, but you know what, I can make ROI in alt-coins in 3 months, sometimes less.
I never talked about loosing money, just not earning enough to make it worth it, period.

[1638993840]

1638993840

[-ck]

ckolivas any plans to do a antminer firmware like you done with avalon and knc miner ?

I echo this, compiling the custom version with Antminer support is very difficult and (in my experience) far from stable. Would love to see the Antminer drivers integrated into the official CGMiner.

I'm waiting to see their code synced up with the current master cgminer before I can do anything with it, but also this happens to be one of the busiest times ever for development (behind the scenes), and I'll be travelling next week, so I can't guarantee timeframes on anything right now.

[kano]

Those ASICMiner devices have always been overpriced. ASICMiner and Avalon units consume way too much power. Those BFL Singles are decent devices. Those AntMiners look very promising. KNC or BitFury are amazing devices. I dare you to ask anyone who has any of those and see if they're losing money.

My V1 Blades have paid for themselves a few time over - they've been totally solid and reliable, and just hash away in the corner with zero intervention.  Same with the Jalapenos. 
...

Only because the price of BTC has risen.

However, you lost BTC. The BTC price paid for said items at the time they were bought is greater than the BTC they have produced.
Thus your profit is less than if you had simply bought BTC instead.
(also you need to subtract the running cost and time mining that would not have been necessary if you only bought BTC)

[cs2000]

ckolivas any plans to do a antminer firmware like you done with avalon and knc miner ?

I echo this, compiling the custom version with Antminer support is very difficult and (in my experience) far from stable. Would love to see the Antminer drivers integrated into the official CGMiner.

I'm waiting to see their code synced up with the current master cgminer before I can do anything with it, but also this happens to be one of the busiest times ever for development (behind the scenes), and I'll be travelling next week, so I can't guarantee timeframes on anything right now.

Thanks for confirming that

Hopefully Bitmain will make the required changes so the two can be merged

[HellDiverUK]

However, you lost BTC. The BTC price paid for said items at the time they were bought is greater than the BTC they have produced.

Well, no, that's false, but hey don't let facts get in the way of a good argument.    I've never bought BTC for fiat, every BTC I've mined has been reinvested or cashed out to fiat.

Thus your profit is less than if you had simply bought BTC instead.
(also you need to subtract the running cost and time mining that would not have been necessary if you only bought BTC)

Agreed on the first point.  

However, my running costs are essentially zero when averaged out across a year, and over the year I've been mining I've spent essentially nothing in fiat to keep my BTC production around 1BTC every 6 weeks.  1BTC every 6 weeks means I can keep up with increase in difficulty by buying new hardware, and sometimes my older hardware is sold to top up that BTC fund - I sold my 10 Block Erupters and bought two BlueFurys.  Selling the Blues paid for the 10 Antminer U1s.  Without spending a fiat penny I've gone from 3.3GH to 5GH to around 20GH.

You also have to consider that I'm not really in this for profit.  I have a good job that pays me enough that I live comfortably and have enough left over at the end of the month to not only save, but spend on my hobby of building PCs and buying little things to tinker with.  Mining is a hobby.  Some people play games on XBox.  Some people go and piss £100 up the wall on a Friday night.  I mess about with my miners.

[HellDiverUK]

ckolivas any plans to do a antminer firmware like you done with avalon and knc miner ?

I echo this, compiling the custom version with Antminer support is very difficult and (in my experience) far from stable. Would love to see the Antminer drivers integrated into the official CGMiner.

I'm waiting to see their code synced up with the current master cgminer before I can do anything with it, but also this happens to be one of the busiest times ever for development (behind the scenes), and I'll be travelling next week, so I can't guarantee timeframes on anything right now.

Thanks for confirming that

Hopefully Bitmain will make the required changes so the two can be merged

nwoolls has drivers working for "The other miner that can't be mentioned", and will be merging them to it's git soon.  Perhaps ck and kano can do something with his code?

[kano]

However, you lost BTC. The BTC price paid for said items at the time they were bought is greater than the BTC they have produced.

Well, no, that's false, but hey don't let facts get in the way of a good argument.    I've never bought BTC for fiat, every BTC I've mined has been reinvested or cashed out to fiat.

Well yes. "BTC price paid" is whatever you paid converted to BTC, be it prayers to Luke, or Indian Rubles. So again, yes.

In fact the early Block Erupter boards and AMUs were so over priced that even I (who got an AMU from FriedCat - probably one of the first of anyone not inside Asicminer) have still not made 2 BTC on it - that was the price they were then, though I didn't pay any BTC/Fiat for it, and I expect to never make 2 BTC on it.

Go check again.

[kano]

Meanwhile, on an on topic note, anyone who has BitFury boards, with a V1 or V2 controller, I've updated the driver in my git and it should work with either now.
https://github.com/kanoi/cgminer

I've tested it on BlackArrow hardware.
One V2 controller with 1 board, the other V2 controller with 6 boards: 3onSPI1, 2onSPI2, 1onSPI3.

Both work fine.

I, however, use Arch coz I find it more reliable on the RPi.
http://www.kano-kun.net/?p=87

[HellDiverUK]

However, you lost BTC. The BTC price paid for said items at the time they were bought is greater than the BTC they have produced.

Well, no, that's false, but hey don't let facts get in the way of a good argument.    I've never bought BTC for fiat, every BTC I've mined has been reinvested or cashed out to fiat.

Well yes. "BTC price paid" is whatever you paid converted to BTC, be it prayers to Luke, or Indian Rubles. So again, yes.

In fact the early Block Erupter boards and AMUs were so over priced that even I (who got an AMU from FriedCat - probably one of the first of anyone not inside Asicminer) have still not made 2 BTC on it - that was the price they were then, though I didn't pay any BTC/Fiat for it, and I expect to never make 2 BTC on it.

Go check again.

I paid for the ASICMiners using BTC I mined using GPUs.  GPUs that were sold for more than I bought them for (bought cheap off eBay and sold for more than I bought them 6 months later when more folks wanted those GPUs for mining).  So, only fiat spent was the GPUs, which I got back.  Power was paid for by fait received after selling BTC.

I have never spent fiat on mining hardware.  It's always been BTC produced mining. 


So, yeah, just because you suck at mining doesn't mean everyone does. 

[-ck]

There was a minor packaging error in the 3.9.0 source tarball which would make bitfury code not fully compile support for bi*fury devices unless drillbit was enabled as well, so I've uploaded updated tarballs with only that one change, they will be tagged 3.9.0-1. There is no other change in this code so you do not need to update if everything's working for you.

I have been working on writing a nanofury driver (using direct USB communications as per our USB device driver model) but it is proving rather challenging so it appears that it will be some time before nanofury support is in mainline cgminer at this stage.

[kano]

...
So, yeah, just because you suck at mining doesn't mean everyone does. 

No, I just don't rip people off selling ASICs I bought.
You may not care about ripping people off - meanwhile I can do well without ripping anyone off.

My $ input to Bitcoin was 2.5 years ago when I bought a rig that paid itself off that year.
Everything else has been minor things.
Oddly enough I've made quite a bit more than that now.

Though, my >700GH/s at the moment (and increasing regularly) says I don't suck at mining.

[rgr_rgr]

I have been working on writing a nanofury driver (using direct USB communications as per our USB device driver model) but it is proving rather challenging so it appears that it will be some time before nanofury support is in mainline cgminer at this stage.

Did you notice https://bitcointalk.org/index.php?topic=321287.msg4086475#msg4086475 ? It works quite well for me. Do you do a rewrite or do you just try to integrate into mainline?

[ok123]

There was a minor packaging error in the 3.9.0 source tarball which would make bitfury code not fully compile support for bi*fury devices unless drillbit was enabled as well, so I've uploaded updated tarballs with only that one change, they will be tagged 3.9.0-1. There is no other change in this code so you do not need to update if everything's working for you.

I have been working on writing a nanofury driver (using direct USB communications as per our USB device driver model) but it is proving rather challenging so it appears that it will be some time before nanofury support is in mainline cgminer at this stage.

                           

I meet a very troublesome problem,and I ask for your help.

My host OS: Win7 ultimate sp1(x64)
Graphics card： ATI Radeon HD 6850

When I mine many coins based on scrypt,cgminer can run smoothly in my host OS.But I want to place cgminer and all coin's wallets into a virtual machine now,because my antivirus software always prompts that there are many viruses in cgminer and some coin's wallets. So I installed VMware workstation(10.0.1 build-1379776) today,and converted my physical computer into a virtual machine by using "Virtualize a Physical Machine".
But cgminer can't run in the virtual machine,and it prompts "No devices found". So I am ready to install the graphics driver,but I find that the graphics driver can't be installed successfully at all in the virtual machine.

So,I want to know:
1: Can cgminer run smoothly in a virtual machine?
2: If it can,how should I set the virtual machine？

My cgminer is downloaded from the link:
http://ck.kolivas.org/apps/cgminer

[EskimoBob]

can cgminer be used for mining twister blocks?

[HellDiverUK]

I meet a very troublesome problem,and I ask for your help.

cgminer doesn't support GPU mining any more. 

You can't mine via using a GPU in a VM anyway, so you're barking up the wrong tree.

[Luke-Jr]

You can't mine via using a GPU in a VM anyway, so you're barking up the wrong tree.

You can if you run an AMD CPU or an Intel CPU with VT-d support (note: not VT-x).

[-ck]

New version: 3.10.0, 9th January 2014

Mainly new drivers.

Human readable changelog:

- Minion driver courtesy of Kano. (More info about this from him hopefully).
- Nanofury driver. These are set up the same as every other USB device is on cgminer. Tested on both windows and linux (sorry no osx to test). Note the hashrate is once again based on only valid shares so may appear lower than other software using this device. No HW errors are currently counted (though they're most definitely there in abundance due to bitfury design). This is a driver based on all the other ones out there with a completely rewritten model to suit how cgminer drivers work.
- Hashfast driver fixes (no I still don't have one).
- Fixed BXF devices slowing down over time.


Full changelog:

- Set the mcp2210 transfer setting only when it changes.
- Buffer sizes in nanofury device data are unnecessarily large.
- Only perform spi reset on init, not with each transaction.
- Remove spi_detect_bitfury at nanofury startup and fix incorrect refresh time.
- Use a simple serialised work model for nanofury
- Use bitfury_checkresults to avoid hashing results twice in nanofury.
- Export bitfury_checkresults in libbitfury
- Pass extra parameters for later use in libbitfury_sendHashData
- Avoid double handling bswap of the nonce value in nanofury
- Avoid unnecessary rehashing in nanofury nonce checking.
- Remove the unused portions of atrvec in the nanofury driver
- Age work in nf1_scan to avoid risk of losing a work item and leaking memory.
- bitfury_work_to_payload is double handling the data unnecessarily
- Default bitrate on nanofury should be 200kHz
- localvec should be only 80 bytes not 80 words
- Wrong init value for nanofury
- Remove unused rehash values from nanofury driver.
- Only update info work in nanofury driver when it's empty.
- Fill the appropriate type of usb transfer when we know if it's an interrupt
transfer instead of a bulk one.
- Use the internal knowledge of the usb epinfo to determine whether we should be
doing an interrupt instead of a bulk transfer, and do not send a ZLP if so, and
limit read transfer to expected size automatically.
- Avoid bin2hex memleak when we start getting nanofury nonces
- Set atrvec only once and use a local array for each device's work.
- Cancel any spi transfers on nf1 close
- Add bitfury detection loop to nanofury startup
- Move spi init code to libbitfury
- Remove inappropriate extra config reg in nanofury setup.
- Status 0x30 should never happen with spi transfers.
- Fix spi transfer data size transmission mistakes.
- Minor correctness change in spi_add_data
- spi_txrx should always send and receive the same size message
- Random libbitfury changes.
- Set value of gpio pins to low on closing nanofury.
- Fix more init sequence for nanofury.
- Add basic initialisation for nf1 devices
- Add basic nf1_scan function.
- Basic import of libbitfury functions from nanofury branch
- Import functions from nanofury fork for libbitfury
- Meter out spi sends to only 2 bytes at a time, offsetting according to how
much data returns.
- Use the usb read limit function for mcp2210 reads.
- Provide a way for usb reads to just read the size asked for with a limit bool.
- Get pin value after an nf1 spi reset.
- Make sure what we send in the buffer doesn't change during spi reset for
nanofury
- Remove all standalone gpio setting change functions in mcp2210 and just use
the one global setting function.
- Set gpio values in the one function with all values for nanofury.
- Provide a helper function for setting all mcp2210 gpio settings.
- Add a helper function for getting all mcp2210 gpio settings.
- Set all pin designations and directions in one call for nanofury and don't
bother storing their values in the info struct.
- Provide helper functions for setting all pins and dirs on mcp2210
- Set all nanofury pin designations in one call
- Provide a helper function for setting all pin designations on mcp2210
- Store the spi settings in a struct for nanofury devices.
- Check the received status in mcp2210 spi transfers and repeat a zero byte send
if it's in progress.
- Set the bytes per spi transfer prior to each mcp2210 transfer.
- Separate out the send and receive functions for mcp2210 and check response
value in return.
- Check that mcp2210 spi settings have taken and check the value of the pin
during nanofury setup.
- Don't set GPIO pin designations after initial setting in nanofury since the
direction and values will be changed.
- Provide an mcp 2210 set gpio input helper function that sets a pin to gpio and
input.
- Move the set gpio output function to a generic mcp2210 version from nanofury
which also sets the pin to gpio.
- Implement a nanofury txrx with a larger buffer and cycling over data too large
to send.
- Implement magic spi reset sequence for nanofury.
- Add more spi magic to the nanofury init sequence.
- Add lots of magic spi initialisation to nanofury.
- Export reused components of bitfury management into a libbitfury and use for
bab and bitfury drivers.
- More init sequence for nanofury and implement a close function that sets all
pins to input.
- Reword offset header handling in hfa_get_header
- Sanity check in hfa_get_header
- Add more checks in hashfast driver for lost devices.
- Change spimode and send more data in nanofury setup.
- Add basic setup  comms to nanofury.
- Implement an mcp2210 spi transfer function.
- Set the initial spi settings for nanofury driver.
- Provide a helper function for gettings mcp2210 spi settings.
- Implement an mcp2210 set spi transfer settings function.
- Cancel any SPI transfers in progress in nanofury after initial setup.
- Implement an mcp2210 spi cancel function.
- Return only binary values for mcp2210 GPIO values.
- Set GPIO LED and power to high in nanofury driver.
- Implement initial part of nanofury init sequence for GPIO pin settings and add
output debugging of set values.
- Add helper functions for getting and setting mcp2210 gpio pin designations.
- Don't return an error in usb read if we've managed to get the whole read
length we've asked for.
- Use correct endpoint order for nanofury devices and read with a short timeout
on return loop from send_recv.
- Add mcp2210 helper functions for getting and setting one GPIO pin val and
direction.
- Create a generic gpio pin struct and add helpers for mcp get pin val and dirs.
- Check the receive msg of a send/receive cycle on mcp2210 matches the send
message.
- Add a set of usb commands to the usbutils defines for mcp2210 comms, and use
the same command name for send and receive.
- Create a generic mcp2210 send_rcv function.
- Include mcp header for bitfury and fix extra params in macro.
- Add basic SPI comms defines for mcp2210 and build rules for bitfury.
- Minion set some core defaults similar to final requirements
- minion compile warnings
- move driver-minion.c to main directory
- Minion with ioctl() stats, settings to attempt to emulate 21TH/s
- minion driver with results interrupt working
- tested working driver-minion.c without interrupts
- Working driver-minion.c v0.1
- driver-minion.c compilable untested
- minion driver - incomplete
- Add minion driver into cgminer
- Add basic device detection and updated udev rules for nanofury devices.
- Remove GPU from share logging example.
- Don't keep resetting BXF clockspeed to default.
- If no pools are active on startup wait 60s before trying to reconnect since we
likely have the wrong credentials rather than all the pools being out.
- Discard bad crc packets for hashfast driver instead of trying to process them.
- Update documentation for modified avalon options syntax and document relevant
55nm details.
- Modify the auto tuning sequence to work with the 50MHz changes required to
work with 55nm Avalon.
- 55nm avalon requires the delays between writes reinstated for stability.
- Use an equation instead of a lookup table to set the frequency for 55nm avalon
allowing arbitrary values to be used.
- Make the result return rate low detection on avalon less trigger happy.
- Always send the bxf device a clockspeed after parsing the temperature in case
the device has changed the clockspeed itself without notification.
- Fix BXF being inappropriately dependent on drillbit.

[Beastlymac]

Great work thanks Ckolivas.

[netfun2000]

Raspberry PI Make Error:
make  all-recursive
make[1]: Entering directory `/home/minepeon/cgminer'
Making all in lib
make[2]: Entering directory `/home/minepeon/cgminer/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
make[3]: Entering directory `/home/minepeon/cgminer/lib'
make[4]: Entering directory `/home/minepeon/cgminer/lib'
  CC       dummy.o
  AR       libgnu.a
make[4]: Leaving directory `/home/minepeon/cgminer/lib'
make[3]: Leaving directory `/home/minepeon/cgminer/lib'
make[2]: Leaving directory `/home/minepeon/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/minepeon/cgminer/compat'
Making all in jansson-2.5
make[3]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in src
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
  CC       dump.lo
  CC       error.lo
  CC       hashtable.lo
  CC       load.lo
  CC       memory.lo
  CC       pack_unpack.lo
  CC       strbuffer.lo
  CC       strconv.lo
  CC       utf.lo
  CC       value.lo
  CCLD     libjansson.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in libusb-1.0
make[3]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
Making all in libusb
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-descriptor.lo
  CC       libusb_1_0_la-io.lo
  CC       libusb_1_0_la-sync.lo
  CC       os/libusb_1_0_la-linux_usbfs.lo
  CC       os/libusb_1_0_la-linux_udev.lo
  CC       libusb_1_0_la-hotplug.lo
  CC       os/libusb_1_0_la-threads_posix.lo
  CCLD     libusb-1.0.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Entering directory `/home/minepeon/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/minepeon/cgminer/compat'
make[2]: Leaving directory `/home/minepeon/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/minepeon/cgminer/ccan'
  CC       opt/libccan_a-helpers.o
  CC       opt/libccan_a-opt.o
  CC       opt/libccan_a-parse.o
  CC       opt/libccan_a-usage.o
  AR       libccan.a
make[2]: Leaving directory `/home/minepeon/cgminer/ccan'
make[2]: Entering directory `/home/minepeon/cgminer'
  CC       cgminer-cgminer.o
  CC       cgminer-util.o
  CC       cgminer-sha2.o
  CC       cgminer-api.o
  CC       cgminer-logging.o
  CC       cgminer-usbutils.o
  CC       cgminer-libbitfury.o
  CC       cgminer-driver-icarus.o
  CCLD     cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2

[loshia]

Raspberry PI Make Error:
make  all-recursive
make[1]: Entering directory `/home/minepeon/cgminer'
Making all in lib
make[2]: Entering directory `/home/minepeon/cgminer/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
make[3]: Entering directory `/home/minepeon/cgminer/lib'
make[4]: Entering directory `/home/minepeon/cgminer/lib'
  CC       dummy.o
  AR       libgnu.a
make[4]: Leaving directory `/home/minepeon/cgminer/lib'
make[3]: Leaving directory `/home/minepeon/cgminer/lib'
make[2]: Leaving directory `/home/minepeon/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/minepeon/cgminer/compat'
Making all in jansson-2.5
make[3]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in src
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
  CC       dump.lo
  CC       error.lo
  CC       hashtable.lo
  CC       load.lo
  CC       memory.lo
  CC       pack_unpack.lo
  CC       strbuffer.lo
  CC       strconv.lo
  CC       utf.lo
  CC       value.lo
  CCLD     libjansson.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in libusb-1.0
make[3]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
Making all in libusb
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-descriptor.lo
  CC       libusb_1_0_la-io.lo
  CC       libusb_1_0_la-sync.lo
  CC       os/libusb_1_0_la-linux_usbfs.lo
  CC       os/libusb_1_0_la-linux_udev.lo
  CC       libusb_1_0_la-hotplug.lo
  CC       os/libusb_1_0_la-threads_posix.lo
  CCLD     libusb-1.0.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Entering directory `/home/minepeon/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/minepeon/cgminer/compat'
make[2]: Leaving directory `/home/minepeon/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/minepeon/cgminer/ccan'
  CC       opt/libccan_a-helpers.o
  CC       opt/libccan_a-opt.o
  CC       opt/libccan_a-parse.o
  CC       opt/libccan_a-usage.o
  AR       libccan.a
make[2]: Leaving directory `/home/minepeon/cgminer/ccan'
make[2]: Entering directory `/home/minepeon/cgminer'
  CC       cgminer-cgminer.o
  CC       cgminer-util.o
  CC       cgminer-sha2.o
  CC       cgminer-api.o
  CC       cgminer-logging.o
  CC       cgminer-usbutils.o
  CC       cgminer-libbitfury.o
  CC       cgminer-driver-icarus.o
  CCLD     cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2

./autogen.sh?