Quote from: jv13613 on October 03, 2012, 02:23:51 AM

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.