will not build without erroring out

[keefer223]

Describe the bug

Multiple issues during build, see below. Reinstall the software multiple times, to no avail.

To Reproduce
Steps to reproduce the behavior:

1. ./build-debian-11.sh
2. See errors

crypto/oaes_lib.c: In function ‘oaes_get_seed’:
crypto/oaes_lib.c(514,2): warning G888501CD: ‘ftime’ is deprecated [-Wdeprecated-declarations] [/home/keefer/miningcore/src/Miningcore/Miningcore.csproj]

In file included from crypto/slow-hash-lite.c:73:
crypto/slow-hash-lite.c: In function ‘aes_256_assist2’:
/usr/lib/gcc/x86_64-linux-gnu/10/include/wmmintrin.h(87,1): error G26EF8B3F: inlining failed in call to ‘always_inline’ ‘_mm_aeskeygenassist_si128’: target specific option mismatch [/home/keefer/miningcore/src/Miningcore/Miningcore.csproj]

/usr/lib/gcc/x86_64-linux-gnu/10/include/avxintrin.h: In function ‘void prep_dv_avx(__m256i*, __m256i&, __m256&)’:
/usr/lib/gcc/x86_64-linux-gnu/10/include/avxintrin.h(454,1): error GCC5876E4: inlining failed in call to ‘always_inline’ ‘__m256 _mm256_cvtepi32_ps(__m256i)’: target specific option mismatch [/home/keefer/miningcore/src/Miningcore/Miningcore.csproj]

In file included from /usr/lib/gcc/x86_64-linux-gnu/10/include/immintrin.h:51,
from /usr/lib/gcc/x86_64-linux-gnu/10/include/x86intrin.h:32,
from xmrig/crypto/cn/gpu/cn_gpu_avx.cpp:30:
/usr/lib/gcc/x86_64-linux-gnu/10/include/avxintrin.h(908,1): error GF2D1BF8C: inlining failed in call to ‘always_inline’ ‘__m256i _mm256_load_si256(const __m256i*)’: target specific option mismatch [/home/keefer/miningcore/src/Miningcore/Miningcore.csproj]

[ 79%] Built target randomx
Scanning dependencies of target randomx-benchmark
[ 82%] Building CXX object CMakeFiles/randomx-benchmark.dir/src/tests/benchmark.cpp.o
[ 85%] Building CXX object CMakeFiles/randomx-benchmark.dir/src/tests/affinity.cpp.o
[ 88%] Linking CXX executable randomx-benchmark
[ 88%] Built target randomx-benchmark
Scanning dependencies of target randomx-codegen
[ 91%] Building CXX object CMakeFiles/randomx-codegen.dir/src/tests/code-generator.cpp.o
[ 94%] Linking CXX executable randomx-codegen
[ 94%] Built target randomx-codegen
Scanning dependencies of target randomx-tests
[ 97%] Building CXX object CMakeFiles/randomx-tests.dir/src/tests/tests.cpp.o
[100%] Linking CXX executable randomx-tests
[100%] Built target randomx-tests
find . -name '*.o' -exec rm -r {} ;
rm -f librandomarq.so
g++ -shared -pthread -L. -Wl,-whole-archive librandomx.a -Wl,-no-whole-archive -o librandomarq.so -lstdc++ -lgcc -lc
/home/keefer/miningcore/src/Miningcore/Miningcore.csproj(123,9): error MSB3073: The command "(cd /home/keefer/miningcore/src/Miningcore/ && sh build-libs-linux.sh bin/Release/net6.0/)" exited with code -1.

Expected behavior
to build without error

Desktop (please complete the following information):

• OS: Debian 11
• Browser firefox
• Version 91.12

Additional context
Add any other context about the problem here.

[0xIbrahim-t]

i have solved by using a older version of miningcore

[seperatis]

@keefer223 This looks similar to the build error that others were getting. Do you need CryptoNight libs, eg, will you be running a Cryptonight coin pool like Monero, etc? If not, then you can do what OliverW suggested and comment out the last two lines inside build-libs-linux.sh and try again.

Just remember you won't be able to run XMR, and other cryptonight related coins...

[0xIbrahim-t]

@seperatis hi,

I tried that way but still got some errors and ended up using old versions.

[keefer223]

My plan was to be able to run them too. I'm trying to focus on the cpu heavy hitters. While the pool is planned to be installed on a 16 core threadripper, I have another 16 core for some mining, with a 64 core in the works.

…

On Thu, Aug 25, 2022, 10:27 AM 0xIbrahim T || Renloi.org < ***@***.***> wrote: @seperatis <https://github.com/seperatis> hi, I tried that way but still got some errors and ended up using old versions. — Reply to this email directly, view it on GitHub <#1367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIBYOZRDED7KKNIQLNLMGDTV257E3ANCNFSM57LSNUDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[seperatis]

@keefer223 @0xIbrahim-t

Have you guys tried @machinasapiens build-script patch? He says it works for him.

To try it, go here: https://github.com/machinasapiens/miningcore

Then grab your required build-script, eg, build-debian-11.sh and replace the current one with it, and run it.

Report back.

Have you guys tried @machinasapiens build-script patch? He says it works for him.

To try it, go here: https://github.com/machinasapiens/miningcore

Then grab your required build-script, eg, build-debian-11.sh and replace the current one with it, and run it.

You ALSO need this corrected file, otherwise the error will persist:
https://github.com/machinasapiens/miningcore/blob/master/src/Miningcore/Miningcore.csproj

How I fixed this problem: I added line 124 and commented out line 123 which was calling build-libs-linux.sh . I placed the call to build-libs-linux.sh inside the files build-debian-11.sh , build-ubuntu-20.04.sh and build-ubuntu-21.04.sh. This way they run outside of the "dotnet publish" command and do not crash anymore. The crash was being caused by some problem with char encoding.

[keefer223]

Thanks, I'll check it out. I've moved on to working on to another software project that has been on going for some months now and we are moving it over to node-red. This project is for the reptile enthusiasts and requires a lot of hardware and sensors. I'll try the patch before the weeks end

…

On Sat, Aug 27, 2022, 9:50 PM machinasapiens ***@***.***> wrote: Have you guys tried @machinasapiens <https://github.com/machinasapiens> build-script patch? He says it works for him. To try it, go here: https://github.com/machinasapiens/miningcore Then grab your required build-script, eg, build-debian-11.sh and replace the current one with it, and run it. You ALSO need this corrected file, otherwise the error will persist: https://github.com/machinasapiens/miningcore/blob/master/src/Miningcore/Miningcore.csproj How I fixed this problem: I added line 124 and commented out line 123 which was calling build-libs-linux.sh . I placed the call to build-libs-linux.sh inside the files build-debian-11.sh , build-ubuntu-20.04.sh and build-ubuntu-21.04.sh. This way they run outside of the "dotnet publish" command and do not crash anymore. The crash was being caused by some problem with char encoding. — Reply to this email directly, view it on GitHub <#1367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIBYOZVHMEMOAA6ALEXKCRLV3LAYDANCNFSM57LSNUDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Konstantin35]

I installed Debian 11 and built it with ease using ./build-debian-11.sh

Operating System: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 5.10.0-16-amd64
Architecture: x86-64

log : build.txt

therefore, there are no problems in Miningcore, look for problems on your server.

Thanks @Konstantin35, but these friends are all reporting the same issue: #1367 , #1327, #1311 and none of them mentioned Debian. I tested this issue for several days and the problem occured every single time with a clean Ubuntu install. Feel free to try yourself. The solution I proposed fixes the issue for all Debian based distros and does not prejudice the build on Debian itself. With this solution, the only change is that the build for the linux libraries takes place outside and before the dotnet publish thus preventing the problem from occurring in the distros where the issues are being reported. I have no clue why the heck this happening but I believe that it has something to do with char encoding or is a bug on the dotnet builder itself. I couldn't find how to fix this what appears to be a char encoding problem and that's why I simply moved the build of the linux libraries to outside the donet publish, where it runs fine. With my patch there is no problem on Ubuntu anymore. I ran clean and updated virtual machines with Ubuntu on LXD on every single test I did. Unfortunatelly I can't contribute anymore here due to lack of time. I am involved into another project which takes all my time and I love doing. Good luck guys and thank you @oliverw for this cool project. Wir sehen uns.

[keefer223]

Before I get started, I'm not a big fan of Ubuntu, even though Debian and Ubuntu are cousins. I took some time this morning and reinstalled all the required software using machinasapiens miningcore and used machinasapiens debian sh. I made no changes to the program or scripts. I did check the database a couple of times, because I usually use mysql, not mariadb. then launched litecoind. while it was syncing I then started miningcore. It didn't halt!!! Admittedly I wasn't watching every line, but no obvious errors. While litecoind was syncing, miningcore keep stating wait for lct1 (litecoin) to sync. So, we know both they are talking litecoind did sync 100% and miningcore says daemon ... 100% from 10 peers, but that's it. While researching why the program halted, earlier, I did stumble across a situation where the daemon synced 100%, but the pool never recognized the 100% because the system was on a hard drive. My plan is to move the pool over to a 1T SSD and a much faster computer than my test computer this week, then see what happens. I still have to install a frontend, then test the whole pool/system.

…

On Tue, Aug 30, 2022 at 2:22 PM machinasapiens ***@***.***> wrote: Thanks @Konstantin35 <https://github.com/Konstantin35>, but these friends are all reporting the same issue: #1367 <#1367> , #1327 <#1327>, #1311 <#1311> and none of them mentioned Debian. I tested this issue for several days and the problem occured every single time with a clean Ubuntu install. Feel free to try yourself. The solution I proposed fixes the issue for all Debian based distros and does not prejudice the build on Debian itself. With this solution, the only change is that the build for the linux libraries takes place outside and before the dotnet publish thus preventing the problem from occurring in the distros where the issues are being reported. I have no clue why the heck this happening but I believe that it has something to do with char encoding or is a bug on the dotnet builder itself. I couldn't find how to fix this what appears to be a char encoding problem and that's why I simply moved the build of the linux libraries to outside the donet publish, where it runs fine. With my patch there is no problem on Ubuntu anymore. I ran clean and updated virtual machines with Ubuntu on LXD on every single test I did. Unfortunatelly I can't contribute anymore here due to lack of time. I am involved into another project which takes all my time and I love doing. Good luck guys and thank you @oliverw <https://github.com/oliverw> for this cool project. Wir sehen uns. — Reply to this email directly, view it on GitHub <#1367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIBYOZQEA7FYUIRL57DK6V3V3ZGNJANCNFSM57LSNUDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[keefer223]

I rebuilt miningcore on another machine; processor: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz MemTotal: 16,239,480 kB ***@***.***:~/miningcore/build$ ./Miningcore -c config.json ███╗ ███╗██╗███╗ ██╗██╗███╗ ██╗ ██████╗ ██████╗ ██████╗ ██████╗ ███████╗ ████╗ ████║██║████╗ ██║██║████╗ ██║██╔════╝ ██╔════╝██╔═══██╗██╔══██╗██╔════╝ ██╔████╔██║██║██╔██╗ ██║██║██╔██╗ ██║██║ ███╗██║ ██║ ██║██████╔╝█████╗ ██║╚██╔╝██║██║██║╚██╗██║██║██║╚██╗██║██║ ██║██║ ██║ ██║██╔══██╗██╔══╝ ██║ ╚═╝ ██║██║██║ ╚████║██║██║ ╚████║╚██████╔╝╚██████╗╚██████╔╝██║ ██║███████╗ https://github.com/oliverw/miningcore Donate to one of these addresses to support the project: BTC - 17QnVor1B6oK1rWnVVBrdX9gFzVkZZbhDm LTC - LTK6CWastkmBzGxgQhTTtCUjkjDA14kxzC DASH - XqpBAV9QCaoLnz42uF5frSSfrJTrqHoxjp ZEC - t1YHZHz2DGVMJiggD2P4fBQ2TAPgtLSUwZ7 ZCL - t1MFU1vD3YKgsK6Uh8hW7UTY8mKAV2xVqBr ETH - 0xcb55abBfe361B12323eb952110cE33d5F28BeeE1 ETC - 0xF8cCE9CE143C68d3d4A7e6bf47006f21Cfcf93c0 XMR - 475YVJbPHPedudkhrcNp1wDcLMTGYusGPF5fqE7XjnragVLPdqbCHBdZg3dF4dN9hXMjjvGbykS6a77dTAQvGrpiQqHp2eH Using configuration file 'config.json' [2022-09-03 15:22:00.2717] [I] [Core] Version 0.1.0.0-master [443f6c5] [2022-09-03 15:22:00.2929] [I] [Core] Runtime .NET 6.0.8 on Linux 5.10.0-17-amd64 #1 SMP Debian 5.10.136-1 (2022-08-13) [X64] [2022-09-03 15:22:00.2983] [I] [Core] Prometheus Metrics API listening on http://127.0.0.1:4000/metrics [2022-09-03 15:22:00.2983] [I] [Core] WebSocket Events streaming on ws:// 127.0.0.1:4000/notifications [2022-09-03 15:22:00.9518] [I] [ShareRecorder] Online [2022-09-03 15:22:00.9871] [I] [PayoutManager] Online [2022-09-03 15:22:00.9871] [I] [StatsRecorder] Online [2022-09-03 15:22:01.0544] [I] [Core] 130 coins loaded from '/home/keefer/miningcore/build/coins.json' [2022-09-03 15:22:01.0675] [I] [ltc1] Starting Pool ... [2022-09-03 15:22:01.0675] [I] [ltc1] ExtraNonceProvider using 4 bits for instance id, 28 bits for 268435455 values, instance id = 0x9 [2022-09-03 15:22:01.0735] [I] [ltc1] Starting Job Manager ... [2022-09-03 15:22:01.1292] [I] [ltc1] All daemons online [2022-09-03 15:22:01.1327] [I] [Core] API Access to /api/admin restricted to 127.0.0.1,::1,::ffff:127.0.0.1 [2022-09-03 15:22:01.1327] [I] [Core] API Access to /metrics restricted to 127.0.0.1,::1,::ffff:127.0.0.1 [2022-09-03 15:22:01.1522] [I] [ltc1] Daemon is still syncing with network. Manager will be started once synced. [2022-09-03 15:22:01.1880] [I] [Core] API access limited to 5 requests per 1s, except from 127.0.0.1, ::1, ::ffff:127.0.0.1 [2022-09-03 15:22:01.1950] [I] [Lifetime] Now listening on: http://127.0.0.1:4000 [2022-09-03 15:22:01.1956] [I] [Lifetime] Application started. Press Ctrl+C to shut down. [2022-09-03 15:22:01.1956] [I] [Lifetime] Hosting environment: Production [2022-09-03 15:22:01.1956] [I] [Lifetime] Content root path: /home/keefer/miningcore/build/ [2022-09-03 15:22:01.2045] [I] [ltc1] Daemon has downloaded 100.00% of blockchain from 27 peers [2022-09-03 15:22:06.2034] [I] [ltc1] Daemon has downloaded 100.00% of blockchain from 26 peers [2022-09-03 15:22:11.1898] [I] [ltc1] Daemon has downloaded 100.00% of blockchain from 26 peers [2022-09-03 15:22:16.0041] [I] [StatsRecorder] Performing Stats GC [2022-09-03 15:22:16.0143] [I] [StatsRecorder] Stats GC complete *[2022-09-03 15:22:16.2017] [I] [ltc1] Daemon has downloaded 100.00% of blockchain from 26 peers [2022-09-03 15:22:21.1962] [I] [ltc1] Daemon has downloaded 100.00% of blockchain from 26 peers [2022-09-03 15:22:26.1924] [I] [ltc1] Daemon has downloaded 100.00% of blockchain from 26 peers * Litecoin is running. Miningcore started displaying the *Daemon has downloaded 100.00% of blockchain from ... after 6 hours of syncing.* *"blocks": 2327167, "headers": 2327167, * However, the Miningcore UI comes up using http://192.168.1.234/miners.html or http://127.0.0.1/miners.html, but no data. I keep getting errors Error: No response from API.(loadStatsChart) and Error: No response from API.(loadMinersList). Any ideas?? Thanks

…

On Tue, Aug 30, 2022 at 3:31 PM Keith Hall ***@***.***> wrote: Before I get started, I'm not a big fan of Ubuntu, even though Debian and Ubuntu are cousins. I took some time this morning and reinstalled all the required software using machinasapiens miningcore and used machinasapiens debian sh. I made no changes to the program or scripts. I did check the database a couple of times, because I usually use mysql, not mariadb. then launched litecoind. while it was syncing I then started miningcore. It didn't halt!!! Admittedly I wasn't watching every line, but no obvious errors. While litecoind was syncing, miningcore keep stating wait for lct1 (litecoin) to sync. So, we know both they are talking litecoind did sync 100% and miningcore says daemon ... 100% from 10 peers, but that's it. While researching why the program halted, earlier, I did stumble across a situation where the daemon synced 100%, but the pool never recognized the 100% because the system was on a hard drive. My plan is to move the pool over to a 1T SSD and a much faster computer than my test computer this week, then see what happens. I still have to install a frontend, then test the whole pool/system. On Tue, Aug 30, 2022 at 2:22 PM machinasapiens ***@***.***> wrote: > Thanks @Konstantin35 <https://github.com/Konstantin35>, but these > friends are all reporting the same issue: #1367 > <#1367> , #1327 > <#1327>, #1311 > <#1311> and none of them > mentioned Debian. I tested this issue for several days and the problem > occured every single time with a clean Ubuntu install. Feel free to try > yourself. The solution I proposed fixes the issue for all Debian based > distros and does not prejudice the build on Debian itself. With this > solution, the only change is that the build for the linux libraries takes > place outside and before the dotnet publish thus preventing the problem > from occurring in the distros where the issues are being reported. I have > no clue why the heck this happening but I believe that it has something to > do with char encoding or is a bug on the dotnet builder itself. I couldn't > find how to fix this what appears to be a char encoding problem and that's > why I simply moved the build of the linux libraries to outside the donet > publish, where it runs fine. With my patch there is no problem on Ubuntu > anymore. I ran clean and updated virtual machines with Ubuntu on LXD on > every single test I did. Unfortunatelly I can't contribute anymore here due > to lack of time. I am involved into another project which takes all my time > and I love doing. Good luck guys and thank you @oliverw > <https://github.com/oliverw> for this cool project. Wir sehen uns. > > — > Reply to this email directly, view it on GitHub > <#1367 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AIBYOZQEA7FYUIRL57DK6V3V3ZGNJANCNFSM57LSNUDQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[oliverw]

There were mutiple PRs working on this but all had problem with the unit tests failing unfortunately.

[keefer223]

Thanks for the update. My problem now is the API working with miningcore-ui. It works on the host computer, but on any other computer I get Error: No response from API. I've played with the API addresses, even took the firewall down. Any ideas?

…

On Fri, Sep 9, 2022 at 7:36 AM Oliver Weichhold ***@***.***> wrote: There were mutiple PRs working on this but all had problem with the unit tests failing unfortunately. — Reply to this email directly, view it on GitHub <#1367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIBYOZVEMFLALLWEYOANOJ3V5MOK5ANCNFSM57LSNUDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>