failing to compile because it can't lookup undefined symbol nvmlGpuInstanceGetComputeInstanceProfileInfoV

[drjoms]

meson compile -C builddir
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/sbin/ninja -C /home/dimko/compiled/toolbox/builddir
ninja: Entering directory `/home/dimko/compiled/toolbox/builddir'
[1/1] Generating src/zsh-completion with a custom command (wrapped by meson to capture output)
FAILED: src/_toolbox
/usr/lib/python-exec/python3.13/meson --internal exe --capture src/_toolbox -- /usr/bin/python3.13 /home/dimko/compiled/toolbox/src/meson_generate_completions.py /home/dimko/compiled/toolbox/src zsh
--- stderr ---
/tmp/go-build2866398736/b001/exe/toolbox: symbol lookup error: /tmp/go-build2866398736/b001/exe/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV
exit status 127
Traceback (most recent call last):
File "/home/dimko/compiled/toolbox/src/meson_generate_completions.py", line 32, in
output = subprocess.run(['go', 'run', '.', 'completion', completion_type], check=True)
File "/usr/lib/python3.13/subprocess.py", line 577, in run
raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['go', 'run', '.', 'completion', 'zsh']' returned non-zero exit status 1.

ninja: build stopped: subcommand failed.

Expected behaviour
No errors after compilation attempt

Actual behaviour
as per output above

Toolbx package info (rpm -q toolbox)
compiling from source

Output of podman version
e.g.,

Version:            1.9.2
RemoteAPI Version:  1
Go Version:         go1.14.2
OS/Arch:            linux/amd64

Podman package info (rpm -q podman)
[ebuild R ] app-containers/podman-5.3.2::gentoo USE="seccomp systemd -apparmor -btrfs (-selinux) -wrapper" 0 KiB

Info about your OS
current one only and latest Gentoo.(ongoing release)

Additional context
Attempting to follow those instructions:
https://containertoolbx.org/install/

meson compile -C builddir
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/sbin/ninja -C /home/dimko/compiled/toolbox/builddir
ninja: Entering directory `/home/dimko/compiled/toolbox/builddir'
[12/12] Generating src/zsh-completion with a custom command (wrapped by meson to capture output)
FAILED: src/_toolbox
/usr/lib/python-exec/python3.13/meson --internal exe --capture src/_toolbox -- /usr/bin/python3.13 /home/dimko/compiled/toolbox/src/meson_generate_completions.py /home/dimko/compiled/toolbox/src zsh
--- stderr ---
/home/dimko/.cache/go-build/8a/8acae153aba024568e3f0ca5d79f7f48544f8f994b124b69c9e8514ee61f787e-d/toolbox: symbol lookup error: /home/dimko/.cache/go-build/8a/8acae153aba024568e3f0ca5d79f7f48544f8f994b124b69c9e8514ee61f787e-d/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV
exit status 127
Traceback (most recent call last):
File "/home/dimko/compiled/toolbox/src/meson_generate_completions.py", line 32, in
output = subprocess.run(['go', 'run', '.', 'completion', completion_type], check=True)
File "/usr/lib/python3.13/subprocess.py", line 577, in run
raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['go', 'run', '.', 'completion', 'zsh']' returned non-zero exit status 1.

ninja: build stopped: subcommand failed.

Not sure if relevant, I have modern AMD GPU with AMDGPU drivers.(because, undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV)

[drjoms]

dev-lang/go-1.24.6

[debarshiray]

Which version of Toolbx are you trying to compile? Are you using your own linker flags?

--- stderr ---
/tmp/go-build2866398736/b001/exe/toolbox: symbol lookup error: /tmp/go-build2866398736/b001/exe/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV
exit status 127

This error makes me think that this about the linker flags. See these two commits:

• 66280a617ae7eaa2
• 83f28c52e47c2d44

I will be away for two weeks, starting from tomorrow, so I won't be able to respond immediately.

[debarshiray]

Ping.

[drjoms]

I am not entirely sure how those two commits relevant to my case. I am not owning any nvidia hardware, only AMD CPU and GPU.(amdgpu driver)
I went with what was in README.
I dont think Gentoo has tinkered with settings of "ld"(I assume this is what you asked?). I certainly did not put any specific ld options.

[drjoms]

i dont know if this helps
sys-devel/binutils-2.44-r4:2.44::gentoo USE="(cet) nls pgo plugins zstd -debuginfod -doc -gprofng -hardened -multitarget -static-libs -test -vanilla -xxhash" 0 KiB

[debarshiray]

I am not entirely sure how those two commits relevant to my case. I am not owning any nvidia hardware, only AMD CPU and GPU.(amdgpu driver)

The code to support the proprietary NVIDIA driver is always compiled, regardless of whether the hardware is present or not. Some of it is used at runtime to find out if the hardware and the proprietary driver is present. If it's present, then the rest of it used, else not.

[debarshiray]

meson compile -C builddir
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/sbin/ninja -C /home/dimko/compiled/toolbox/builddir
ninja: Entering directory `/home/dimko/compiled/toolbox/builddir'
[1/1] Generating src/zsh-completion with a custom command (wrapped by meson to capture output)
FAILED: src/_toolbox /usr/lib/python-exec/python3.13/meson --internal exe --capture src/_toolbox -- /usr/bin/python3.13 /home/dimko/compiled/toolbox/src/meson_generate_completions.py /home/dimko/compiled/toolbox/src zsh
--- stderr ---
/tmp/go-build2866398736/b001/exe/toolbox: symbol lookup error: /tmp/go-build2866398736/b001/exe/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV

The error above when compiling Toolbx is exactly the same as described in commit 83f28c52e47c2d44:

$ toolbox
  toolbox: symbol lookup error: toolbox: undefined symbol:
      nvmlGpuInstanceGetComputeInstanceProfileInfoV

In your case, when you are compiling Toolbx, it's trying to run toolbox(1) to generate the shell completions, and that's failing.

I went with what was in README.

You mean https://containertoolbx.org/install/ ? The upstream Toolbx CI uses the same way to build Toolbx, so it should work.

I am not familiar enough with Gentoo to dig into it and pinpoint what's exactly wrong. Right now my theory is that for some reason you are ending up using the -z now linker flag.

[drjoms]

Can you please give me an example of command that allows me to check linker settings for go programming language?(right?)
I understand that every (compiled)language can have custom flags for compilation of a specific program, due to making process?

is there a verbose way to compile toolbox?

[PeakKS]

I'm also on gentoo, and I also get this issue.

If I explicitly set -Wl,-z,lazy in go-build-wrapper the binary in builddir/src/toolbox works okay:

blake@gbox ~/Code/toolbox $ ./builddir/src/toolbox
Error: missing command

create    Create a new Toolbx container
enter     Enter an existing Toolbx container
list      List all existing Toolbx containers and images

Run 'toolbox --help' for usage.

However the on in the go build cache does not work correctly:

blake@gbox ~/Code/toolbox $ /home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox 
/home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox: symbol lookup error: /home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV

And since go tries to generate completions with the one in the cache, the build fails:

FAILED: [code=1] src/toolbox.bash 
/usr/lib/python-exec/python3.13/meson --internal exe --capture src/toolbox.bash -- /usr/bin/python3.13 /home/blake/Code/toolbox/src/meson_generate_completions.py /home/blake/Code/toolbox/src bash
--- stderr ---
/home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox: symbol lookup error: /home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV
exit status 127
Traceback (most recent call last):
  File "/home/blake/Code/toolbox/src/meson_generate_completions.py", line 32, in <module>
    output = subprocess.run(['go', 'run', '.', 'completion', completion_type], check=True)
  File "/usr/lib/python3.13/subprocess.py", line 577, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['go', 'run', '.', 'completion', 'bash']' returned non-zero exit status 1.

[3/3] Generating src/zsh-completion with a custom command (wrapped by meson to capture output)
FAILED: [code=1] src/_toolbox 
/usr/lib/python-exec/python3.13/meson --internal exe --capture src/_toolbox -- /usr/bin/python3.13 /home/blake/Code/toolbox/src/meson_generate_completions.py /home/blake/Code/toolbox/src zsh
--- stderr ---
/home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox: symbol lookup error: /home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox: undefined symbol: nvmlGpuInstanceGetComputeInstanceProfileInfoV
exit status 127
Traceback (most recent call last):
  File "/home/blake/Code/toolbox/src/meson_generate_completions.py", line 32, in <module>
    output = subprocess.run(['go', 'run', '.', 'completion', completion_type], check=True)
  File "/usr/lib/python3.13/subprocess.py", line 577, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['go', 'run', '.', 'completion', 'zsh']' returned non-zero exit status 1.

ninja: build stopped: subcommand failed.

They list different dependencies with ldd as well.

blake@gbox ~/Code/toolbox $ ldd builddir/src/toolbox 
	linux-vdso.so.1 (0x00007f603952d000)
	libresolv.so.2 => /run/host/usr/lib64/libresolv.so.2 (0x00007f6039513000)
	libc.so.6 => /run/host/usr/lib64/libc.so.6 (0x00007f6039325000)
	/run/host/usr/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f603952f000)
blake@gbox ~/Code/toolbox $ ldd /home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox 
	linux-vdso.so.1 (0x00007f3d662a8000)
	libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007f3d66268000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f3d6607a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3d662aa000)

[PeakKS]

@drjoms If it helps I now have updated the toolbox ebuild in my overlay to the latest release plus the patches I have pending in #1722 : https://github.com/PeakKS/peakover/blob/master/app-containers/toolbox/toolbox-0.3.ebuild

[debarshiray]

I'm also on gentoo, and I also get this issue.

If I explicitly set -Wl,-z,lazy in go-build-wrapper the binary in builddir/src/toolbox works okay:

[...]

However the on in the go build cache does not work correctly:

I see. Thanks for tracking this down!

They list different dependencies with ldd as well.

blake@gbox ~/Code/toolbox $ ldd builddir/src/toolbox 
	linux-vdso.so.1 (0x00007f603952d000)
	libresolv.so.2 => /run/host/usr/lib64/libresolv.so.2 (0x00007f6039513000)
	libc.so.6 => /run/host/usr/lib64/libc.so.6 (0x00007f6039325000)
	/run/host/usr/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f603952f000)
blake@gbox ~/Code/toolbox $ ldd /home/blake/.cache/go-build/ac/ac4db54da5e00df3baa68975a29060c989f1fbd5ac1d6f48100d0835fd076f37-d/toolbox 
	linux-vdso.so.1 (0x00007f3d662a8000)
	libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007f3d66268000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f3d6607a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3d662aa000)

Yes, the binary in the cache is broken. Containers created with it might have trouble starting.

I am curious, does the problem go away if you delete the cache or the cached binary?