You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest releases of all the above?
I am very confident because of the problem I point out at the end of this issue
What operating system and processor architecture are you using?
Linux/x86_64
What did you do?
I am compiling a go_library that contains source files that are both in-tree as normal and some that are genrule outputs. However, I am having trouble getting the paths trimmed in the resulting archive. I am using go tool nm to list the symbols and grepping for gofile. Normally, it trims the paths for the normal files and the paths for the genruled files contain the bindir, which is not desirable as it depends on transition state.
I tried passing something like gc_goopts = ["-trimpath=$(BINDIR)=>."].
What did you expect to see?
I expected to see that the genfiles had their paths trimmed. This was true.
What did you see instead?
However, the normal files did not have their paths trimmed anymore (meaning I fixed half of the files and broke the other half). In addition the bindir substitution was wrong, it replaced BINDIR with .:. instead of ..
The result is that this archive cannot be shared between plugins and a main binary because of a version mismatch.
In addition upon reviewing the output of actually trying to use $(BINDIR) as the trimpath I realized that although it removes the k8-fastbuild case it doesn't work when theres actually a transition because $(BINDIR) is not the correct transition directory for the input... and now I am even more lost as to how to possibly fix this. Maybe can run a glob at compilepkg time to pick up all possible transition dirs that need to be filtered out?
Why do you need to trim the bindir? You wrote that it's undesirable because it encodes "transition state", but what's the concrete problem this is causing you?
What version of rules_go are you using?
0.46
What version of Bazel are you using?
6.1.0
Does this issue reproduce with the latest releases of all the above?
I am very confident because of the problem I point out at the end of this issue
What operating system and processor architecture are you using?
Linux/x86_64
What did you do?
I am compiling a
go_library
that contains source files that are both in-tree as normal and some that are genrule outputs. However, I am having trouble getting the paths trimmed in the resulting archive. I am usinggo tool nm
to list the symbols and grepping forgofile
. Normally, it trims the paths for the normal files and the paths for the genruled files contain the bindir, which is not desirable as it depends on transition state.I tried passing something like
gc_goopts = ["-trimpath=$(BINDIR)=>."]
.What did you expect to see?
I expected to see that the genfiles had their paths trimmed. This was true.
What did you see instead?
However, the normal files did not have their paths trimmed anymore (meaning I fixed half of the files and broke the other half). In addition the bindir substitution was wrong, it replaced
BINDIR
with.:.
instead of.
.The result is that this archive cannot be shared between plugins and a main binary because of a version mismatch.
This colon is presumably from https://github.com/bazel-contrib/rules_go/blob/master/go/tools/builders/compilepkg.go#L512. Clearly its not being processed as a delimiter. According to https://github.com/golang/go/blob/master/src/cmd/internal/objabi/line.go#L70 the delimiter is actually a semicolon. Sadly, I tried editing rules_go to use a semicolon and it still doesn't work (the default trimpath isn't being applied still)
The text was updated successfully, but these errors were encountered: