I poked around with things for the fun of it and because there are other things I should be doing   It's been a long time.  As best I can tell, this is an issue with config.guess/config.sub and probably not much you could/should reasonable do about it as the maintainer (unless you want to hack the auto-tools distro which is not very maintainable.)

Many of these tools can be run individually, and it seems like this is the crack-up:

  ~/work/bfgminer/bfgminer-2.8.1$ /bin/sh -x ./config.sub armv6l-unknown-linux-eabihf

config.[sub|guess] seem to not be up to date with regards to -eabi and parsing it out, but you've got a pretty recent version in your 2.8.1 distro.

The OP could use a flag to force acceptance of the string (produced by ./config.guess) but it sounds like he's got things going (not sure why given the issue...maybe his distro has an even newer auto-tools..., but oh well.)

I've not used the hardware but it wikipedia says that a number of OS's are ported to it including Arch Linux.


IIRC (and it's been many years since I messed with this stuff) there is a file which is part of one of the auto-tools which tools to perform platform analysis and one which contains data to interpret the output.  I believe that it is possible to recognize particular parts of this output which are of interest to the rest of the configure system rather than to crash when there is a failure to do a complete match.

IIRC, the files which do this analysis are bundled with the distribution being cut so as long as the code maintainer is the one generating the configure system he/she can be up-to-date with his/her autoconfiguration generation tools and the end-user does not have to be.  Of course all bets are off if the end-user is trying to generate the autoconfiguration in his/her environment (when trying to build from HEAD, for instance, or correct an input file deficiency or whatever.)

That's hopeful, and probably useful info to someone trying to build the code.  Do you know what OS's they might have been running?

The guy's initial attempt (with ./configure presumably from the release) crashed in platform recognition.  Ideally the user could trust that message to indicate whether the platform is supported, but it's understandable if/when it cannot be 100% reliable.  Much of the time (imho) when there is a failure here, the maintainer has simply not leveraged the autoconf system to it's potential.

One way or another, at least your code has an autoconfiguration system.  Last time I looked bitcoind did not which was a disappointment to me.

I noticed nothing in a scan of the README (though I was looking for 'arm' and not 'mips' which was a mistake since I've not done this kinds of stuff in a while) and noticed no assembly for anything but x86's.  But it is not unheard of for people to optimize for an architecture with assembly while supporting other architectures with compiled code.  And also common to build a sub-set of functionality on less well supported architectures.  That's why I said 'or at least not fully.'

But, since you are here, is it known that the code should work on his platform, or is he blazing trails in trying to get it going?

It was pretty obvious to me several years ago that Obama was going to win and 'they' would run someone unelectable against him.  It was a disaster when the Dems had house/senate/executive because they had no excuse not to get anything done.  But they made up a bunch anyway ("oh golly...we need 60%...shucks, can't do it") and with the help of the media the peeps bought it lock/stock/barrel.  Obama has been the best friend to the bankers so of course he was going to win.

I'm planning to write-in Elizabeth Warren.  Maybe she'll get the message and run for prez next time around.

Although I am unfamiliar with Arch, it looks to me like you may be missing at least 'libtool', or there is something missing in the environment of the user who is compiling (like the PATH to find libtool.)  If you are using a release (vs. the development head) than it would be unfortunate and unexpected that you would need to execute autoconf, though it is common enough if you are on an unexpected platform where the developers don't normally work (and you know how do manipulate configure.ac files and such which is not always trivial.)

Usually one of the steps in cutting a release for the maintainer to execute aclocal and autoconf themselves which generate a portable configuration system which the end-user uses (e.g., ./configure) and that is why I distinguish between HEAD and a release branch in my comment.

I would suggest you start out by verifying that the libtool package is installed on your system.

First though I would also suggest that you verify that the software you are trying to build has a hope of compiling under ARM else you might end up spending a lot of time on something which will be very difficult to achieve.  It is not at all uncommon for source code to need significant porting to run on different architectures (i.e., ARM vs. x86) and it not to have been done.  A cursory glance at the project indicates to me that it probably does not, or at least not fully.

Sock Puppet of ~tvbcof to use when I cannot control myself and refrain from being an immature prick.