You are not logged in.
As I want to set up an old computer with a modern Ati card for gpu mining, I am facing an annoying problem:
When trying to start claymore95, I receive this error message:
./ethdcrminer64: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./ethdcrminer64)
Hardly anyone else seem to have that problem... I installed libcurl-openssl-1.0 from AUR but that does not help.
Anyone know a solution? It seems to be a lib problem for Arch, as I did not had it an Linuxmint.
Last edited by Spot (2017-06-24 19:23:48)
Offline
try libcurl-compat or lib32-libcurl-compat
Last edited by ugjka (2017-06-22 15:28:49)
https://ugjka.net
paru > yay | webcord > discord
pacman -S spotify-launcher
mount /dev/disk/by-...
Offline
I have installed both, but no luck!
Maybe its a linking problem?
Last edited by Spot (2017-06-22 15:30:28)
Offline
What are claymore and ethdcrminer64? Are these things that we could test to help identify the problem?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Those are programs used for ethereum mining on gpus. You can get it here https://github.com/nanopool/Claymore-Dual-Miner
Last edited by Spot (2017-06-22 15:45:49)
Offline
Ah, thanks. Is there a source version or just the binary? With just the binary may need to LD_PRELOAD an older version of libcurl.
EDIT: I confirmed I get the same error, but can avoid it with the following:
LD_PRELOAD=/usr/lib/libcurl.so.3 ./ethdcrminer64
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Thanks for the super fast responce.
But despite pre-loading the lip, I still get the same error:
[spot@Terra claymore95]$ LD_PRELOAD=/usr/lib/libcurl.so.3 ./ethdcrminer64
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file. This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it. You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run. This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.
--list list all dependencies and how they are resolved
--verify verify that given object really is a dynamically linked
object we can handle
--inhibit-cache Do not use /etc/ld.so.cache
--library-path PATH use given PATH instead of content of the environment
variable LD_LIBRARY_PATH
--inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
in LIST
--audit LIST use objects named in LIST as auditors
Trying to start claymore:
[spot@Terra claymore95]$ ./mine.sh
./ethdcrminer64: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./ethdcrminer64)
Thats how the linking is:
[spot@Terra claymore95]$ ls -l /usr/lib/libcurl*
-rwxr-xr-x 1 root root 492896 26. Apr 21:24 /usr/lib/libcurl-compat.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.3 -> libcurl-gnutls.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.4 -> libcurl-gnutls.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.4.0.0 -> libcurl-gnutls.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.4.1.0 -> libcurl-gnutls.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.4.2.0 -> libcurl-gnutls.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.4.3.0 -> libcurl-gnutls.so.4.4.0
-rwxr-xr-x 1 root root 463184 26. Apr 21:28 /usr/lib/libcurl-gnutls.so.4.4.0
lrwxrwxrwx 1 root root 28 22. Jun 17:08 /usr/lib/libcurl-openssl-1.0.so -> libcurl-openssl-1.0.so.4.4.0
-rwxr-xr-x 1 root root 517728 22. Jun 17:08 /usr/lib/libcurl-openssl-1.0.so.4.4.0
lrwxrwxrwx 1 root root 16 14. Jun 10:59 /usr/lib/libcurl.so -> libcurl.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:24 /usr/lib/libcurl.so.3 -> libcurl-compat.so.4.4.0
lrwxrwxrwx 1 root root 16 14. Jun 10:59 /usr/lib/libcurl.so.4 -> libcurl.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:24 /usr/lib/libcurl.so.4.0.0 -> libcurl-compat.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:24 /usr/lib/libcurl.so.4.1.0 -> libcurl-compat.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:24 /usr/lib/libcurl.so.4.2.0 -> libcurl-compat.so.4.4.0
lrwxrwxrwx 1 root root 23 26. Apr 21:24 /usr/lib/libcurl.so.4.3.0 -> libcurl-compat.so.4.4.0
-rwxr-xr-x 1 root root 513784 14. Jun 10:59 /usr/lib/libcurl.so.4.4.0
/usr/lib/libcurl-openssl-1.0:
insgesamt 0
lrwxrwxrwx 1 root root 31 22. Jun 17:08 libcurl.so -> ../libcurl-openssl-1.0.so.4.4.0
lrwxrwxrwx 1 root root 31 22. Jun 17:08 libcurl.so.4 -> ../libcurl-openssl-1.0.so.4.4.0
lrwxrwxrwx 1 root root 31 22. Jun 17:08 libcurl.so.4.4.0 -> ../libcurl-openssl-1.0.so.4.4.0
Last edited by Spot (2017-06-22 18:27:37)
Offline
mine.sh does apparently not set LD_PRELOAD and why do you get the ld.so usage help when running ./ethdcrminer64?? Is that a script that itself attempts to call ld.so and if so, does it only w/ an LD_PRELOAD set and what does it call exactly (if it's a shell script you can just open it in a text editor)
Offline
The content of mine.sh is:
#!/bin/sh
export GPU_MAX_ALLOC_PERCENT=100
./ethdcrminer64 -epool us1.ethermine.org:4444 -ewal WALLETADRESS.MINERIG_NAME -epsw x -mode 1 -tt 68 -allpools 1
However starting with ./ethdcrminer64 and using the given config-file for the options dont work either:
LD_PRELOAD=/usr/lib/libcurl.so.3 ./ethdcrminer64
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
.
.
.
[spot@Terra claymore95]$ ./ethdcrminer64
./ethdcrminer64: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./ethdcrminer64)
Unfortunatly "ethdcrminer64" is a binary file and not a shell script.
Btw there is also a way to use geth and cpp-ethereum to mine ethereum coins.
But thats not working either...I made a comment (date: 2017-06-22 19:34) on the specific AUR site for that package.
Last edited by Spot (2017-06-22 20:15:52)
Offline
I've zero knowledge about the clients you're trying to use.
What does this do?
LD_PRELOAD=/usr/lib/libcurl.so.3 xterm
LD_PRELOAD=/usr/lib/libgnarf.so xterm # spitting errors about missing libgnarf.so is ok, printing the ld.so usage help is not
LD_PRELOAD=/usr/lib/libgnarf.so ./ethdcrminer64 # spitting errors about missing libgnarf.so is ok, printing the ld.so usage help is not
Offline
Hi Seth,
I've zero knowledge about the clients you're trying to use.
What does this do?
LD_PRELOAD=/usr/lib/libcurl.so.3 xterm
This opens xterm in a new window.
LD_PRELOAD=/usr/lib/libgnarf.so xterm # spitting errors about missing libgnarf.so is ok, printing the ld.so usage help is not
This open a xterm window and promting:
(no ld.so usage printing)
ERROR: ld.so: object '/usr/lib/libgnarf.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
The last one...
LD_PRELOAD=/usr/lib/libgnarf.so ./ethdcrminer64 # spitting errors about missing libgnarf.so is ok, printing the ld.so usage help is not
...prompts the ld.so usage
LD_PRELOAD=/usr/lib/libgnarf.so ./ethdcrminer64
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file. This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it. You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run. This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.
--list list all dependencies and how they are resolved
--verify verify that given object really is a dynamically linked
object we can handle
--inhibit-cache Do not use /etc/ld.so.cache
--library-path PATH use given PATH instead of content of the environment
variable LD_LIBRARY_PATH
--inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
in LIST
--audit LIST use objects named in LIST as auditors
Offline
Ok, something is very fishy with your system having nothing to do with this claymore stuff.
I've really never seen anything like that, and I'm not really sure where to start troubleshooting, but lets gather some basics: What shell do you use, and what's the output of `env`?
(edit: I misread previous output)
Last edited by Trilby (2017-06-23 10:42:02)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
file ethdcrminer64
Then stat whatever it spits out as interpreter for you (/lib64/ld-linux-x86-64.so.2 on the version I downloaded)
stat /lib64/ld-linux-x86-64.so.2
It's likely a symlink, so in doubt inspect the result as well (notably whether it's ELF or some wrapper script)
Also the md5sum of my Download of that file is
23a5f302fe128a6be79caf92f7ff36eb ethdcrminer64
Offline
I use the standard shells with the xfce4-terminal and terminator.
"env" displays:
[spot@Terra Schreibtisch]$ env
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.patch=00;32:*.diff=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/dri/:/usr/lib32/xorg/modules/dri
LC_MEASUREMENT=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
XDG_MENU_PREFIX=xfce-
LANG=de_DE.utf8
YAOURT_COLORS=nb=1:pkg=1:ver=1;32:lver=1;45:installed=1;42:grp=1;34:od=1;41;5:votes=1;44:dsc=0:other=1;35
DISPLAY=:0.0
COLORTERM=truecolor
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=7
SSH_AUTH_SOCK=/tmp/ssh-OtB9Nu376C2X/agent.8019
GLADE_CATALOG_PATH=:
LC_NAME=de_DE.UTF-8
XDG_SESSION_ID=c2
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/spot
USER=joschkar
GLADE_MODULE_PATH=:
DESKTOP_SESSION=xfce
QT_QPA_PLATFORMTHEME=qt5ct
PWD=/home/spot/Schreibtisch
HOME=/home/spot
SSH_AGENT_PID=8025
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_SESSION_DESKTOP=xfce
LC_ADDRESS=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
GLADE_PIXMAP_PATH=:
GTK_MODULES=canberra-gtk-module:canberra-gtk-module
MAIL=/var/spool/mail/spot
TERM=xterm-256color
SHELL=/bin/bash
VTE_VERSION=4803
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_CURRENT_DESKTOP=XFCE
SHLVL=3
XDG_SEAT=seat0
WINDOWID=56623107
LC_TELEPHONE=de_DE.UTF-8
GDMSESSION=xfce
LOGNAME=spot
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/home/spot/.Xauthority
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_CONFIG_DIRS=/etc/xdg
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
LC_IDENTIFICATION=de_DE.UTF-8
SESSION_MANAGER=local/Terra:@/tmp/.ICE-unix/7836,unix/Terra:/tmp/.ICE-unix/7836
LC_TIME=de_DE.UTF-8
_=/usr/bin/env
The file command promts:
[spot@Terra claymore95]$ file ethdcrminer64
ethdcrminer64: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4b2d01fde66246066d42cc7e620da32289cbc374, stripped
md5sum prints this:
[spot@Terra claymore95]$ md5sum ethdcrminer64
a919e303d2250f2719c7a28bfebd9a79 ethdcrminer64
This problem occurs on both my normal Arch and on the Manjaro Arch
Offline
Oops, I misread some of your previous output. I thought you were getting the ld.so help output every time you used LD_PRELOAD - but it does seem to be only with the claymore related binary. But note again, I *don't* get that ld.so output with the ethdcrminer64 - I do get the original error, but LD_PRELOAD=... avoids the problem.
For your shell *which* one do you use? Saying you use "standard shells" doesn't mean anything. Does this mean bash or zsh which are both common enough for some to call standard, or fish, ksh, ash, dash, etc? (edit: nevermind, bash is listed in your env output).
Also for future reference, there is no such thing as "Manjaro Arch". You can run Arch Linux and Manjaro, but these are two different distros. It seems you may have set something up on each of them that is causing problems.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Did you notice the md5sum difference?
I fetched https://github.com/nanopool/Claymore-Du … NUX.tar.gz
The ethdcrminer64 file in there also isn't suid'd and its BuildID differs...
Offline
Yeah I saw the md5sum difference, but I have no idea on how to interpret that
I am currently trying to set up another mining program, but thats not working either.
Last edited by Spot (2017-06-23 14:46:43)
Offline
Yeah I saw the md5sum difference, but I have no idea on how to interpret that
There is no subjective interpretation necessary - quite plainly, the link you provided us with is not the same program that you are running.
The most likely cause of this is that you have an older version. Download the same program you directed us to and you should get the same output we do.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I am sorry about causing confusion about the claymore version.
Please see http://www.cryptobadger.com/2017/04/bui … rig-linux/ and refer to step 6 for the link to the newest claymore version.
The Github pages seems to have only the older version.
Last edited by Spot (2017-06-23 15:04:11)
Offline
Alright, I downloaded that version and can confirm the same md5sum and buildID that you have, but I still cannot replicate your problem. Without LD_PRELOAD I get the same error you did at the start of the thread, but with LD_PRELOAD the program runs: I do get a warning about libcurl, but the program does run and I certainly don't get that ld.so help output.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Ok please try this: Add the LD_PRELOAD Option to the mine.sh script.
What happens on your system?
Mine will promt
-epool: error while loading shared libraries: -epool: cannot open shared object file
Nothing about libcurl (but that might by oppressed by the script), but also no program start.
Offline
Now thats funny. On my ArchLinux, its suddenly works. Only that this laptop does not have a dedicated graphics card.
But it still refuses to work in Manjaro with the same old problem.
From what I thought, Manjaro shouldn't be that different from ArchLinux to behave that strange, should it?
Offline
Things don't "suddenly work" - either you're still on that other binary on Manjaro or had not tried this on "Real Actual Arch Arch" itfp.
In the latter case it's hard to say what kind of mess Manjaro has done with the ELF loader - it's probably indeed some broken wrapper script to handle different architectures or some such ... *shrug*
Offline
Either way, if it works on Arch, can you mark as SOLVED ? We don't particularly care about Manjaro, you will have to ask on their boards.
Offline