my machine is on windows 10, and I followed the instructions https://github.com/ipfs/go-ipfs/blob/v0.4.14/docs/windows.md
this is the result when I finish get the source code.
src:
pkg:
bin:
but when I ran gx --verbose install --global, the problem occurs,
what I confused is the soruce code in the folder src seems incomplete
So, it looks like you’re in China which has, unfortunately, blocked ipfs.io. While the source tarball contains the source for ipfs itself, it doesn’t contain the dependencies. Those are fetched as-needed over IPFS using a tool called gx. By default, gx is configured to use the IPFS daemon running at https://ipfs.io. If you already have ipfs installed, you can configure gx to use your instance by setting the environment variable IPFS_API=127.0.0.1:5001. Alternatively, you can configure IPFS to use an alternative gateway by setting IPFS_API=https://some-gateway. You can find a list here: https://ipfs.github.io/public-gateway-checker/
Note: We can’t endorse any of these gateways and gx will blindly trust any results they return. Your best bet would be to download a pre-built IPFS binary from a trusted source, run a local daemon, and use that to fetch the source.
2 Likes
Tnx for detailed answer. And exactly I am in China now.
I still met some problem to build ipfs from source.
this is the issue that I set IPFS_API=127.0.0.1:5001
and my ipfs config file is same as defult.
when I tried to use other IPFS_API address, it seems all addresses are blocked…
this is ipfs terminal
Ah… Windows. Unfortunately, that last one is a known bug that will be fixed in the next release.
For the first error (“A required privilege is not held by the client”), try removing C:\Users\wangzh20785\go\src\gx and starting over. I’m not sure what happened there but it looks like the prior failed downloads messed something up.
1 Like
tnx, I deleted the folder gx and started again…the same problem still occurred, I only can download part of dependency…
Hm. So, it looks like there’s a (broken) symlink in the go-multihash package and Windows requires users to have special permissions to make symlinks (for security reasons). The head-scratcher here is why nobody else has complained about this.
1 Like
Looking into this, I’m guessing it has to do with most people building with make, which pulls in a bundled prebuilt version of gx.exe. Using the prebuilt binary gives me 0-byte files where symlinks should be, but still builds successfully since the links are only in tests. Using my own build of gx from master results in these access errors.
The former is still incorrect behaviour so trying to revert back to that isn’t a proper fix to the current problem.
I’m going to look into fixing symlink creation on Windows in tar-utils which should resolve this. For now, the workaround would be to use the old gx binaries /ipns/dist.ipfs.io/gx/v0.12.1/
1 Like
um…the release version is better indeed
I had the same error (failed to fetch dependencies). Fixed it by running from Administrator Command Prompt. After that everything worked fine. Windows 10 (possibly 8 as well) needs admin-level access to create symlinks.
1 Like
There’s a patch in the works that handles symlinks a little better on Windows 10, but it’s going to have to wait until Go 1.11
In the meantime, I’m working on a solution to handle user symlink permissions for Windows Vista and later, This should enable users to create links without requiring full admin rights. For standard users, the current options are to skip the links and warn the user about it, or return an error with the same warning, telling users how to enable symlink creation privilege for their account.
Here is a relevant ipfs patch: https://github.com/ipfs/go-ipfs/pull/4956
Something similar will need to be done for gx/go-ipfs-api.
1 Like
thanks. I thought maybe it is because of the GFW in china…