No, configure is not part of clean package, it is an auto-generated script. Here's a way to prove that:

 * Delete configure and then run build.sh -- magically it somehow reappears.
 * Where from? From configure.ac!

If you want your changes in configure to persist, change the source of that file -- configure.ac

For more info how configure works, read the docs -- https://www.gnu.org/software/autoconf/manual/autoconf.pdf

Write a warning about that somewhere, because this is not how the rest of the world does it.

https://wiki.debian.org/Autoreconf

Debian (and, by extension, Ubuntu) deletes configure and regenerates it from configure.ac on almost every single package that is in the repository.

Your copy of configure also might be too old for newer distros like Arch or Gentoo, and will end up tripping on errors. A simple run of "autoreconf -f -i -v" fixes many of those problems by regenerating that configure script.

Keeping nonperishable source-class information in that place is not sane idea. This is equivalent of editing *.o files after compilation from *.c.

PS: if you insist on keeping configure, then remove it from .gitignore and delete the source file -- configure.ac.

Funny thing is the only thing I do differently than cpuminer-multi is, presumably,  manually edit configure but noticed no
change in the building after doing so. I edit once every release with many make distclean before and after the edit. My changes
never get tossed so there must be something preventing make distclean from deleting configure and autogen.sh from
overwriting it, and it's nothing I've done.

I don't disagree philosophically with anything that has been said about it, but it's not my problem, I'm just doing what the
previous guy did. Since I didn't break it I can't fix it in the sense of putting it back the way I found it.

Also configure.in doesn't exist, configure.ac hasn't changed since October. I'd be shooting in the dark trying to figure it out.
if it didn't work immediately I'd be lost.

It can be frustrating at times when you bring up issues I inherited, know nothing about, and aren't causing me any problems
at the moment. But other than that you know your stuff and I could learn a lot from you, but preferably at a time of my
choosing.

thanks for the diff

also made yiimp support ^^ all since 5h this morning


i use autoreconf alone when i add a file in Makefile.am, i rarely use -fi

@joblo I'm getting this error while trying to solo-mine hodlcoin.

The launch parameters (below), works with the original hodlminer and hodlminer-wolf versions.

./cpuminer -a hodl -o http://192.168.1.x:xxxx -u xxxx -p xxxx -t 4 --coinbase-addr=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --no-getwork -q

Cpuminer-opt v3.3.1 released with support for new algo x11evo (Revolver coin).
The algo has been optimized +109% for AES_NI and 42% for SSE2.

https://drive.google.com/file/d/0B0lVSGQYLJIZWlJaOWtPZ2tESmM/view?usp=sharing

There is a small change in build procedure, a new option to configure not documented in README.md
or supported in build,sh.


Full Windows support is provided except for hodl algo on CPUs without AES_NI. See README.md
for instructions to install mingw_w64 and msys for compiling on Windows. Compiling with Visual
Studio is not supported and no precompiled Windows binaries are provided.

Edit: Cryptomining Blog has built Windows binaries for v3.3. Will give it a try.

http://cryptomining-blog.com/7900-windows-binaries-for-the-cpuminer-opt-3-3-cpu-miner/

Edit2: The CMB package comes with a bunch of DLLs needed to run so it should work for most users.
It runs fine on my i7-4790K Windows 8.1.

Having the same issue @ i5-6200U @ 2.4Ghz on Windows 10