[Bug]: [email protected] indirect dependency block me to build a program with stepca direct dependency in plugin buildmode

[ekopsy]

Steps to Reproduce

I tried to build a Go plugin with StepCA as a direct dependency. Building on macOS arm64 target works fine, but when I tried to build it on Linux / amd64, it failed with the following error:

[MAKE] build
GOOS=linux GOARCH=amd64 go build -trimpath -buildmode=plugin -o stepca-linux.so plugin.go;
# github.com/cespare/xxhash
asm: xxhash_amd64.s:120: when dynamic linking, R15 is clobbered by a global variable access and is used here: 00092 (/Users/ben/go/pkg/mod/github.com/cespare/[email protected]/xxhash_amd64.s:120) ADDQ    R15, AX
asm: assembly failed
make: *** [build-linux] Error 1

It seems that the issue has already been fixed in v2, as mentioned in this post

However, in your go.mod file, you still have an indirect dependency on github.com/cespare/xxhash v1.1.0, which is causing the error.

You can find an exemple below to reproduce.

src.zip

Your Environment

• OS - alpine 3.18.0
• Arch - amd64
• step-ca Version - 0.24.2
• Go 1.20

Expected Behavior

No errors when build a program in plugin buildmode with stepca direct dependency on arch amd64

Actual Behavior

[MAKE] build
GOOS=linux GOARCH=amd64 go build -trimpath -buildmode=plugin -o stepca-linux.so plugin.go;
github.com/cespare/xxhash
asm: xxhash_amd64.s:120: when dynamic linking, R15 is clobbered by a global variable access and is used here: 00092 (/Users/ben/go/pkg/mod/github.com/cespare/[email protected]/xxhash_amd64.s:120) ADDQ R15, AX
asm: assembly failed
make: *** [build-linux] Error 1

Additional Context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[maraino]

Hi @akapouet, can you share why you're trying to build a Go plugin with step-ca? What's the use case?

If you look into https://github.com/cespare/xxhash/blob/main/xxhash_amd64.s you can see that you can use the flag --tags purego to avoid using the assembly version and probably use just Go.

Looking at the dependency tree, you can also see that this dependency is coming from Badger. You can build step-ca without Badger using --tags nobadger. But you will need to properly configure step-ca for it to work.

[ekopsy]

Hi @maraino, thanks for your reply.

Sorry for the lack of precision. My final goal is to build a web service in front of multiple PKI, including StepCA.
To communicate with them, I have started creating client libraries in Go for each engine as plugins for my web service. For StepCA, I have directly included the library github.com/smallstep/certificates/ca in my plugin, and I call the necessary functions such as ca.CreateSignRequest, etc.

Each client is built in plugin mode, and each shared object file is loaded into my web service. This approach allows me to load only the required plugins instead of loading all of them.

Hoping to have been clearer on my need. I will take a look at the tag options to disable ASM as suggested. I will let you know if it fixes my issue.

[ekopsy]

Ok purego tags solved my issue. Thanks for your help @maraino