New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vendoring fails on projects using the native Golang bindings #2738

Closed
awishformore opened this Issue Jun 26, 2016 · 14 comments

Comments

Projects
None yet
@awishformore
Copy link

awishformore commented Jun 26, 2016

System information

Geth
Version: 1.4.7-stable-667a386d
Protocol Versions: [63 62 61]
Network Id: 1
Go Version: go1.6.2
OS: linux
GOPATH=/home/awishformore/Code/go
GOROOT=/opt/google/go

Expected behaviour

I am using the Golang native contract bindings in a project. The project builds fine. I want to use vendoring to add all dependencies into the repository and have it build in an isolated fashion. Using godep save should add all required dependencies to the vendor folder.

Actual behaviour

godep save misses some cgo dependencies that are located in their own folder. This causes the build to fail with:

vendor/github.com/ethereum/go-ethereum/crypto/secp256k1/curve.go:43:44: fatal error: libsecp256k1/include/secp256k1.h: No such file or directory
 #include "libsecp256k1/include/secp256k1.h"
                                            ^
compilation terminated.

The problem is described in the following issue on the Godep repository: tools/godep#422

The sqlite library in Go solved the issue by putting the cgo dependencies into the same package as the files that depend on it.

Steps to reproduce the behaviour

  • use automatically generated Golang bindings in a project
  • bind a contract using the native binding, an address and a backend
  • use godep save to save the dependencies in the vendor folder
  • attempt a build with go build on Golang version 1.6 or later
@awishformore

This comment has been minimized.

Copy link

awishformore commented May 8, 2017

Still an issue.

@LYY

This comment has been minimized.

Copy link

LYY commented Oct 19, 2017

Still have same issue.

@kjda

This comment has been minimized.

Copy link

kjda commented Nov 9, 2017

me too! any solutions??

@kc1116

This comment has been minimized.

Copy link

kc1116 commented Feb 12, 2018

anyone find a solution to this ?

@lmars

This comment has been minimized.

Copy link
Contributor

lmars commented Feb 13, 2018

A temporary solution is to just manually copy the files into vendor:

cp -r \
  "${GOPATH}/src/github.com/ethereum/go-ethereum/crypto/secp256k1/libsecp256k1" \
  "vendor/github.com/ethereum/go-ethereum/crypto/secp256k1/"
@Freyert

This comment has been minimized.

Copy link

Freyert commented Apr 23, 2018

@lmars you ... I can't even... wow... thanks! For any newbz out there like myself who have been privileged enough to grow up on dep ensure you should do a:

go get github.com/ethereum/go-ethereum

before running the above.

@overtfuture

This comment has been minimized.

Copy link

overtfuture commented May 10, 2018

I think the issue is more along the lines of dep, see this issue: golang/dep#1847

@saan099

This comment has been minimized.

Copy link

saan099 commented Jun 14, 2018

Same thing with govendor.

@nkashy1

This comment has been minimized.

Copy link

nkashy1 commented Jul 8, 2018

Had this error using dep. Thanks @lmars

nkashy1 added a commit to nkashy1/microcosm that referenced this issue Jul 8, 2018

Docker build now includes microcosm binary
This brought about many changes:

1. Switched from glide to dep for managing dependencies
(https://golang.github.io/dep/). I was having issues with glide in that
it wouldn't resolve the subpackages of go-ethereum (accounts, common).

2. Added .dockerignore file

3. Modified docker/Dockerfile to also build microcosm binary and put it
into /usr/local/bin of final image.

4. Updated vendor/ subdirectory after `dep` did its magic.

5. Had to manually add libsecp256k1 into vendored go-ethereum as per
@lmars solution here:
ethereum/go-ethereum#2738
@ezynda3

This comment has been minimized.

Copy link

ezynda3 commented Aug 29, 2018

Is there a plan to fix this?

@engenegr

This comment has been minimized.

Copy link

engenegr commented Sep 6, 2018

@ezynda3 it is more likey golang bug. or dep. or whatever, i encountered the same problems with ledger-related golang code.

@s1na

This comment has been minimized.

Copy link

s1na commented Sep 11, 2018

According to this comment a simple way of fixing this would be to add a dummy go file in crypto/secp256k1/libsecp256k1/, until the fix is implemented and merged into dep.

AaronVasquez added a commit to oysterprotocol/brokernode that referenced this issue Sep 27, 2018

AaronVasquez added a commit to oysterprotocol/brokernode that referenced this issue Sep 28, 2018

@zglzglak47

This comment has been minimized.

Copy link

zglzglak47 commented Oct 31, 2018

if you are using govendor , try "govendor fetch -tree github.com/ethereum/go-ethereum/crypto/secp256k1"

@karalabe

This comment has been minimized.

Copy link
Member

karalabe commented Jan 15, 2019

Hey, so this is a limitation of the Go vendoring ecosystem. The suggested workaround by @zglzglak47 is the correct solution unfortunately. Maybe go 1.11 modules could eventually help, but for now this is an unfortunate limit of Go.

@karalabe karalabe closed this Jan 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment