Issue: build from source

my machine is on windows 10, and I followed the instructions
this is the result when I finish get the source code.




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 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 If you already have ipfs installed, you can configure gx to use your instance by setting the environment variable IPFS_API= Alternatively, you can configure IPFS to use an alternative gateway by setting IPFS_API=https://some-gateway. You can find a list here:

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.


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=

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

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:
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…