Compile BFGMiner on Pogoplug (Arch Linux)

[jv13613]

I am attempting to compile BFGMiner on my ARMv6l Pogoplug V3 running Arch Linux. When I download and try to configure the 2.8.1 source I get this error.

Code:

 ./configure
checking build system type... Invalid configuration `armv6l-unknown-linux-eabihf': machine `armv6l-unknown-linux' not recognized
configure: error: /bin/sh ./config.sub armv6l-unknown-linux-eabihf failed

I thought the whole point of compiling was to be able to run the code on almost any machine. Any thought on how I can get this to compile?

[jv13613]

Ok so I am installing bfgminer-git through yaourt now. I am now stuck at this point (see code below). Oh BTW I have been editing the PKGBUILD file to remove the opencl dependency and add the --disable-opencl flag to autogen.sh.

Code:

Running autoreconf -if...
configure.ac:12: installing './ar-lib'
configure.ac:9: installing './install-sh'
configure.ac:9: installing './missing'
Makefile.am:1: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:1:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:1:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
Makefile.am:1:   If 'LT_INIT' is in 'configure.ac', make sure
Makefile.am:1:   its definition is in aclocal's search path.
Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1

Is this something I should should be fixing on my system (such as a system variable?) or in the source code?

[Iman E. Vilsok]

Ok so I am installing bfgminer-git through yaourt now. I am now stuck at this point (see code below). Oh BTW I have been editing the PKGBUILD file to remove the opencl dependency and add the --disable-opencl flag to autogen.sh.

Code:

Running autoreconf -if...
configure.ac:12: installing './ar-lib'
configure.ac:9: installing './install-sh'
configure.ac:9: installing './missing'
Makefile.am:1: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:1:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:1:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
Makefile.am:1:   If 'LT_INIT' is in 'configure.ac', make sure
Makefile.am:1:   its definition is in aclocal's search path.
Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1

Is this something I should should be fixing on my system (such as a system variable?) or in the source code?

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.

[Luke-Jr]

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.

What makes you think that? ARM isn't all that different from x86, and I've put some effort into ensuring it's portable even to big-endian architectures like MIPS.

[Iman E. Vilsok]

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.

What makes you think that? ARM isn't all that different from x86, and I've put some effort into ensuring it's portable even to big-endian architectures like MIPS.

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?

[Luke-Jr]

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.

Assembly is only used (optionally) for CPU mining, though that does support both x86 (SSE) and PowerPC (Altivec). CPU mining is mostly pointless, though, so I wouldn't consider other platforms really "less" supported.

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?

I know a number of users have had success on Raspberry Pi, at least.

[Iman E. Vilsok]

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.

Assembly is only used (optionally) for CPU mining, though that does support both x86 (SSE) and PowerPC (Altivec). CPU mining is mostly pointless, though, so I wouldn't consider other platforms really "less" supported.

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?

I know a number of users have had success on Raspberry Pi, at least.

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.

[Luke-Jr]

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.

Assembly is only used (optionally) for CPU mining, though that does support both x86 (SSE) and PowerPC (Altivec). CPU mining is mostly pointless, though, so I wouldn't consider other platforms really "less" supported.

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?

I know a number of users have had success on Raspberry Pi, at least.

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?

I presume whatever RPi ships with.

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.

Possible... but Google has never heard of armv6l-unknown-linux-eabihf either, so not sure what I can do there.

[Iman E. Vilsok]

...

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?

I presume whatever RPi ships with.

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

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.

Possible... but Google has never heard of armv6l-unknown-linux-eabihf either, so not sure what I can do there.

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.)

[Luke-Jr]

My autotools skills aren't so great, and I'd appreciate any input in how it could be improved.

[jv13613]

Initially I didn't install libtools because I thought I saw its source being downloaded, which it was being built with bfgminer-git. Well I installed libtools and now I get different errors.

http://techblog.sethleedy.name/?p=24276 is a tutorial on compiling cgminer, which BFGMiner forked off from, on the raspberry pi. The os is debian.

UPDATE: I got it working. I installed pkg-config and make, and now it seems to be compiling. Thanks for all the help. I'm glad it was as simple as installing missing dependencies. I'll probably be releasing a tutorial or script once I get everything working.

[Luke-Jr]

http://techblog.sethleedy.name/?p=24276

It's missing libjansson-dev; and -S auto is the default.

[Iman E. Vilsok]

My autotools skills aren't so great, and I'd appreciate any input in how it could be improved.

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.)

[jv13613]

Iman, when I run yaourt i give it an ignore architecture flag. "yaourt -AS packagename" That alone should not solve my first error, but it is probably the fact that it configures everything through autogen.sh and not ./configure.

Make finished compiling but building the package failed because I got a write error. I assume I ran out of space on /tmp (this thing only has 128mb ram), so I moved the compiling temp directory to one on the hard drive. I'm still getting an error though. The executable is under /var/abs/local/yaourtbuild/bfgminer-git/src/bfgminer-build, so I can run it, but I would like to have it packaged.

Code:

make[2]: Leaving directory `/var/abs/local/yaourtbuild/bfgminer-git/src/bfgminer-build'
make[1]: Leaving directory `/var/abs/local/yaourtbuild/bfgminer-git/src/bfgminer-build'
==> Tidying install...
  -> Purging unwanted files...
  -> Compressing man and info pages...
  -> Stripping unneeded symbols from binaries and libraries...
==> Creating package...
  -> Generating .PKGINFO file...
  -> Compressing package...
/usr/bin/makepkg: line 1290: 4821 Killed                  xz -c -z -
bsdtar: Write error
==> ERROR: Failed to create package file.
==> ERROR: Makepkg was unable to build bfgminer-git.

[Luke-Jr]

Iman, when I run yaourt i give it an ignore architecture flag. "yaourt -AS packagename" That alone should not solve my first error, but it is probably the fact that it configures everything through autogen.sh and not ./configure.

Make finished compiling but building the package failed because I got a write error. I assume I ran out of space on /tmp (this thing only has 128mb ram), so I moved the compiling temp directory to one on the hard drive. I'm still getting an error though. The executable is under /var/abs/local/yaourtbuild/bfgminer-git/src/bfgminer-build, so I can run it, but I would like to have it packaged.

Code:

make[2]: Leaving directory `/var/abs/local/yaourtbuild/bfgminer-git/src/bfgminer-build'
make[1]: Leaving directory `/var/abs/local/yaourtbuild/bfgminer-git/src/bfgminer-build'
==> Tidying install...
  -> Purging unwanted files...
  -> Compressing man and info pages...
  -> Stripping unneeded symbols from binaries and libraries...
==> Creating package...
  -> Generating .PKGINFO file...
  -> Compressing package...
/usr/bin/makepkg: line 1290: 4821 Killed                  xz -c -z -
bsdtar: Write error
==> ERROR: Failed to create package file.
==> ERROR: Makepkg was unable to build bfgminer-git.

That sounds like some kind of OOM killed xz. dmesg?

[jv13613]

Correct Luke,

Code:

[313014.130000] Out of memory: kill process 19029 (makepkg) score 891 or a child
[313014.140000] Killed process 19030 (xz)
[324044.570000] xz invoked oom-killer: gfp_mask=0x201da, order=0, oomkilladj=0
[324044.570000] [<c00305e4>] (unwind_backtrace+0x0/0xe0) from [<c007cb38>] (oom_kill_process.isra.8+0xa0/0x200)
[324044.580000] [<c007cb38>] (oom_kill_process.isra.8+0xa0/0x200) from [<c007cf68>] (__out_of_memory+0x118/0x1a8)
[324044.590000] [<c007cf68>] (__out_of_memory+0x118/0x1a8) from [<c007d25c>] (out_of_memory+0x6c/0xdc)
[324044.600000] [<c007d25c>] (out_of_memory+0x6c/0xdc) from [<c007fa64>] (__alloc_pages_nodemask+0x524/0x550)
[324044.610000] [<c007fa64>] (__alloc_pages_nodemask+0x524/0x550) from [<c0081cf4>] (__do_page_cache_readahead+0xf8/0x248)
[324044.620000] [<c0081cf4>] (__do_page_cache_readahead+0xf8/0x248) from [<c00820e0>] (ra_submit+0x28/0x30)
[324044.630000] [<c00820e0>] (ra_submit+0x28/0x30) from [<c007a3f8>] (filemap_fault+0x400/0x434)
[324044.640000] [<c007a3f8>] (filemap_fault+0x400/0x434) from [<c008c88c>] (__do_fault+0x50/0x4d4)
[324044.650000] [<c008c88c>] (__do_fault+0x50/0x4d4) from [<c008f768>] (handle_mm_fault+0x104/0x610)
[324044.660000] [<c008f768>] (handle_mm_fault+0x104/0x610) from [<c0325740>] (do_page_fault+0xe4/0x294)
[324044.670000] [<c0325740>] (do_page_fault+0xe4/0x294) from [<c0323d5c>] (ret_from_exception+0x0/0x10)

I'll try adding a swap file later and see if it works. this will hopefully be my last problem.  

[jv13613]

I got it. I added a swap file and the package was able to be created.

bfgminer-git-20121003-1-arm.pkg.tar.xz can be downloaded at http://www.sendspace.com/file/bdsb74

Thanks to everyone for helping me, especially Luke for developing this great software. 

[Iman E. Vilsok]

Iman, when I run yaourt i give it an ignore architecture flag. "yaourt -AS packagename" That alone should not solve my first error, but it is probably the fact that it configures everything through autogen.sh and not ./configure.
...

I believe that autogen.sh mainly locates and executes the auto-tools to generate a ./configure saving you the trouble.  I'd be surprised if something (e.g., yaourt which I've never used) were not executing it as a phase of the build process.  But it doesn't matter all that much at this point.  Glad to see that you got it going.  Nice work!

[KillaGT]

hey there didn't know if i'm right here.

i got some trouble to run CgMiner on my Pogoplug B04 -> i connect to it via Putty

I installed arch linux like it was discribed here: http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3

I installed the following packages:

pacman -Sy autoconf
pacman -Sy libtool
pacman -Sy ncurses
pacman -Sy yasm
pacman -Sy curl
pacman -Sy curlftpfs
pacman -Sy openssl
pacman -Sy flickcurl
pacman -Sy pkg-config
pacman -Sy git

than downloaded the lates cgminer on the following adress:

git clone git://github.com/ckolivas/cgminer.git cgminer

it donwloads all but no file named "cgminer". i only got cgminer.c which i cannot really handle.

i followed the configuration. first of al i entered:

aclocal


-> nothing happend, it take a while blocking the line and bring me back to the point where i can enter an other command.

i continued with:

./autogen.sh

->now there's some live in the Pogoplug. it lists a lot of things.

I continued with:

./configure --enable-cpumining

-> because i want the Pogo B04 first mine on it's CPu to test this, before i plug in any FPGA's =)

so it takes a while again untill the cofiguration is done....seems alright until yet.

But i don't know what to do now...

I'm new in arch linux and have no idea how to start CgMiner working ....i don't have a File that allows me to start it....i can't find any further explainations on the internet, how to move on =(

here's a litte sample of the "dir"

aclocal.m4                 COPYING            mknsis.sh
adl.c                      depcomp            NEWS
adl_functions.h            diablo121016.cl    ocl.c
adl.h                      diakgcn121016.cl   ocl.h
ADL_SDK                    driver-bitforce.c  phatk121016.cl
api.c                      driver-cpu.c       poclbm121016.cl
API.class                  driver-cpu.h       README
api-example.c              driver-icarus.c    scrypt121016.cl
api-example.php            driver-modminer.c  scrypt.c
API.java                   driver-opencl.c    scrypt.h
API-README                 driver-opencl.h    SCRYPT-README
arg-nonnull.h              driver-ztex.c      sha256_4way.c
AUTHORS                    elist.h            sha256_altivec_4way.c
autogen.sh                 example.conf       sha256_cryptopp.c
autom4te.cache             findnonce.c        sha256_generic.c
bench_block.h              findnonce.h        sha256_sse2_amd64.c
bitforce-firmware-flash.c  FPGA-README        sha256_sse2_i386.c
bitstreams                 fpgautils.c        sha256_sse4_amd64.c
ccan                       fpgautils.h        sha256_via.c
c++defs.h                  install-sh         sha2.c
cgminer.c                  lib                sha2.h
ChangeLog                  libztex.c          stamp-h1
compat                     libztex.h          todo_ztex.txt
compat.h                   LICENSE            usbutils.c
compile                    linux-usb-cgminer  usbutils.h
config.guess               logging.c          uthash.h
config.h                   logging.h          util.c
config.h.in                m4                 util.h
config.h.in~               Makefile           warn-on-use.h
config.log                 Makefile.am        windows-build.txt
config.status              Makefile.in        x86_32
config.sub                 miner.h            x86_64
configure                  miner.php
configure.ac               missing


The configure.acc is missing, i reinstalled the third time, at the second time it was available - don't know why but is it was, -> aclocal.m4 was missing -lol- =/

does anyone has some information for me, how i can move on?

greets Killa






 

[jv13613]

@KillaGT

I would recommend you start a new topic to get help on this. As for now I recommend you install yaourt. run "yaourt -AS cgminer-git". When it ask you if you want to edit the PKGBUILD file say yes, type in nano if it ask for an editor. Then proced to delete "'libcl'" from the depends= line. ctr-o hit enter, then crt-x. This should compile cgminer from git on your pogoplug. yaourt automates the process. When your done you should have a package file you can install with pacman. You will probably run out of ram when compiling so you will need to set up a ram file on another usb drive. It would be simpler if you just used the precompiled binaries I have made. I'll PM them to you. Also don't follow any of my directions without completely knowing what they do. (you should learn something along the way!)