I’ve had this particular issue as well as another involving adding a vault which gives similar results, or produces an IO error, depending on when you add/remove the vault. The response I got was that they are actively working on churn handling and it should be fixed shortly. I’ll be watching the repo.
Yes I’ve seen that I/O error on adding another vault. Wasn’t sure about it as it was on the laptop with wifi and the kids were hammering the wifi with games and vids at the time.
I played a bit with vaults/clients on virtual machines today and at some point the client didn’t log in, it was waiting for a put response if I remember correctly which was not coming in
I’ll try to replicate it some time next week and post a log here.
Look what happens when you give us something to play with @dirvine, 64 posts in 3 days!
Yip, brilliant I like the fast and furious testing and the warts and all release before we package it for everyone. Really cool
I have installed Rust 1.3 Nightly Builds on my Win7/64. I also set a path to the rust dir for the cmd. Is there a tutorial somewhere how I can actually build stuff? In this topic it’s stated that I need to “grab” the latest master of the client and vault. But I actually don’t have a clue on how to do that. Does anyone know a nice tutorial somewhere?
Should just mean
git clone https://github.com/maidsafe/maidsafe_vault
and cd into that dir and type cargo build/run etc. Similar for client git clone https://github.com/maidsafe/maidsafe_client
and your set to follow all the instructions on each news update I think.
Anyone else get a failure with the latest git update of vault?
Last night’s rust, everything else is latest git
Ubuntu 15.04 64-bit
cargo test --verbose bails out with …
maidsafe_vault 0 has 0 connected connections.
thread 'executable_test' panicked at 'assertion failed: `(left == right)` (left: `true`, right: `false`)', tests/lib.rs:71
I’ll raise an issue in github, meanwhile if anyone can confirm - or better yet, tell me I’m wrong - please say so
failures:
executable_test
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured
thread '<main>' panicked at 'Some tests failed', ../src/libtest/lib.rs:255
Yes!
Confirmed operational on Fedora 22 workstation
Same here w10/64
Given my very basic coding proficiency, it shows that maidsafe team has done a great job keeping things clear and simple ! Thanks also to the contributors of these threads for the help !
I’m quite new to the whole compiling etc. So may be a simple thing which I don’t get at this moment. I installed RUST NB 1.3, I installed MinGW, Git and put a pre-build binarie of LibSodium in the MinGW-BIN folder. Now the MinGW-BIN-folder has a sub-folder containing “libsodium-win32” and “libsodium-win64”. Both these folders have their own sub-folder called BIN with a .dll in it. Now when I try to build the Vault I keep getting this error:
C:\maidsafe\maidsafe_vault>cargo build
Updating registry https://github.com/rust-lang/crates.io-index
Compiling libsodium-sys v0.0.5
Compiling winapi-build v0.1.0
Compiling libc v0.1.8
Compiling strsim v0.3.0
Compiling itertools v0.3.21
Compiling rustc-serialize v0.3.15
Compiling byteorder v0.3.10
Compiling regex-syntax v0.1.2
Compiling log v0.3.1
Compiling rand v0.3.8
Compiling memchr v0.1.3
Compiling winapi v0.1.23
Compiling num_cpus v0.2.6
Compiling kernel32-sys v0.1.2
Compiling aho-corasick v0.2.1
Compiling asynchronous v0.4.5
Compiling sodiumoxide v0.0.5
Compiling regex v0.1.38
Compiling env_logger v0.3.1
Compiling docopt v0.6.67
Compiling cbor v0.3.7
Compiling num v0.1.25
Compiling time v0.1.30
Compiling term v0.2.9
Compiling lru_time_cache v0.1.8
Compiling message_filter v0.1.1
Compiling accumulator v0.0.1
Compiling utp v0.6.0
Compiling crust v0.1.4
Compiling routing v0.2.7
Compiling maidsafe_types v0.2.2
Compiling maidsafe_vault v0.1.0 (file:///C:/maidsafe/maidsafe_vault)
error: linking with gcc
failed: exit code: 1
note: “gcc” “-Wl,–enable-long-section-names” “-fno-use-linker-plugin” “-Wl,–nx
compat” “-static-libgcc” “-m64” “-L” “C:\Program Files\Rust nightly 1.3\bin\rust
lib\x86_64-pc-windows-gnu\lib” “C:\maidsafe\maidsafe_vault\target\debug\maidsafe
vault.o" “-o” “C:\maidsafe\maidsafe_vault\target\debug\maidsafe_vault.exe” “-Wl
,–gc-sections” “C:\maidsafe\maidsafe_vault\target\debug\deps\libmaidsafe_types-
e022f498f2e0be44.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\librouting-
c637995867c141d6.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\libcrust-c5
9c517caf52ab64.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\libcbor-0bd94
1ffbb5daf77.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\libmessage_filte
r-c4297ec9773f359a.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\libasynch
ronous-5f0cce4e19357a9a.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\libn
um_cpus-16707c6acca9fe91.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\lib
itertools-4233a7da5928e157.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\l
ibbyteorder-399c175f6a7726ac.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps
\libsodiumoxide-75eb99c13a8dec07.rlib” “C:\maidsafe\maidsafe_vault\target\debug
deps\libutp-d5f3579e915156bb.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps
\libnum-7ad397ad0b46ae38.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\lib
rand-de6cdb9e4fd93d55.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\liblib
sodium_sys-230d4350cd007c4b.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps
libdocopt-141ed6b1383f3228.rlib” “C:\maidsafe\maidsafe_vault\target\debug\deps\l
ibrustc_serialize-c1e8163a38ed3d54.rlib” “C:\maidsafe\maidsafe_vault\target\debu
g\deps\libregex-32ebc1f1da8b6841.rlib” “C:\maidsafe\maidsafe_vault\target\debug
deps\libaho_corasick-068913d97bcdea39.rlib” “C:\maidsafe\maidsafe_vault\target\d
ebug\deps\libregex_syntax-74cdf8e4e9018a0c.rlib” “C:\maidsafe\maidsafe_vault\tar
get\debug\deps\libmemchr-38e2ee286f7e4bdb.rlib” “C:\maidsafe\maidsafe_vault\targ
et\debug\deps\libstrsim-f37b8d6da2e1c859.rlib” “C:\maidsafe\maidsafe_vault\targe
t\debug\deps\libaccumulator-4ea207c6b4eb723c.rlib” “C:\maidsafe\maidsafe_vault\t
arget\debug\deps\liblru_time_cache-7fa82329a30ad63b.rlib” "C:\maidsafe\maidsafe
vault\target\debug\deps\libtime-d3937aca0d3022b9.rlib” “C:\maidsafe\maidsafe_vau
lt\target\debug\deps\libkernel32-7ae262b5d3e8acdb.rlib” “C:\maidsafe\maidsafe_va
ult\target\debug\deps\libwinapi-fbb144edd0d77a8f.rlib” “C:\maidsafe\maidsafe_vau
lt\target\debug\deps\liblog-8a6aba167994951e.rlib” “C:\maidsafe\maidsafe_vault\t
arget\debug\deps\liblibc-ef5cbad4ef5c7a1e.rlib” “C:\Program Files\Rust nightly 1
.3\bin\rustlib\x86_64-pc-windows-gnu\lib\libstd-74fa456f.rlib” “C:\Program Files
\Rust nightly 1.3\bin\rustlib\x86_64-pc-windows-gnu\lib\libcollections-74fa456f.
rlib” “C:\Program Files\Rust nightly 1.3\bin\rustlib\x86_64-pc-windows-gnu\lib\l
ibrustc_unicode-74fa456f.rlib” “C:\Program Files\Rust nightly 1.3\bin\rustlib\x8
6_64-pc-windows-gnu\lib\librand-74fa456f.rlib” “C:\Program Files\Rust nightly 1.
3\bin\rustlib\x86_64-pc-windows-gnu\lib\liballoc-74fa456f.rlib” “C:\Program File
s\Rust nightly 1.3\bin\rustlib\x86_64-pc-windows-gnu\lib\liblibc-74fa456f.rlib”
“C:\Program Files\Rust nightly 1.3\bin\rustlib\x86_64-pc-windows-gnu\lib\libcore
-74fa456f.rlib” “-L” “C:\maidsafe\maidsafe_vault\target\debug” “-L” “C:\maidsafe
\maidsafe_vault\target\debug\deps” “-L” “C:\Program Files\Rust nightly 1.3\bin\r
ustlib\x86_64-pc-windows-gnu\lib” “-L” “C:\maidsafe\maidsafe_vault.rust\bin\x86
_64-pc-windows-gnu” “-L” “C:\maidsafe\maidsafe_vault\bin\x86_64-pc-windows-gnu”
“-Wl,-Bstatic” “-Wl,-Bdynamic” “-l” “Iphlpapi” “-l” “sodium” “-l” “kernel32” "-l
" “ws2_32” “-l” “userenv” “-l” “advapi32” “-l” “compiler-rt”
note: ld: cannot find -lsodium
error: aborting due to previous error
Could not compile maidsafe_vault
.
How do I fix this “linking with gcc
failed: exit code: 1” and why does it say “note: ld: cannot find -lsodium”
Is there a path I need to set somewhere? Again, I’m quite new to this
You appear to be in Windows.
The right place, should be exactly where you put it, in my opinion. Probably there is a variable somewhere that would allow that… However, to get up and running, do this instead.
Instead, I create a bin directory directly in the rust program folder.
cd maidsafe_vault
mkdir bin
cd bin
mkdir x86_64-pc-windows-gnu
Now, instead of putting in a .dll file, you’re looking for libsodium.a
Put libsodium.a into maidsafe_vault/bin/x86_64-pc-windows-gnu
Should work now.
Thanx, works well for the Vault. I can actually run it now, using cargo run. I can also find the process for the vault in the taskmanager (maidsafe_vault.exe). I tried to build the Client as well. As stated above, I also created a subfolder called “bin” with another subfolder called “x86_64-pc-windows-gnu”. The libsodium.a is in there as well. But here’s what I get when I try to build the client:
C:\maidsafe\maidsafe_client>cargo build
Updating registry `https://github.com/rust-lang/crates.io-index`
Compiling libsodium-sys v0.0.5
Compiling byteorder v0.3.10
Compiling libc v0.1.8
Compiling regex-syntax v0.1.2
Compiling rustc-serialize v0.3.15
Compiling gcc v0.3.8
Compiling strsim v0.3.0
Compiling winapi-build v0.1.0
Compiling itertools v0.3.21
Compiling log v0.3.1
Compiling memchr v0.1.3
Compiling winapi v0.1.23
Compiling rand v0.3.8
Compiling num_cpus v0.2.6
Compiling rust-crypto v0.2.31
Compiling kernel32-sys v0.1.2
Compiling aho-corasick v0.2.1
Compiling asynchronous v0.4.5
Compiling tempdir v0.3.4
Compiling sodiumoxide v0.0.5
Compiling regex v0.1.38
Build failed, waiting for other jobs to finish...
failed to run custom build command for `rust-crypto v0.2.31`
Process didn't exit successfully: `C:\maidsafe\maidsafe_client\target\debug\buil
d\rust-crypto-093a8ad0ae39b61a\build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-pc-windows-gnu")
TARGET = Some("x86_64-pc-windows-gnu")
CARGO_MANIFEST_DIR = Some("C:\\Users\\Hansolo\\.cargo\\registry\\src\\github.com
-0a35038f75765ae4\\rust-crypto-0.2.31")
OUT_DIR = Some("C:\\maidsafe\\maidsafe_client\\target\\debug\\build\\rust-crypto
-093a8ad0ae39b61a\\out")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
debug 0
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CFLAGS_x86_64-pc-windows-gnu = None
CFLAGS_x86_64_pc_windows_gnu = None
HOST_CFLAGS = None
CFLAGS = None
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
running: "gcc" "-O0" "-c" "-ffunction-sections" "-fdata-sections" "-mwin32" "-m6
4" "-fPIC" "C:\Users\Hansolo\.cargo\registry\src\github.com-0a35038f75765ae4\rus
t-crypto-0.2.31\src/util_helpers.c" "-o" "C:\maidsafe\maidsafe_client\target\deb
ug\build\rust-crypto-093a8ad0ae39b61a\out\src\util_helpers.o"
failed to execute command: Het systeem kan het opgegeven bestand niet vinden.
(os error 2)
Is `gcc` not installed? (see https://github.com/alexcrichton/gcc-rs#windows-note
s for help)
When I try cargo run, it says: "A bin target must be available for “Cargo Run”. Both Maidsafe_vault and Maidsafe_client actually have the same bin-folder with the same sub-dirs and libsodium.a
It’s encouraging to see it working… can’t wait to see more.
I was just wondering later that there will be an option to allocate space and other resources, rather than SAFE being greedy and making full use of what is available. Then I wondered that if that was the case, a user could fraction their disk and run multiple instances, which would rather goes against the idea of wanting resource to be distributed; so, perhaps a dilemma there or is that resolved by identifying resources uniquely?
Yes
It’s unlikely a computer split up would be much of an issue really. IF the network takes off it will be insignificant really.
hello, if i translated this message right, i believe you just have not got gcc compiler installed or path to it is not in the PATH variable
this is direct link to download
http://sourceforge.net/projects/mingw-w64/files/latest/download
choose Archictecture “x86_64” during installation (not i686) and then put folder of installed product containing “gcc.exe” into the path enviromental variable
(this is all assuming you have windows x64)
Hi guys this is some great news
My vaults running successfully, i can see that they get their port open. Started 4 of them.
But client is idle with this output:
>cargo run --example rest_api --features “USE_ACTUAL_ROUTING”
Running target\debug\examples\rest_api.exe
Account Creation
================
------------ Enter Keyword ---------------
123
------------ Enter Password --------------
123
--------- Enter PIN (4 Digits) -----------
1234
Trying to create an account …
trying to bootstrapped client
Put sent out with message_id 3075015447
Where can be the problem?
Thanks in advance!
@NikVolf Thanx! Great help.
Got it up and running. created an account, logged in. Works very well. I see the Vault responding when I start to use the Client.
regarding the last screenshot, shouldn’t it say “trying to bootstrap client” instead of “trying to bootsrapped client”?
figured how to work around
it seems that running vault from “rust 1.3 shell” (shortcut provided with rust for windows installer) not only works incorrect itself, it destroys other nodes already running from regular command-line
if all nodes are run using regular command-line everything ok
i can’t even imagine how using rust shell (which is just a shortcut to the regular windows console) can lead to this error, but each time i run vault from rust console i get this error on all nodes:
CRUST::NewConnection on Tcp(V4(192.168.1.144:48617))
RT (size : 3) added connected node f6910f…c0663f on Tcp(V4(192.168.1.144:48617)
)
Handle CHURN new node f6910f…c0663f
thread ‘’ panicked at ‘called Result::unwrap()
on an Err
value: Dec
ode(TypeMismatch { expected: Array, got: UInt64 })’, …/src/libcore\result.rs:73
1
but until then, everything works
checked it several times
writing it just for people who can encounter very same behaviour, i believe it is no concern for developers or whoever else