V2 breaks xk6 cross compilation

[timvahlbrock]

Hey there, thanks for this easy to use project. We are currently trying to upgrade to V2 and have noticed, that cross compilation (specifically Linux compiles for ARM MacOS) in a docker image no longer seems to work.

Commands that work in the golang:1.26.4 image:

xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v1.3.0 --os linux --verbose

xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v1.3.0 --os darwin --verbose

xk6 build --k6-version v2.0.0 --with github.com/mostafa/xk6-kafka/v2@v2.0.0 --os linux --verbose

Commands that don't work in the same image:

xk6 build --k6-version v2.0.0 --with github.com/mostafa/xk6-kafka/v2@v2.0.0 --os darwin --verbose

The command fails with

9:24AM INF Building k6
# github.com/confluentinc/confluent-kafka-go/v2/schemaregistry/internal
/xk6-go/mod/github.com/confluentinc/confluent-kafka-go/v2@v2.14.0/schemaregistry/internal/rest_service.go:93:22: undefined: kafka.LibraryVersion
9:24AM INF Cleaning up work directory /tmp/k6foundry2632259015
9:24AM ERR compiling: executing go command: exit status 1

It would be great if this could work again, because by cross building with docker we can avoid having each developer install a k6 toolchain and maintain it.

[timvahlbrock]

possibly related to confluentinc/confluent-kafka-go#119 ?

[mostafa]

Hey! 👋

Thanks for raising this. Did you see #393?

[timvahlbrock]

Oh i thought I read in the release notes this was already migrated to k6@v2. It isn't? That explains why xk6 keeps logging that k6 is still referenced.

[timvahlbrock]

Oh i thought I read in the release notes this was already migrated to k6@v2. It isn't? That explains why xk6 keeps logging that k6 is still referenced.

I even wondered why the go.mod still referenced 1.7.1 . Okay. We're gonna wait for #393 then and check again when it's done.

[timvahlbrock]

Well, I just ran

xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v2.0.0 --os darwin --verbose

and that raises the same error.

[mostafa]

@timvahlbrock That's because you need CGO_ENABLED=1 as env-var passed before the command:

CGO_ENABLED=1 xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v2.0.0 --os darwin --verbose

[timvahlbrock]

Was already enabled

root@70c200314f81:/xk6# echo $CGO_ENABLED
1
root@70c200314f81:/xk6# xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v2.0.0 --os darwin --verbose
10:06AM INF Building new k6 binary (native)
10:06AM INF Initializing Go module
go: creating new go.mod: module k6
10:06AM INF Creating k6 main
10:06AM INF adding dependency go.k6.io/k6@v1.7.1
10:06AM INF importing extensions
10:06AM INF adding dependency github.com/mostafa/xk6-kafka/v2@v2.0.0
go: finding module for package github.com/aws/aws-sdk-go-v2/service/signin
go: finding module for package github.com/moby/sys/atomicwriter
go: finding module for package github.com/aws/aws-sdk-go-v2/credentials/logincreds
go: found github.com/moby/sys/atomicwriter in github.com/moby/sys/atomicwriter v0.1.0
go: found github.com/aws/aws-sdk-go-v2/credentials/logincreds in github.com/aws/aws-sdk-go-v2/credentials v1.19.22
go: found github.com/aws/aws-sdk-go-v2/service/signin in github.com/aws/aws-sdk-go-v2/service/signin v1.1.4
10:06AM INF Building k6
# github.com/confluentinc/confluent-kafka-go/v2/schemaregistry/internal
/xk6-go/mod/github.com/confluentinc/confluent-kafka-go/v2@v2.14.0/schemaregistry/internal/rest_service.go:93:22: undefined: kafka.LibraryVersion
10:06AM INF Cleaning up work directory /tmp/k6foundry1617262420
10:06AM ERR compiling: executing go command: exit status 1
root@70c200314f81:/xk6# 

[timvahlbrock]

If that command works for you, maybe this has something to do with the host architecture. Running on Apple Silicon means I'm running the arm64 variant of the image.

[mostafa]

Same exact command worked for me with xk6 v1.4.5 and Go version go1.26.3 darwin/arm64 on macOS:

$ CGO_ENABLED=1 xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v2.0.0 --os darwin --verbose
12:14PM DBG Resolving k6 repo module path for version repo=go.k6.io/k6 version=v1.7.1
12:14PM DBG Inferred module path from semver base=go.k6.io/k6 version=v1.7.1 path=go.k6.io/k6
12:14PM DBG Resolved k6 repo path repo=go.k6.io/k6
12:14PM INF Building new k6 binary (native)
12:14PM INF Initializing Go module
go: creating new go.mod: module k6
12:14PM INF Creating k6 main
12:14PM INF adding dependency go.k6.io/k6@v1.7.1
12:14PM INF importing extensions
12:14PM INF adding dependency github.com/mostafa/xk6-kafka/v2@v2.0.0
go: finding module for package github.com/aws/aws-sdk-go-v2/service/signin
go: finding module for package github.com/moby/sys/atomicwriter
go: finding module for package github.com/aws/aws-sdk-go-v2/credentials/logincreds
go: found github.com/moby/sys/atomicwriter in github.com/moby/sys/atomicwriter v0.1.0
go: found github.com/aws/aws-sdk-go-v2/credentials/logincreds in github.com/aws/aws-sdk-go-v2/credentials v1.19.22
go: found github.com/aws/aws-sdk-go-v2/service/signin in github.com/aws/aws-sdk-go-v2/service/signin v1.1.4
12:14PM INF Building k6
12:15PM INF Build complete
12:15PM INF Cleaning up work directory /var/folders/ts/3418f6fs7cq3lgwtff3fq42r0000gn/T/k6foundry167940478
12:15PM INF Successful build platform=darwin/arm64
12:15PM INF added module=go.k6.io/k6 version=v1.7.1
12:15PM INF added module=github.com/mostafa/xk6-kafka/v2 version=v2.0.0
12:15PM INF A new binary has been built based on k6 version=v1.7.1
12:15PM DBG Go proxy request url=https://proxy.golang.org/go.k6.io/k6/@latest
12:15PM DBG Go proxy response url=https://proxy.golang.org/go.k6.io/k6/@latest status=200
12:15PM WRN Newer k6 version available actual=v1.7.1 latest=v1.8.0

xk6 has now produced a new k6 binary which may be different than the command on your system path!
Be sure to run './k6 run <SCRIPT_NAME>' from the '/Users/mostafa/Documents/Obsidian/Job/idea-proposals' directory.

Why don't you just use the binary I ship as part of the releases?

[timvahlbrock]

Same exact command worked for me in xk6 v1.4.5 and Go version go1.26.3 darwin/arm64 on macOS:

I'm gonna try again with those versions.

Why don't you just use the binary I ship as part of the releases?

Because we also use other extensions.

[mostafa]

Because we also use other extensions.

This might cause issues. Isolate builds to see which one is acting up.

[timvahlbrock]

Because we also use other extensions.

This might cause issues. Isolate builds to see which one is acting up.

We do. The reproduction are only with this extension.

Using Version 1.4.5 of xk6 is no help. Using the amd64 image does not help either. It seems like you ran native. So that isn't a cross compile, right?

[timvahlbrock]

Running cross compilation for Linux using

CGO_ENABLED=1 xk6 build --k6-version v1.7.1 --with github.com/mostafa/xk6-kafka@v2.0.0 --os linux --verbose

on native MacOS throws the same error.

[mostafa]

@timvahlbrock

I dug into this, and found the issue:

TL;DR

I already tried Option 1 below and it works well.

@yorugac I believe we should fix xk6.

Root cause

The error is a Go type-check error, not a C/linker error:

schemaregistry/internal/rest_service.go:93:22: undefined: kafka.LibraryVersion

kafka.LibraryVersion is defined in confluent-kafka-go/v2/kafka/kafka.go, and that file is cgo (it has import "C" at line 271, and LibraryVersion() calls C.rd_kafka_version()):

// LibraryVersion returns the underlying librdkafka library version as a
// (version_int, version_str) tuple.
func LibraryVersion() (int, string) {
	ver := (int)(C.rd_kafka_version())
	verstr := C.GoString(C.rd_kafka_version_str())
	return ver, verstr
}

When CGO is disabled, Go silently drops every import "C" file from the build. So kafka.go vanishes, kafka.LibraryVersion no longer exists, and schemaregistry/internal (pure Go, always compiled) fails to resolve it. That's exactly the symptom we see.

So the real question is: why is CGO off when we explicitly passed CGO_ENABLED=1/--cgo?

Because xk6/k6foundry forcibly disables it for any cross-build. In k6foundry's env setup:

	// disable CGO if target platform is different from host platform
	if env["GOHOSTARCH"] != platform.Arch || env["GOHOSTOS"] != platform.OS {
		env["CGO_ENABLED"] = "0"
	}

I'm on darwin/arm64 building for linux, so the platform differs and CGO_ENABLED is hard-overwritten to 0, even though my env var and --cgo flag were already applied. That's why all three attempts (--cgo, --cgo=1, CGO_ENABLED=1) produced the identical error. librdkafka being absent is the next problem we'd hit, but you never even get there because CGO is switched off first.

Interestingly, I already solved it in the CI by already encoding a workaround for this (.github/workflows/build.yaml lines 78-87): run xk6 build --skip-cleanup, scrape the temp dir from the log, then run go build manually with CGO_ENABLED=1. Note that CI never cross-compiles to Linux. It uses native ubuntu runners and only cross-builds darwin-arm64 -> darwin-amd64 (same OS, where Apple clang handles -arch fine).

Fixes

There's no flag to stop xk6 from killing CGO on a cross-build, so you have two practical paths.

Option 1: build natively inside a Linux container (recommended, most robust)

No cross-toolchain headaches; CGO stays on because it's a native build in the container:

docker run --rm -v "$PWD":/src -w /src golang:1.26 bash -c '
  apt-get update && apt-get install -y --no-install-recommends pkg-config librdkafka-dev gcc ca-certificates &&
  go install go.k6.io/xk6/cmd/xk6@latest &&
  CGO_ENABLED=1 $(go env GOPATH)/bin/xk6 build --k6-version v1.7.1 \
    --with github.com/mostafa/xk6-kafka@v2.1.0 -o k6-linux
'

On Apple Silicon this produces a linux/arm64 binary by default. For linux/amd64, add --platform linux/amd64 to docker run (uses emulation, slower but works).

Option 2: cross-compile from macOS with a real Linux C toolchain (mirrors your CI trick)

Use zig as the C compiler and the bundled musl static librdkafka (confluent-kafka-go ships librdkafka_musl_linux_amd64.a, selected via -tags musl, which pairs cleanly with zig's musl target):

brew install zig

# Let xk6 generate the module dir, then grab it (the build itself fails with CGO off — expected)
xk6 build --skip-cleanup --output /dev/null --k6-version v1.7.1 \
  --with github.com/mostafa/xk6-kafka@v2.1.0 --os linux --verbose 2>&1 | tee /tmp/xk6.log || true
BUILD_DIR=$(sed -n 's/.* leaving directory \(.*\) intact/\1/p' /tmp/xk6.log)

# Now build it yourself, with CGO actually on and a linux cross-compiler
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 \
  CC="zig cc -target x86_64-linux-musl" \
  CXX="zig c++ -target x86_64-linux-musl" \
  go build -C "$BUILD_DIR" -tags musl -trimpath -ldflags="-s -w" \
  -o "$PWD/k6-linux-amd64" .

For arm64, swap GOARCH=arm64 and -target aarch64-linux-musl.

Key detail: the -tags musl is important. Without it, Go picks the glibc bundle (librdkafka_glibc_linux_amd64.a), which won't link against zig's musl target.

[yorugac]

Wow, that's quite a trick!

I assume there's no way around getting version at the level of Confluent Go library, like a hard-coded const or something.

I believe we should fix xk6.

Agreed, it'd be nice to solve this upstream. Basically, this is about having one, "recommended" way of supporting a cross-platform xk6 builds that depend on CGO_ENABLED=1. Though I don't know if there's another such extension as xk6-kafka / Confluent that would have this kind of issue with CGO 🤔

@mostafa, IMO, this needs an issue in k6foundry 👀