neofutur
|
|
October 18, 2010, 08:57:20 PM |
|
I updated the ebuild with git, but you ll have to rebuild the manifest in the ebuild : !!! Digest verification failed: !!! /usr/local/portage/net-p2p/bitcoin/files/Makefile.gentoo !!! Reason: Filesize does not match recorded size
I did it : cd net-p2p/bitcoin/ ebuild bitcoin-0.3.13.ebuild manifest Appending /root/bitcoin_gentoo_ebuild to PORTDIR_OVERLAY... >>> Creating Manifest for /root/bitcoin_gentoo_ebuild/net-p2p/bitcoin cp -af net-p2p/ /usr/local/portage/ emerge bitcoin
and it WORKS ! * Enabling SSE2 code >>> Source prepared.
many thanks biomike ! now building, I ll give more feedback later
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
October 21, 2010, 09:47:47 PM |
|
bitcoin-0.3.14.ebuild is on github.
|
|
|
|
neofutur
|
|
October 22, 2010, 02:15:35 PM |
|
for information the ebuild is working perfectly on my intel servers, but not working on a ATOM CPU : +++ killed by SIGSEGV +++ Segmentation fault
Logs : Oct 22 15:41:46 mx kernel: bitcoind[32466]: segfault at 3042924 ip 161ab4c0 sp 452fed50 error 4 in bitcoind[1614b000+13b000] Oct 22 15:42:04 mx kernel: bitcoind[32648]: segfault at 1042924 ip 1272d4c0 sp 4f0fad50 error 4 in bitcoind[126cd000+13b000] Oct 22 15:43:03 mx kernel: bitcoind[32730]: segfault at 2042924 ip 16eea4c0 sp 4a9fad50 error 4 in bitcoind[16e8a000+13b000] Oct 22 15:46:26 mx kernel: bitcoind[753]: segfault at 1042924 ip 143244c0 sp 46ffed50 error 4 in bitcoind[142c4000+13b000]
CPU : mx bitcoin_gentoo_ebuild # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping : 2 cpu MHz : 1596.057 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm bogomips : 3192.11 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management:
processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping : 2 cpu MHz : 1596.057 cache size : 512 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm bogomips : 3192.29 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management:
processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping : 2 cpu MHz : 1596.057 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm bogomips : 3192.27 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management:
processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping : 2 cpu MHz : 1596.057 cache size : 512 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm bogomips : 3192.30 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management:
CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
end of the strace : stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 close(11) = 0 munmap(0x515e5000, 4096) = 0 gettimeofday({1287755265, 385568}, NULL) = 0 time(NULL) = 1287755265 time(NULL) = 1287755265 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x50de5000 mprotect(0x50de5000, 4096, PROT_NONE) = 0 clone(child_stack=0x515e5484, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x515e5bd8, {entry_number:6, base_addr:0x515e5b70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x515e5bd8) = 832 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x505e4000 mprotect(0x505e4000, 4096, PROT_NONE) = 0 clone(child_stack=0x50de4484, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x50de4bd8, {entry_number:6, base_addr:0x50de4b70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x50de4bd8) = 833 gettimeofday({1287755265, 386429}, NULL) = 0 gettimeofday({1287755265, 386521}, NULL) = 0 nanosleep({999, 999908000}, <unfinished ...>
( I can provide the complete strace if needed ) this is true with the 2 last ebuilds, 0.3.13 and 0.3.14 NOTE : the BINARY 32/bitcoind is running well on the same ATOM CPU server
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
October 22, 2010, 08:16:13 PM |
|
( I can provide the complete strace if needed )
this is true with the 2 last ebuilds, 0.3.13 and 0.3.14
NOTE : the BINARY 32/bitcoind is running well on the same ATOM CPU server
Yes, a complete strace would be more useful. I don't see anything strange in this part. Did you also try ebuilds before 0.3.13, did they give issues? Also give a bit more information about your system (is is x86 or ~x86 for example).
|
|
|
|
neofutur
|
|
October 22, 2010, 10:39:18 PM Last edit: October 23, 2010, 07:12:06 AM by neofutur |
|
EDIT : for now forget about this bugreport, theres something weird on this server and the problem could be unrelated with the ebuild, I m investigating and will update this within 24-48 hours. Yes, a complete strace would be more useful. I don't see anything strange in this part. Did you also try ebuilds before 0.3.13, did they give issues?
Also give a bit more information about your system (is is x86 or ~x86 for example).
nop tried only 0.3.13 and 0.3.14 until now, dont know how to get older ebuilds with git ;( the system is x86 but I added =net-p2p/bitcoin-0.3.14 ~x86
in /etc/portage/package.keywords also all my servers are gentoo hardened / grsec, but i m 99% its not related ( no grsec log message concerning bitcoind, its just a segfault, nothing more, and bitcoind is running on other dedicate servers ) since the strace can contain sensitive information I d prefer not to put it publicly here, could you send me a PM with you email or come on the #bitcoin-dev IRC channel ?
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
October 23, 2010, 11:04:41 AM |
|
Just see if your system is sane, if it is I'll contact you for the whole strace.
|
|
|
|
neofutur
|
|
November 15, 2010, 06:45:47 AM |
|
ok after more investigation the problem is not related to ATOM CPU or to my system I can build and run any gentoo packages but still have a problem with bitcoin on all the servers using the gentoo hardened pie/ssp toolchain ( http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml ) bitcoin is running ok on the servers not using hardened toolchain bitcoin will SIGSEGV on all the server using hardened : here is the full strace of the segfault : [pid 8467] write(19, "BitcoinMiner started\n", 21) = 21 [pid 8467] close(19) = 0 [pid 8467] munmap(0xb7ef7000, 4096) = 0 [pid 8467] setpriority(PRIO_PROCESS, 0, 20) = 0 [pid 8467] open("/var/lib/bitcoin/.bitcoin/debug.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 19 [pid 8467] fstat64(19, {st_mode=S_IFREG|0600, st_size=8581205, ...}) = 0 [pid 8467] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef7000 [pid 8467] fstat64(19, {st_mode=S_IFREG|0600, st_size=8581205, ...}) = 0 [pid 8467] _llseek(19, 8581205, [8581205], SEEK_SET) = 0 [pid 8467] write(19, "CPUID 6c65746e family 6, model 2"..., 59) = 59 [pid 8467] close(19) = 0 [pid 8467] munmap(0xb7ef7000, 4096) = 0 [pid 8467] --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 8467 detached
its always reproducible. I also tried disabling the sse2 use flag, nothing changes, same sigsegv problem with or without sse2 flag there is no crash if I disable the miner ( -gen=0 option ) so its clear the problem is in the miner code I also tried updating myself the ebuild to 0.3.15 , same crash but th strace is different : [pid 12260] open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 17 [pid 12260] fstat64(17, {st_mode=S_IFREG|0644, st_size=744, ...}) = 0 [pid 12260] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7db7000 [pid 12260] read(17, "# /etc/hosts: This file describ"..., 4096) = 744 [pid 12260] read(17, "", 4096) = 0 [pid 12260] close(17) = 0 [pid 12260] munmap(0xb7db7000, 4096) = 0 [pid 12260] time(NULL) = 1289803862 [pid 12260] socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 17 [pid 12260] connect(17, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.186.33.99")}, 28) = 0 [pid 12260] gettimeofday({1289803862, 19994}, NULL) = 0 [pid 12260] poll([{fd=17, events=POLLOUT}], 1, 0) = 1 ([{fd=17, revents=POLLOUT}]) [pid 12260] send(17, "\334\16\1\0\0\1\0\0\0\0\0\0\3irc\5lfnet\3org\0\0\1\0\1", 31, MSG_NOSIGNAL) = 31 [pid 12260] poll([{fd=17, events=POLLIN}], 1, 5000 <unfinished ...> [pid 12263] write(19, "ThreadMessageHandler started\n", 29) = 29 [pid 12263] close(19) = 0 [pid 12263] munmap(0xb7db5000, 4096) = 0 [pid 12263] setpriority(PRIO_PROCESS, 0, 2) = 0 [pid 12263] gettimeofday({1289803862, 20156}, NULL) = 0 [pid 12263] gettimeofday({1289803862, 20177}, NULL) = 0 [pid 12263] nanosleep({0, 99979000}, <unfinished ...> [pid 12261] set_robust_list(0xb4afebe0, 0xc) = 0 [pid 12261] open("/var/lib/bitcoin/.bitcoin/debug.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 18 [pid 12261] fstat64(18, {st_mode=S_IFREG|0600, st_size=8587255, ...}) = 0 [pid 12261] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7db7000 [pid 12261] fstat64(18, {st_mode=S_IFREG|0600, st_size=8587255, ...}) = 0 [pid 12261] _llseek(18, 8587255, [8587255], SEEK_SET) = 0 [pid 12261] write(18, "ThreadSocketHandler started\n", 28) = 28 [pid 12261] close(18) = 0 [pid 12261] munmap(0xb7db7000, 4096) = 0 [pid 12261] select(6, [5], [], [], {0, 50000} <unfinished ...> [pid 12235] +++ killed by SIGSEGV +++ [pid 12260] +++ killed by SIGSEGV +++ [pid 12233] +++ killed by SIGSEGV +++ [pid 12262] +++ killed by SIGSEGV +++ [pid 12263] +++ killed by SIGSEGV +++ [pid 12261] +++ killed by SIGSEGV +++ [pid 12234] +++ killed by SIGSEGV +++ +++ killed by SIGSEGV +++
with 0.3.15 the crash happens later, after : CPUID 6c65746e family 6, model 23, stepping 10, fUseSSE2=0 ThreadIRCSeed started ThreadMessageHandler started ThreadSocketHandler started
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
November 15, 2010, 06:53:22 AM |
|
Ok, I'll see if I can find out what is going wrong (please note that I'm not a C++ coder myself).
The distributed binary works, right?
|
|
|
|
neofutur
|
|
November 15, 2010, 07:03:29 AM |
|
Ok, I'll see if I can find out what is going wrong (please note that I'm not a C++ coder myself).
I was a C coder 10 years ago and had a quick look at the source code but couldnt find anything until now, i m thinking on adding debug to see more precisely where the segv happen The distributed binary works, right?
I never run binaries on my servers ;( so i havent tried the binary yet , I ll see if I can give it a try on a testing server.
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
November 15, 2010, 07:09:48 AM Last edit: November 15, 2010, 07:51:07 AM by BioMike |
|
Do you have SSP enabled? Issues arising from default SSP
The SSP implementation in gcc-3.x is not perfect, and can cause problems. In particular C++ code can be built incorrectly when SSP is enabled, although the exact details are not clear at the moment.
The SSP implementation in gcc-4.x is completely different, even so far as changing the semantics of the compiler switches. At the time of writing, we have little experience in the SSP implementation in gcc-4.x.
<edit> Try the binaries first, if they also give problems, hand the problem to the devs. They might be quicker in pinpointing the problem. If the problem is not present in the binaries, we might have to add a build flag somewhere (although there is not much difference, compared with the distributed build scripts). </edit>
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
November 15, 2010, 08:29:41 AM |
|
Pushed bitcoin-0.3.15 ebuild to github.
|
|
|
|
neofutur
|
|
November 15, 2010, 11:25:12 AM |
|
yes I m using PIE / SSP I tried the official binaries , they are working, no segfault
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
November 15, 2010, 12:23:04 PM |
|
yes I m using PIE / SSP I tried the official binaries , they are working, no segfault
Ok, could you give me some info on the system and your C++/LD-flags?
|
|
|
|
neofutur
|
|
November 16, 2010, 02:31:29 AM |
|
profile : [7] hardened/linux/x86/10.0 * make.profile -> ../usr/portage/profiles/hardened/linux/x86/10.0
gcc-config : [10] i686-pc-linux-gnu-4.4.4 *
in make.conf :
CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j3"
CPU :
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz stepping : 10 cpu MHz : 2997.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips : 5999.86 clflush size : 64 power management:
any command line you recommend to get more specific details about g++/ld flags ?
|
|
|
|
neofutur
|
|
November 16, 2010, 06:01:52 AM |
|
another thing, I now have a running bitcoind with mining enabled ( -gen ) but with no genproclimit
no crash until I set the genproclimit
wether I have the genproclimit in the config file ( -genproclimit=1 in /etc/conf.d/bitcoin ) or when I set it via bitcoind command line the server crashes
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
November 16, 2010, 03:49:18 PM |
|
Thank you for the information.
I've been searching through the code, but haven't able to find anything yet that might cause the problem. The part where genproclimit comes into play (until where it is the same as not setting it) is relatively small and doesn't seem to do strange things. Also, as this code is also the same as the prebuild binaries it seems that the problem is somewhere else.
Did you already try to get a gdb trace? (there seems also to be a -debug option, might be useful)
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
December 03, 2010, 08:53:36 PM |
|
Ok, I've changed one of my systems to a hardened system and was able to reproduce the bug on version 0.3.17. Here is the backtrace. No idea what is going wrong. gdb bitcoind GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) run Starting program: /usr/bin/bitcoind [Thread debugging using libthread_db enabled] bitcoin server starting [New Thread 0xb6aa46d0 (LWP 6475)] [New Thread 0xb6477b70 (LWP 6478)] [New Thread 0xb5c76b70 (LWP 6479)] [New Thread 0xb5475b70 (LWP 6480)] [New Thread 0xb4c74b70 (LWP 6481)] [New Thread 0xb4473b70 (LWP 6482)] [New Thread 0xb3c57b70 (LWP 6483)] [New Thread 0xb3456b70 (LWP 6484)] [New Thread 0xb2c39b70 (LWP 6485)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb2c39b70 (LWP 6485)] Detect128BitSSE2 () at main.cpp:2956 2956 main.cpp: No such file or directory. in main.cpp (gdb) bt full #0 Detect128BitSSE2 () at main.cpp:2956 fUseSSE2 = <value optimized out> fPrinted = false nFamily = 15 nModel = 2 #1 0xb768fdfc in BitcoinMiner () at main.cpp:3313 reservekey = {nIndex = 0, vchPubKey = {<std::_Vector_base<unsigned char, std::allocator<unsigned char> >> = { _M_impl = {<std::allocator<unsigned char>> = {<__gnu_cxx::new_allocator<unsigned char>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>}} nExtraNonce = <value optimized out> nPrevTime = <value optimized out> __PRETTY_FUNCTION__ = "void BitcoinMiner()" #2 0xb7690e32 in ThreadBitcoinMiner (parg=0x0) at main.cpp:2884 No locals. #3 0xb6acd96e in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0xb6baeb5e in clone () from /lib/libc.so.6 No symbol table info available.
The misbehaving line is: in the following code: // AMD reports a lower model number in 64-bit mode if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160000) fUseSSE2 = true;
static bool fPrinted; if (!fPrinted) { fPrinted = true; printf("CPUID %08x family %d, model %d, stepping %d, fUseSSE2=%d\n", nBrand, nFamily, nModel, cpu.nStepping, fUseSSE2); } return fUseSSE2;
fPrinted is false according to the backtrace, I don't know why this is causing the segfault?
|
|
|
|
Elanthius
Newbie
Offline
Activity: 45
Merit: 0
|
|
December 16, 2010, 11:08:45 AM |
|
I would love to be able to get this running on my headless gentoo box. Any suggestions on this error:
* Applying bitcoin-monitor.patch ...
* Failed Patch: bitcoin-monitor.patch ! * ( /usr/local/portage/net-p2p/bitcoin/files/bitcoin-monitor.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/net-p2p/bitcoin-9999/temp/bitcoin-monitor.patch.out
* ERROR: net-p2p/bitcoin-9999 failed: * Failed Patch: bitcoin-monitor.patch! * * Call stack: * ebuild.sh, line 56: Called src_prepare * environment, line 5246: Called epatch '/usr/local/portage/net-p2p/bitcoin/files/bitcoin-monitor.patch' * environment, line 2216: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * * If you need support, post the output of 'emerge --info =net-p2p/bitcoin-9999', * the complete build log and the output of 'emerge -pqv =net-p2p/bitcoin-9999'. * This ebuild is from an overlay: '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/environment'. * S: '/var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999/trunk'
>>> Failed to emerge net-p2p/bitcoin-9999, Log file:
|
|
|
|
BioMike
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
December 16, 2010, 11:48:03 AM |
|
bitcoin-9999 is a live ebuild (against cvs/git?). They can break. Make sure your patch is ok.
|
|
|
|
checker
|
|
December 17, 2010, 01:45:48 AM |
|
shall we post bugs of it here? if not - it would be the last (from me)
emake failed * ERROR: net-p2p/bitcoin-9999 failed: * died running emake, base_src_make * * Call stack: * ebuild.sh, line 56: Called src_compile * environment, line 3226: Called bitcoin_src_compile * environment, line 596: Called base_src_compile * environment, line 506: Called base_src_make * environment, line 544: Called die * The specific snippet of code: * emake "$@" || die "died running emake, $FUNCNAME"; * * If you need support, post the output of 'emerge --info =net-p2p/bitcoin-9999', * the complete build log and the output of 'emerge -pqv =net-p2p/bitcoin-9999'. * This ebuild used the following eclasses from overlays: * /usr/local/portage/layman/booboo/eclass/bitcoin.eclass * This ebuild is from an overlay named 'booboo': '/usr/local/portage/layman/booboo/' * The complete build log is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/environment'. * S: '/var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999'
what shall I do?
|
Xoчeшь oтблaгoдapить - кинь биткoинoв, cкoлькo нe жaлкo- бyдy paд! (If u want to say me thanx - give me some bitcoins ) 1NXsbppu1B2exLUY8i5cYbQxbc2zWtiTAY
|
|
|
|