What does @executable_path mean?

Any fix for this will have to be very careful. For the GNU tools, among others, starting a parameter with @ causes it to be replaced with the contents of a file with the string following the @. So if we do need to handle @executable_path, we need to be careful to only do it in a context in which we know for sure that it won't be replaced by a file. Otherwise all of this flag vetting no longer works.

@exexutable_path is like the MacOS version of $ORIGIN on Linux i.e. it is the path that the binary is in at runtime to be able to dynamically link to a library using a relative path.

Here's some more info: https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath
While we're at it we should probably add @loader_path as well as @executable_path.

It looks like @ is specifically forbidden as a leading character since we started validating cgo flags in 1dcb5836.

A wrinkle in all this is that GNU binutils uniformly accept
@foo on the command line to mean "if the file foo exists,
then substitute its contents for @foo in the command line".
So we must also reject @x.go, flags and flag arguments
beginning with @, and so on.

That would still be an issue here. Perhaps we could support specifically @loader_path and @executable_path (nothing else that starts with @), and only allow those when GOOS=darwin?

Yes, that sounds like the ideal solution!

If someone can point me to where I need to look I'm happy to have a bash at a PR.

security.go contains regular expressions for allowed flags.

cfg.GOOS may be used to check the target operating system. I don't think we have any regular expressions that are allowed on one platform but not others, but that would be necessary here.

cgo_bad_directives.txt tests this filtering, so that would need to be expanded. See README.txt in that directory for information on the test format.

Actually I'm evaluating go for a project on mac and i've a poc that needs to load an external *.dylib from a directory relative to the binary. So I stumbled over @executable_path and this issue with go, so is there any known workaround to get a go binary working that can load a *.dylib from a directory relative to the binary?

Any suggestions would be great, I really would like to use go for the project, but we need to load external C libraries that are not installed in any of the OS search paths.

Update:
Sorry for the post but I've found at least a workaround for that:

1. Compile my go file with cgo flags

package native

/*
#cgo LDFLAGS: -L../path/to/libs -Wl,-rpath,./libs -lgreeter
#include "path/to/libs/include/greeter.h"
#include <stdlib.h>
*/
import "C"

// Rest of code omitted for brevity

2. Run go build -o mybinary
3. Run the install_name_tool

# You can check the correct name for change with otool -L mybinary
install_name_tool -change @rpath/libgreeter.dylib @executable_path/libs/x64/libgreeter.dylib mybinary

I'm not sure if this would break anything else, but so far everything is working as expected. I still hope that the go tooling will allow the @executable_path and @loader_path flags in the future.

@snmed I'm glad you found a way. You can also set set the CGO_LDFLAGS_ALLOW environment variable. https://golang.org/cmd/go/#hdr-Environment_variables

@ianlancetaylor Thanks for your advice, that worked very well with CGO_LDFLAGS_ALLOW="-Wl,-rpath,@executable_path/.*" go build, now only the vscode extensions still shows the invalid flag in #cgo LDFLAGS:-Wl,-rpath,@executable_path/libs maybe there is some setting for that. A workaround for that is to set the variable for the whole development environment.

I've just hit this issue and the CGO_LDFLAGS_ALLOW workaround doesn't work for me. I want to be able to go install my project without having to instruct people to set that variable.

Since @ doesn't actually read files on macOS, would it be acceptable to patch the code to allow it on Darwin? If yes, I can submit a PR implementing that.

Some people do use the GNU tools on Darwin, and those tools do read files when they see an @ at the start of an option. So we must not in general ignore @ on Darwin.

If the specific string @executable_path is magic, then perhaps we can recognize that string on Darwin. Are there other magic strings like that one?

For -rpath, @executable_path and @loader_path are the only special values that you can provide. See https://forums.developer.apple.com/forums/thread/736728.

The only other argument that I’m aware of that can receive a value starting with @ is -install_name. It accepts @rpath to indicate the library may be installed at any of the paths defined by -rpath. I can open a new issue for that one if you prefer.

More info about these 3 special values at the very bottom of this man page: https://www.unix.com/man-page/osx/1/dyld/.

I did some extra research and it looks like the GNU ld doesn't support Darwin as a target. The only way to use it on macOS is by targeting another platform to produce an ELF file. You cannot use it to produce a Mach-O file. See Homebrew/homebrew-core#17794.

Since @executable_path, @loader_path, and @rpath are only meaningful in Mach-O, can we check the target platform and allow or disallow these flags based on that?

Change https://go.dev/cl/638075 mentions this issue: cmd/go/internal/work: allow @ character in some -Wl, linker flags on darwin