 Show Posts
|
|
Pages: « 1 [2] 3 »
|
Looks like the 1.5.3 configure script inadvertently dropped support for alternate cURL library path support via --with-libcurl: Yes, because it's the crappy way to do it. The right way is to export a variable to specify the PKG_CONFIG_PATH to the correct *.pc file. See my RPMs for reference... Seems to be a way that works on more systems and with local built binaries is the right way to do it. Dependance on a packaging system is the crappy way to do it. No offense, but do read up on pkgconfig a little bit before commenting. For how long have you been involved in packaging? I've told what's the correct way of doing it with pkconfig and locally built binaries. |
|
|
|
Is it possible to use a proxy-server with cgminer?
I can't find any option about it in the first post. I think I told you that you don't need any options for that, just export the http_proxy variable before starting cgminer. |
|
|
|
Looks like the 1.5.3 configure script inadvertently dropped support for alternate cURL library path support via --with-libcurl: Yes, because it's the crappy way to do it. The right way is to export a variable to specify the PKG_CONFIG_PATH to the correct *.pc file. See my RPMs for reference... |
|
|
|
|
So what's the problem? If your proxy listening on port 80 allows for outbound connections to other ports it will work. If not, make your own proxy to listen on port 80 and chain them.
|
|
|
|
|
Yes, anything that curl can do, this miner can do. Try to export the http_proxy variable correctly, it used to work for me.
|
|
|
|
|
The point is that with a fork on github I can see exactly what you have changed as compared to the original files and also easily download your latest changes without tedious copy-pasting from the forum. Also you can easily pull ck's changes into your branch (single command needed for that) and when it will be ready you can just give him the changed files.
A fork on github doesn't mean that you are taking the code away and starting your own project, it's just a way to easily publish your changes for others to test and submit to the original project when ready.
|
|
|
|
|
d3m0n1q_733rz, why wouldn't you create a fork on github? would be easier then copy-pasting and less error-prone.
|
|
|
|
|
+1, I've been using this very successfully so far, but be careful, because it allows you to supply the values outside the range without confirmation. You can brick your card this way if you are not attentive enough.
|
|
|
|
|
Thanks ck! Man, have nice holidays!!! The bugs will wait...
|
|
|
|
|
Yeah, sounds very much like rainbow table attack, I was wondering why nobody seems to be interested in rainbow tables, was thinking that with SHA2 it's impractical due to the huge table size to get any gains required. If you can dig something out... I mean we can collaborate to create a huge table and then rock them all :-)
|
|
|
|
|
The ncurses crash that you fixed in 1.5.0 is back again. This is a really annoying crash and there is no way I can update curses on Ubuntu 10.04 LTS, I was hoping to switch over from Diabolo today :-/
|
|
|
|
|
ck, glitch: ./configure doesn't check for curses.
P.S. Would be nice to enable issues on github, so that bug / feature request are not lost in this thread.
|
|
|
|
That part is an error secondary to the first one which is the sockopt function. What does that part of ./configure show for you? checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
checking for gawk... (cached) gawk
checking for curl-config... (cached) /usr/bin/curl-config
checking for the version of libcurl... (cached) 7.15.5
checking for libcurl >= version 7.15.6... (cached) yes
checking whether libcurl is usable... (cached) yes
checking for curl_free... (cached) yes |
|
|
|
ck, on the other hand, your curl fix was incomplete, it still doesn't work with older curl: util.c:254: error: expected declaration specifiers or '...' before 'curlsocktype'
util.c: In function 'json_rpc_call':
util.c:348: error: 'CURLOPT_SOCKOPTFUNCTION' undeclared (first use in this function)
util.c:348: error: (Each undeclared identifier is reported only once
util.c:348: error: for each function it appears in.)
make[2]: *** [cgminer-util.o] Error 1
make[2]: *** Waiting for unfinished jobs.... I think you should ifdef this function too. What I'm talking about is util.c:254: error: expected declaration specifiers or '...' before 'curlsocktype'What version of curl does that have? My code defines CURL_HAS_SOCKOPT only for versions of curl:
checking for libcurl >= version 7.15.6... (cached) yes
$ rpm -qa | grep curl curl-7.15.5-9.el5_6.3 |
|
|
|
ck, on the other hand, your curl fix was incomplete, it still doesn't work with older curl: util.c:254: error: expected declaration specifiers or '...' before 'curlsocktype'
util.c: In function 'json_rpc_call':
util.c:348: error: 'CURLOPT_SOCKOPTFUNCTION' undeclared (first use in this function)
util.c:348: error: (Each undeclared identifier is reported only once
util.c:348: error: for each function it appears in.)
make[2]: *** [cgminer-util.o] Error 1
make[2]: *** Waiting for unfinished jobs.... I think you should ifdef this function too. |
|
|
|
- Try to do every curses manipulation under the curses lock.
Fabulous! This solved the segfault when attaching a running tmux session. That's one down, thanks! ck, you are the hero, you fixed the segfaults that I was getting under screen or when resizing the terminal on rhel5/ubuntu! |
|
|
|
The most common mode for failure to start is trying to do make install which will FAIL, followed by the wrong url or credentials. Are you sure it is still failing? It's been working for me both on RHEL and Ubuntu. Besides, that's how I am making my packages... |
|
|
|
what's the fix? There is no fix, I just compile it statically against the curl from RHEL6. I ain't pickin up your precompiled code  I am making the SRPM available, feel free to rebuild it yourself if you want. |
|
|
|
The problem with this idea is that network-using static libraries are not supported by glibc. Errr... what? Adding a --with-libcurl=/usr/local/src/newcurl option to configure is reasonably simple. This isn't even needed, because curl gets picked up by pkgconfig (which actually doesn't seem to work, it's rather curl-config that does the trick). Viceroy, I have tried my static curl twist and it worked, updated RPMs here. You know which way to throw your coins ;-) |
|
|
|
|
Added RHEL5 RPMs, these are built statically against curl from RHEL6.
|
|
|
|
|
