[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[JarBinks]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

I think the current format has become the defacto standard.
Though I am all about being different, I.E. bleeding edge, and I support any change.

My only concern would be that no changes happen with how the API is presents data, which I am pretty sure this will not.

[1695664006]

1695664006

[1695664006]

1695664006

[1695664006]

1695664006

[1695664006]

1695664006

[joblo]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

I think the current format has become the defacto standard.
Though I am all about being different, I.E. bleeding edge, and I support any change.

My only concern would be that no changes happen with how the API is presents data, which I am pretty sure this will not.

Thanks for your comment.

I agree the API should not be different among miners as well as primary command line options. Console output is a little
less rigid.

I believe the current format, with some variations, is the convention for cpuminer and ccminer only. Those variations include
displaying hash count as well as rate, and "yes!" "noooo" instead of "yeah!!!" "boooo". AMD miners and alternative miners
have completely different output formats. I don't feel bound by the current format if it can be improved.

Any change to the output format could  affect users who run filters on the output and expect a certain format. They would
have to modify their filters for the new format.

[JarBinks]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

I think the current format has become the defacto standard.
Though I am all about being different, I.E. bleeding edge, and I support any change.

My only concern would be that no changes happen with how the API is presents data, which I am pretty sure this will not.

Thanks for your comment.

I agree the API should not be different among miners as well as primary command line options. Console output is a little
less rigid.

I believe the current format, with some variations, is the convention for cpuminer and ccminer only. Those variations include
displaying hash count as well as rate, and "yes!" "noooo" instead of "yeah!!!" "boooo". AMD miners and alternative miners
have completely different output formats. I don't feel bound by the current format if it can be improved.

Any change to the output format could  affect users who run filters on the output and expect a certain format. They would
have to modify their filters for the new format.

Good point about the people parsing the output!!!
Maybe make a switch to allow the new and improved vs. the legacy output just in case.

[felixbrucker]

that seemed to have worked, now it complains about missing gmp.h however

edit: added gmp.h from here http://cs.nyu.edu/~exact/core/gmp/index.html, now compile fails but im unsure why, windows building is pita



wonderful garbled text from msys

i guess i have done something wrong, might need a guide for dummies, will wait for someone else to build bins

cheers

What CPU? Did you compile native or specify -march=?

This error is in AES code, which suggests your CPU doesn't have it but the compiler thought it did.

Edit: In case it isn't obvious this is significant progress in helping me. If the compiler can't figure out the correct
architecture it can be specified manually.

the cpu is a i5-3330, it has aes, though im pretty sure the only thing holding me back from compiling successfully is somehow PATH related

steps done:

downloaded the mingw32 installer and installed basics+msys (32bit) to C:\mingw
downloaded mingw64 (x86_64-6.2.0-posix-seh-rt_v5-rev0) to C:\mingw64
added various C:\mingw64 directories to the system PATH
started a msys shell (from c:\mingw\msys...)
compiled curl source with ./configure --host=x86_64-w64-mingw32 --prefix=/c/mingw64
merged pthread mingw64 dir with C:\mingw64 dir
merged OpenSSL-Win64 include dir into mingw64 include

started winbuild.sh, complained about curl.h, so i copied it into the cpuminer dir to not spend hours with the obviously not working PATH
same for openssl and pthread

after this it complained about some double initialization or something of time in sys/time.h, so i copied the mingw64 versions of the files into the cpuminer dir

after this only the gmp.h was missing and then the garbled output from thge screen above appeared


i think some bins/libs used to compile are still 32bit ones as the PATH or at least the PATH the msys shell uses do not use the mingw64 ones but the 32 bit

which steps did differ for your setup?

to my understanding mingw32 is only needed for msys (its not included in mingw64 it seems), is this correct? i would skip the whole mingw32 part if i could and only use mingw64 if this works too, so there is no chance some 32bit bins/libs are getting used

cheers

[felixbrucker]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

my only suggestion for the output (if you are going to change it): make the space before "accepted" before the coloring stuff, right now its like this:
[01;37m accepted[...]
to
 [01;37maccepted[...]

cheers

[th3.r00t]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

In ccminer there is a "yes!" - accepted share, "nooooo" - rejected share and "yay!!!" which is share that found a block.
I believe that it this come from pooler's original cpuminer.

So if you intend to change the format, how do you mark a share resulting a block find?

In general i like the idea of redesigning the output.
I would really love output format like SGminer here in cpuminer-opt (one can dream )

[Q_R_V]

start /high ?

"start /low" - process will have low priority, useful when you have other more important processes running on your OS.

[joblo]

What CPU? Did you compile native or specify -march=?

This error is in AES code, which suggests your CPU doesn't have it but the compiler thought it did.

the cpu is a i5-3330, it has aes, though im pretty sure the only thing holding me back from compiling successfully is somehow PATH related

In my setup I didn't add any extra files to cpuminer but I did have to add some to /msys/opt/windows_64.

Right now your problem isn't the setup but the architecture selection. The 3330 is indeed Ivybridge and should have
both AES and AVX. Your compiler chose "ivybridge" but trips over the AES code. As I mentioned my compiler doesn't
accept brand names like ivybridge, only architecture names like core-avx-i and corei7-avx. Try compiling specifying
different architectures until the AES error goes away then we can compare what works with what should have worked

[joblo]

In ccminer there is a "yes!" - accepted share, "nooooo" - rejected share and "yay!!!" which is share that found a block.
I believe that it this come from pooler's original cpuminer.

That's interesting. It definitely isn't implemented that way in cpuminer and I don't recall seeing any code regarding
block finder. I will take a look at Pooler. If he has impmeneted it that way it's worth considering.

Edit: I just looked at he latest Pooler code and he still uses yay!!!/boooo for accepted/rejected shares with no indication
of finding a block. It's an interesting idea but I don't see anywhere that the pool communicates that info to the miner.

[joblo]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

my only suggestion for the output (if you are going to change it): make the space before "accepted" before the coloring stuff, right now its like this:
[01;37m accepted[...]
to
 [01;37maccepted[...]

cheers

I don't understand what you are saying.

[felixbrucker]

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

my only suggestion for the output (if you are going to change it): make the space before "accepted" before the coloring stuff, right now its like this:
[01;37m accepted[...]
to
 [01;37maccepted[...]

cheers

I don't understand what you are saying.

ok ill try

redirecting the miner output to file instead of the console reveals the structure of the text, like this:


lines starting with ESC/weird symbols are other colors than default grey, for example "accepted" messages are white and the "yes" is green

note that this "color code" starts right after the date/time and the space betweent date/time and the actual message is "colored"

this "colored" space could be moved before the coloring so if someone filters the output and wants to cut off the date/time they dont have to deal with removing the 9th char (or so) to preserve colors

cheers

[joblo]

redirecting the miner output to file instead of the console reveals the structure of the text, like this:


lines starting with ESC/weird symbols are other colors than default grey, for example "accepted" messages are white and the "yes" is green

note that this "color code" starts right after the date/time and the space betweent date/time and the actual message is "colored"

this "colored" space could be moved before the coloring so if someone filters the output and wants to cut off the date/time they dont have to deal with removing the 9th char (or so) to preserve colors

cheers

Ok I understand now I think. Everything before "accepted", including the bold font code and the space is part of the applog prefix
that is automatically prepended to the output. If I changed that it would affect everywhere applog is called. Anyone parsing the
output should use --no-color option.

[felixbrucker]

ahh i see, well loosing the colors then

thanks for the explanation!

[felixbrucker]

trying to compile for mingw64 i get this error (3.4.4b, march=native and march=core2):

Code:

algo/hodl/hodl.cpp: In function 'int scanhash_hodl(int, work*, uint32_t, uint64_t*)':
algo/hodl/hodl.cpp:96:18: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
   EVP_CIPHER_CTX ctx;
                  ^

im a bit lost there, anyone got an idea what the problem might be?

[joblo]

ahh i see, well loosing the colors then

thanks for the explanation!

Have you made any progress compiling on Windows with your i5-3330 using different -march= flags?
That AES error seems to be the current blocker.

I'm trying to recall anything I did outside of process in the mingw environment. All of the missing libraries were installed to
/msys/opt/windows_64, nothing was added to cpuminer.

Any #include that uses <file.h> instead of "file.h" expects to find the file in /msys/opt/windows_64/include.
Unfortunately I didn't keep good notes while I was hacking and have to rely on memory

[joblo]

trying to compile for mingw64 i get this error (3.4.4b, march=native and march=core2):

Code:

algo/hodl/hodl.cpp: In function 'int scanhash_hodl(int, work*, uint32_t, uint64_t*)':
algo/hodl/hodl.cpp:96:18: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
   EVP_CIPHER_CTX ctx;
                  ^

im a bit lost there, anyone got an idea what the problem might be?

If you've copied files to the cpuminer directory you should start fresh pristine source. You should never have to
copy any files into cpuminer.

There appears to be a problem with the ssl install. Search for evp.h, it will be in an includes dir with a bunch of
other files. Create a symlink in /msys/opt/windows_64/include to point to the openssl include directory. You should
do this for any 3rd party packages you need to install in order to compile cpuminer, such as gmp.

Edit: I'm getting a bit lost too. The last error you reported was with AES code. What happened to that?

[felixbrucker]

trying to compile for mingw64 i get this error (3.4.4b, march=native and march=core2):

Code:

algo/hodl/hodl.cpp: In function 'int scanhash_hodl(int, work*, uint32_t, uint64_t*)':
algo/hodl/hodl.cpp:96:18: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
   EVP_CIPHER_CTX ctx;
                  ^

im a bit lost there, anyone got an idea what the problem might be?

If you've copied files to the cpuminer directory you should start fresh pristine source. You should never have to
copy any files into cpuminer.

There appears to be a problem with the ssl install. Search for evp.h, it will be in an includes dir with a bunch of
other files. Create a symlink in /msys/opt/windows_64/include to point to the openssl include directory. You should
do this for any 3rd party packages you need to install in order to compile cpuminer, such as gmp.

i have started a fresh compile, this time in linux and cross-compiling to mingw64, no files have been added to the cpuminer-opt dir, the PATH variable works fine here

will investigate the ssl issue, ive crosscompiled ssl libs/headers, might be using system headers

cheers

[felixbrucker]

trying to compile for mingw64 i get this error (3.4.4b, march=native and march=core2):

Code:

algo/hodl/hodl.cpp: In function 'int scanhash_hodl(int, work*, uint32_t, uint64_t*)':
algo/hodl/hodl.cpp:96:18: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
   EVP_CIPHER_CTX ctx;
                  ^

im a bit lost there, anyone got an idea what the problem might be?

If you've copied files to the cpuminer directory you should start fresh pristine source. You should never have to
copy any files into cpuminer.

There appears to be a problem with the ssl install. Search for evp.h, it will be in an includes dir with a bunch of
other files. Create a symlink in /msys/opt/windows_64/include to point to the openssl include directory. You should
do this for any 3rd party packages you need to install in order to compile cpuminer, such as gmp.

i have started a fresh compile, this time in linux and cross-compiling to mingw64, no files have been added to the cpuminer-opt dir, the PATH variable works fine here

will investigate the ssl issue, ive crosscompiled ssl libs/headers, might be using system headers

cheers

problem found: i used the latest stable openssl version (1.1.0) but using 1.0.2h it is working fine

now im seeing a linker issue, but i think this is trivial:

Code:

/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lcurl
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lz
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lssl
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lcrypto
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lgmp

compiler successfully gets till the last compile step, im on the finish road i guess

cheers

[felixbrucker]

after including the lib dir with "-L/opt/mingw64/lib" only -lz was missing, after crosscompiling and copying the bin/lib/and include files into mingw64 the following error is displayed:

Code:

x86_64-w64-mingw32-g++  -O3 -march=native -Wall -I/opt/mingw64/include -L/opt/mingw64/lib -std=gnu++11 -fpermissive -Lcompat/pthreads/x64  -Lyes/lib  -Lcompat/pthreads/x64  -Lyes/lib  -o cpuminer.exe cpuminer-cpu-miner.o cpuminer-util.o cpuminer-uint256.o cpuminer-api.o cpuminer-sysinfos.o cpuminer-algo-gate-api.o algo/groestl/cpuminer-sph_groestl.o algo/skein/cpuminer-sph_skein.o algo/bmw/cpuminer-sph_bmw.o algo/shavite/cpuminer-sph_shavite.o algo/shavite/cpuminer-shavite.o algo/echo/cpuminer-sph_echo.o algo/blake/cpuminer-sph_blake.o algo/heavy/cpuminer-sph_hefty1.o algo/blake/cpuminer-mod_blakecoin.o algo/luffa/cpuminer-sph_luffa.o algo/cubehash/cpuminer-sph_cubehash.o algo/simd/cpuminer-sph_simd.o algo/hamsi/cpuminer-sph_hamsi.o algo/fugue/cpuminer-sph_fugue.o algo/gost/cpuminer-sph_gost.o algo/jh/cpuminer-sph_jh.o algo/keccak/cpuminer-sph_keccak.o algo/keccak/cpuminer-keccak.o algo/sha3/cpuminer-sph_sha2.o algo/sha3/cpuminer-sph_sha2big.o algo/shabal/cpuminer-sph_shabal.o algo/whirlpool/cpuminer-sph_whirlpool.o crypto/cpuminer-blake2s.o crypto/cpuminer-oaes_lib.o crypto/cpuminer-c_keccak.o crypto/cpuminer-c_groestl.o crypto/cpuminer-c_blake256.o crypto/cpuminer-c_jh.o crypto/cpuminer-c_skein.o crypto/cpuminer-hash.o crypto/cpuminer-aesb.o crypto/cpuminer-magimath.o algo/argon2/cpuminer-argon2a.o algo/argon2/ar2/cpuminer-argon2.o algo/argon2/ar2/cpuminer-opt.o algo/argon2/ar2/cpuminer-cores.o algo/argon2/ar2/cpuminer-ar2-scrypt-jane.o algo/argon2/ar2/cpuminer-blake2b.o algo/cpuminer-axiom.o algo/blake/cpuminer-blake.o algo/blake/cpuminer-blake2.o algo/blake/cpuminer-blakecoin.o algo/blake/cpuminer-decred.o algo/blake/cpuminer-pentablake.o algo/bmw/cpuminer-bmw256.o algo/cubehash/sse2/cpuminer-cubehash_sse2.o algo/cryptonight/cpuminer-cryptolight.o algo/cryptonight/cpuminer-cryptonight-common.o algo/cryptonight/cpuminer-cryptonight-aesni.o algo/cryptonight/cpuminer-cryptonight.o algo/cpuminer-drop.o algo/echo/aes_ni/cpuminer-hash.o algo/cpuminer-fresh.o algo/groestl/cpuminer-groestl.o algo/groestl/cpuminer-myr-groestl.o algo/groestl/sse2/cpuminer-grso.o algo/groestl/sse2/cpuminer-grso-asm.o algo/groestl/aes_ni/cpuminer-hash-groestl.o algo/groestl/aes_ni/cpuminer-hash-groestl256.o algo/haval/cpuminer-haval.o algo/heavy/cpuminer-heavy.o algo/heavy/cpuminer-bastion.o algo/cpuminer-hmq1725.o algo/hodl/cpuminer-hodl.o algo/hodl/cpuminer-hodl-gate.o algo/hodl/cpuminer-hodl_arith_uint256.o algo/hodl/cpuminer-hodl_uint256.o algo/hodl/cpuminer-hash.o algo/hodl/cpuminer-hmac_sha512.o algo/hodl/cpuminer-sha256.o algo/hodl/cpuminer-sha512.o algo/hodl/cpuminer-utilstrencodings.o algo/hodl/cpuminer-hodl-wolf.o algo/hodl/cpuminer-aes.o algo/hodl/cpuminer-sha512_avx.o algo/hodl/cpuminer-sha512_avx2.o algo/cpuminer-lbry.o algo/luffa/cpuminer-luffa.o algo/luffa/sse2/cpuminer-luffa_for_sse2.o algo/lyra2/cpuminer-lyra2.o algo/lyra2/cpuminer-sponge.o algo/lyra2/cpuminer-lyra2rev2.o algo/lyra2/cpuminer-lyra2re.o algo/keccak/sse2/cpuminer-keccak.o algo/cpuminer-m7m.o algo/cpuminer-neoscrypt.o algo/cpuminer-nist5.o algo/cpuminer-pluck.o algo/quark/cpuminer-quark.o algo/qubit/cpuminer-qubit.o algo/ripemd/cpuminer-sph_ripemd.o algo/cpuminer-scrypt.o algo/scryptjane/cpuminer-scrypt-jane.o algo/sha2/cpuminer-sha2.o algo/simd/sse2/cpuminer-nist.o algo/simd/sse2/cpuminer-vector.o algo/skein/cpuminer-skein.o algo/skein/cpuminer-skein2.o algo/cpuminer-s3.o algo/tiger/cpuminer-sph_tiger.o algo/cpuminer-veltor.o algo/whirlpool/cpuminer-whirlpool.o algo/whirlpool/cpuminer-whirlpoolx.o algo/x11/cpuminer-x11.o algo/x11/cpuminer-x11evo.o algo/x11/cpuminer-x11gost.o algo/x11/cpuminer-c11.o algo/x13/cpuminer-x13.o algo/x14/cpuminer-x14.o algo/x15/cpuminer-x15.o algo/x17/cpuminer-x17.o algo/yescrypt/cpuminer-yescrypt.o algo/yescrypt/cpuminer-yescrypt-common.o algo/yescrypt/cpuminer-sha256_Y.o algo/yescrypt/cpuminer-yescrypt-simd.o algo/cpuminer-zr5.o asm/cpuminer-neoscrypt_asm.o  asm/cpuminer-sha2-x64.o asm/cpuminer-scrypt-x64.o asm/cpuminer-aesb-x64.o  compat/cpuminer-winansi.o -lcurl -lz compat/jansson/libjansson.a -lpthread -L/mingw/x86_64-w64-mingw32/lib -lws2_32 -lssl -lcrypto -lgmp
cpuminer-util.o:util.c:(.text+0x4e6): undefined reference to `localtime_s'
cpuminer-util.o:util.c:(.text+0x632): undefined reference to `localtime_s'
cpuminer-util.o:util.c:(.text+0x784): undefined reference to `localtime_s'
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cpuminer-util.o: bad reloc address 0x11 in section `.text.unlikely'
collect2: error: ld returned 1 exit status

[joblo]

trying to compile for mingw64 i get this error (3.4.4b, march=native and march=core2):

Code:

algo/hodl/hodl.cpp: In function 'int scanhash_hodl(int, work*, uint32_t, uint64_t*)':
algo/hodl/hodl.cpp:96:18: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
   EVP_CIPHER_CTX ctx;
                  ^

im a bit lost there, anyone got an idea what the problem might be?

If you've copied files to the cpuminer directory you should start fresh pristine source. You should never have to
copy any files into cpuminer.

There appears to be a problem with the ssl install. Search for evp.h, it will be in an includes dir with a bunch of
other files. Create a symlink in /msys/opt/windows_64/include to point to the openssl include directory. You should
do this for any 3rd party packages you need to install in order to compile cpuminer, such as gmp.

i have started a fresh compile, this time in linux and cross-compiling to mingw64, no files have been added to the cpuminer-opt dir, the PATH variable works fine here

will investigate the ssl issue, ive crosscompiled ssl libs/headers, might be using system headers

cheers

problem found: i used the latest stable openssl version (1.1.0) but using 1.0.2h it is working fine

now im seeing a linker issue, but i think this is trivial:

Code:

/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lcurl
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lz
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lssl
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lcrypto
/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lgmp

compiler successfully gets till the last compile step, im on the finish road i guess

cheers

Is this on Linux or windows? I think trying to cross compile is complicating the issue. I'm trying to follow but am
getting lost jumping around from Linux to windows to cross compiling. It also helps if you say how you compiled.

I looked at my system and I don't see those packages in msys/opt/windows_64/lib/ but it compiles and links ok.
This is getting beyond me, I don't know how to proceed.

I'm going to have to build a mingw compile environment in a VM and document everything I do.

You can still use the precompiled windows binaries. You should get optimum performance or your Ivybridge using the
core-avx-i version. Only the older Intels (like Westmere) and AMDs might have issues.