Skip to content
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

cmd/cgo: consider supporting simple variable substitution in #cgo lines #7891

Closed
ianlancetaylor opened this issue Apr 28, 2014 · 6 comments
Closed
Milestone

Comments

@ianlancetaylor
Copy link
Contributor

A common complaint about #cgo lines is that there is no way to refer to a C library
relative to the source directory.  A relative path is taken relative to the build
directory, typically in /tmp.

We should consider supporting constructs like $ORIGIN (name taken from the ELF dynamic
linker, could also be SRCDIR) which expands to the path name of the source directory.

#cgo LDFLAGS -l $ORIGIN/../lib

I don't think we should support environment variables in general.  Just a few specific
strings.  Other obvious strings would $GOARCH and $GOOS.
@gopherbot
Copy link

Comment 1 by manoj.dayaram@moovweb.com:

That would certainly help with this issue!
https://golang.org/issue/5428

@cookieo9
Copy link
Contributor

cookieo9 commented Jul 2, 2014

Comment 3:

I don't see the problem happening at tip.
On OSX 10.9 I have successfully linked a program with local libraries in a lib directory
and the cgo directive:
// #cgo LDFLAGS: -Llib -lsomelibrary
The output of go build -x --ldflags -v shows that the files in the build directory are
referenced by absolute path, and the source directory appears to be the working
directory, so relative paths seem to work.

@gopherbot
Copy link

Comment 4 by manoj.dayaram@moovweb.com:

The issue only arises if you're running the build command outside of the directory using
the library and if the path in the #cgo line is a relative path but *not* the same
directory as the code using it.
I made fairly detailed instructions on replicating this process on this issue:
https://golang.org/issue/5428

@gopherbot
Copy link

Comment 5:

CL https://golang.org/cl/114640044 mentions this issue.

@rsc
Copy link
Contributor

rsc commented Sep 15, 2014

Comment 6:

It's too late for 1.4.

Labels changed: added release-go1.5, removed release-go1.4.

Status changed to Accepted.

@cookieo9
Copy link
Contributor

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants