Package Details: libnvidia-container 1.10.0-1

Git Clone URL: (read-only, click to copy)
Package Base: libnvidia-container
Description: NVIDIA container runtime library
Upstream URL:
Licenses: Apache
Submitter: lukeyeager
Maintainer: jshap (kiendang)
Last Packager: jshap
Votes: 22
Popularity: 0.049775
First Submitted: 2017-09-12 21:34 (UTC)
Last Updated: 2022-07-09 13:55 (UTC)

Latest Comments

Nephyrin commented on 2022-03-29 23:10 (UTC)

The problem seems to be go breaking their whole ecosystem with their module shenanigans.

This fixes the build for me:

diff --git a/PKGBUILD b/PKGBUILD
index ab0a282..0988186 100644
@@ -74,7 +74,7 @@ build(){
   cd ${_srcdir}

   # finally actually make
-  CC=gcc make
+  CC=gcc make GO111MODULE=auto


Nephyrin commented on 2022-03-29 23:02 (UTC)

1.9.0 seems to be failing as of today with:

go build -o -ldflags "-s -w" -buildmode=c-shared .
main.go:22:2: cannot find package "nvcgo/internal/cgroup" in any of:
        /usr/lib/go/src/nvcgo/internal/cgroup (from $GOROOT)
        /home/$USER/go/src/nvcgo/internal/cgroup (from $GOPATH)
make[2]: *** [Makefile:40:] Error 1

jshap commented on 2022-02-14 18:02 (UTC)

@trumee should be fixed now, somehow missed adding go as a makedep.

trumee commented on 2022-02-13 05:13 (UTC) (edited on 2022-02-13 05:13 (UTC) by trumee)

1.8.0 failed to install,

export CGO_CFLAGS="-std=gnu11 -O2"; \
export CGO_LDFLAGS="-Wl,--gc-sections -Wl,-s -Wl,-soname,"; \
go build -o -ldflags "-s -w" -buildmode=c-shared .
/bin/sh: line 3: go: command not found
make[2]: *** [Makefile:40:] Error 127

KerfuffleV2 commented on 2022-02-09 17:44 (UTC)

1.8.0 seems to have a build dependency on the go compiler which is not correctly defined. Therefore, it fails to build in a chroot (and presumably any system without the go toolchain already installed.)

ruidc commented on 2022-01-08 23:31 (UTC)

Following a reboot it installed fine. I must have applied system updates during that boot.

ruidc commented on 2022-01-04 08:57 (UTC)

Very strange indeed! sorry, I can't explain why on my fresh Arch system (not derivative) they were missing when base-devel was installed - sorry for the noise. Can you suggest a solution to the linking error? or should I have a go at producing it in a docker image?

jshap commented on 2022-01-03 15:14 (UTC)

Both groff and patch are in base-devel[1]. Are you perhaps on a derivative distro and not archlinux?


ruidc commented on 2022-01-03 05:53 (UTC)

I am also getting this on a freshly built system. Also, patch,groff/nroff and patch were not part of base-devel

osiro commented on 2021-09-02 10:42 (UTC) (edited on 2021-09-02 10:48 (UTC) by osiro)

Have you guys come across with this:

/usr/bin/ld: warning: ./libnvidia-container/src/libnvidia-container-1.4.0/src/ contains output sections; did you forget -T?
/usr/bin/ld: ./libnvidia-container/src/libnvidia-container-1.4.0/deps/usr/lib/libelf.a(elf_scn.o): in function `_libelf_load_section_headers':
./libnvidia-container/src/libnvidia-container-1.4.0/deps/src/elftoolchain-0.7.1/libelf/elf_scn.c:72: undefined reference to `_libelf_fsize'
/usr/bin/ld: ./libnvidia-container/src/libnvidia-container-1.4.0/deps/usr/lib/libelf.a(gelf_fsize.o): in function `elf32_fsize':
./libnvidia-container/src/libnvidia-container-1.4.0/deps/src/elftoolchain-0.7.1/libelf/gelf_fsize.c:37: undefined reference to `_libelf_fsize'
/usr/bin/ld: ./libnvidia-container/src/libnvidia-container-1.4.0/deps/usr/lib/libelf.a(gelf_fsize.o): in function `elf64_fsize':
./libnvidia-container/src/libnvidia-container-1.4.0/deps/src/elftoolchain-0.7.1/libelf/gelf_fsize.c:43: undefined reference to `_libelf_fsize'
/usr/bin/ld: ./libnvidia-container/src/libnvidia-container-1.4.0/deps/usr/lib/libelf.a(libelf_ehdr.o): in function `_libelf_ehdr':
./libnvidia-container/src/libnvidia-container-1.4.0/deps/src/elftoolchain-0.7.1/libelf/libelf_ehdr.c:138: undefined reference to `_libelf_fsize'
/usr/bin/ld: ./libnvidia-container/src/libnvidia-container-1.4.0/deps/usr/lib/libelf.a(libelf_ehdr.o): in function `_libelf_load_extended':
./libnvidia-container/src/libnvidia-container-1.4.0/deps/src/elftoolchain-0.7.1/libelf/libelf_ehdr.c:52: undefined reference to `_libelf_fsize'
collect2: error: ld returned 1 exit status
make: *** [Makefile:202:] Error 1
==> ERROR: A failure occurred in build().

I am unsure whether this has to do with the version of ld, the one I've got it: GNU ld (GNU Binutils) 2.36.1

lmat commented on 2021-03-25 16:12 (UTC)

When I click "Download Snapshot", it downloads libnvidia-container.tar.gz (which is one of this package's dependencies. When I "manually" change the URL to download libnvidia-container-tools.tar.gz, I get the file, but makepkg fails with a validity check. I think I'm missing something.

kosantosbik commented on 2021-02-14 05:31 (UTC)

@jshap You are a lifesaver man. Thank you very much :)

jshap commented on 2021-02-13 23:42 (UTC)

@kosantosbik and @popov-aa : I was able to get a patch working which overwrites the build target from /usr/share/mk/ so it should all be working now :)

kosantosbik commented on 2021-02-12 09:31 (UTC)

@jshap any luck with the fix?

jshap commented on 2021-02-11 00:21 (UTC)

@popov-aa it's an issue/bug with bmake coming from which is where the -soname flag comes from. idk what changed with ld to break it yet though, it's very weird. Still looking into what I can do about it :(

popov-aa commented on 2021-02-09 14:10 (UTC)

building standard elf library
--- libelf_convert.pico ---
ld -x -r libelf_convert.pico.o -o libelf_convert.pico
--- libelf_pic.a ---
building shared object elf library
--- libelf_p.a ---
building profiled elf library
--- libelf.a ---
ranlib libelf.a
--- libelf_pic.a ---
ranlib libelf_pic.a
--- libelf_p.a ---
ranlib libelf_p.a
--- ---
building shared elf library (version 1)
gcc -o -shared -Wl,"-soname" -Wl,--whole-archive libelf_pic.a -Wl,--no-whole-archive  
/usr/bin/ld: Error: unable to disambiguate: -soname (did you mean --soname ?)
collect2: error: ld returned 1 exit status
*** [] Error code 1

Disabling patches not working for me.

homerhsing commented on 2020-12-27 20:35 (UTC) (edited on 2020-12-27 20:36 (UTC) by homerhsing)

The wiki says "Members of the base-devel group should not be included in the makedepends array." Gotcha. Thanks for pointing it out!

However, pkgconf (a.k.a pkg-config) is in the base-devel group (see here ) therefore it shouldn't be added to makedepends.

jshap commented on 2020-12-26 23:22 (UTC)

Patch and m4 are in base-devel and are assumed to be installed. see the note in

Updating to add pkgconf as a makedep as that's a real dependency. Thanks for pointing it out, cyounkins

homerhsing commented on 2020-12-26 02:06 (UTC) (edited on 2020-12-26 02:10 (UTC) by homerhsing)

Hey, this package should have declared "makedepends" dependencies on the package named "patch" and "m4"! Thanks!

cyounkins commented on 2020-12-23 20:05 (UTC)

This package appears to have an undeclared dependency on pkg-config

jshap commented on 2020-04-05 22:25 (UTC)

very strange, I'm still seeing it being named wrong locally. I've gone ahead and changed it to be a conditional, hopefully it should work for everyone now :/

phixion commented on 2020-04-05 15:00 (UTC) (edited on 2020-04-05 15:01 (UTC) by phixion)

had similar errors

mv /home/phixion/libnvidia-container/src/libnvidia-container-1.0.6/deps/src/elftoolchain-0.7.1/libelf/'name' /home/phixion/libnvidia-container/src/libnvidia-container-1.0.6/deps/src/elftoolchain-0.7.1/libelf/''
mv: cannot stat '/home/phixion/libnvidia-container/src/libnvidia-container-1.0.6/deps/src/elftoolchain-0.7.1/libelf/name': No such file or directory

removing fix_libelf_so_name.patch from the PKGBULD and a clean build fixed it for me

jshap commented on 2020-04-02 21:54 (UTC)

@kokx should be fixed now. that was a very weird issue, considering it seems like something w/in the elf build broke despite the pkg being version locked...

kokx commented on 2020-04-01 11:44 (UTC) (edited on 2020-04-01 11:45 (UTC) by kokx)

When trying to install, this package gives the following error for me:

install -D -c -o 1000 -g 1000 -m 444 /home/kokx/aur/libnvidia-container/src/libnvidia-container-1.0.5/deps/usr/lib
install: cannot stat '': No such file or directory

I get this error when using pikaur and when using makepkg -si

jshap commented on 2019-05-20 15:54 (UTC)

@archasaurusrex I don't think packer works with split packages like this (also all of the jetbrains tools or many many many of the builds from the trusted repos), so it's an issue with the tool and not this package. sorry. fwiw yay works perfectly fine with it for me, plus you can always just build and install it by hand with makepkg -Si.


archasaurusrex commented on 2019-05-20 14:24 (UTC)

I get an error while trying to install from packer:

error: 'libnvidia-container-tools-1.0.2-1-x86_64.okg.tar.xz': duplicate target
Dependencies for `libnvidia-container-tools` are not met, not building...

this happens after it apparently builds just fine, but it won't install.

I ran across this while trying to install nvidia-docker via packer. I'm able to work around it by first installing libnvidia-container-tools-bin and libnvidiai-container-bin.

jshap commented on 2019-03-25 15:50 (UTC)

good catch, updated to just totally remove relative references in place of just using $srcdir

petronny commented on 2019-03-25 10:38 (UTC)


==> Starting prepare()...
patch: **** Can't open patch file ../../fix_rpc_flags.patch : No such file or directory
==> ERROR: A failure occurred in prepare().

You should use

patch -Np1 -i ../fix_rpc_flags.patch
patch -Np1 -i ../fix_git_rev_unavail.patch

bzs commented on 2019-03-20 17:21 (UTC)

jshap70 kiendang yes I was using pikaur -S libnvidia-container; it does appear to be fixed now, thanks!

jshap commented on 2019-03-20 16:33 (UTC)

alright updated, let me know if that fixed it for you bzs

jshap commented on 2019-03-20 16:18 (UTC) (edited on 2019-03-20 16:18 (UTC) by jshap)

ah, my guess is that pikaur isn't making this by cloning the aur branch, and in mk/ it does REVISION := $(shell git rev-parse HEAD) which locally for me would turn into the parent aur repo's git revision by mistake.

I'll make a patch for that quickly.

kiendang commented on 2019-03-20 16:02 (UTC)

bzs may I know which command you use to install the package? also could you try clone the package then makepkg -rsi and see if it works?

bzs commented on 2019-03-20 15:42 (UTC)

I'm encountering the following failure when building from source: ==> Making package: libnvidia-container 1.0.1-1 (Wed 20 Mar 2019 11:39:47 AM EDT) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found v1.0.1.tar.gz -> Found elftoolchain-0.7.1.tar.bz2 -> Found 396.51.tar.gz -> Found fix_rpc_flags.patch ==> Validating source files with sha256sums... v1.0.1.tar.gz ... Passed elftoolchain-0.7.1.tar.bz2 ... Passed 396.51.tar.gz ... Passed fix_rpc_flags.patch ... Passed ==> Extracting sources... -> Extracting v1.0.1.tar.gz with bsdtar -> Extracting elftoolchain-0.7.1.tar.bz2 with bsdtar -> Extracting 396.51.tar.gz with bsdtar ==> Starting prepare()... /home/bzs/.cache/pikaur/build/libnvidia-container/src/libnvidia-container-1.0.1 patching file Makefile ==> Removing existing $pkgdir/ directory... ==> Starting build()... fatal: not a git repository (or any of the parent directories): .git /home/bzs/.cache/pikaur/build/libnvidia-container/src/libnvidia-container-1.0.1/mk/ *** Invalid commit hash. Stop. ==> ERROR: A failure occurred in build(). Aborting...

jshap commented on 2019-03-20 05:07 (UTC) (edited on 2019-03-20 15:11 (UTC) by jshap)

This package was changed to properly build from source. If you want to continue using prebuilt binaries you can use libnvidia-container-bin.

kiendang commented on 2019-03-06 02:59 (UTC)

Cool! I will submit the -bin packages and work on src packages for nvidia-container-runtime and nvidia-container-runtime-hook then.

jshap commented on 2019-03-06 02:28 (UTC)

@kiendang oh awesome! I'll add you as a co-maintainer later when I get back to my computer. yeah, me taking it over was an effort to try and stop it being so split up.

My plan was to turn this into the src version and spin off a -bin version later, but if you already have those then do you want to just get those packages started right away? I'm close to getting the src pkgbuild up for this as well as -tools, just sorting out some weirdness with the make setup.

actually on topic, I don't think it really makes sense to keep -tools around, as afaik it's not really feasible to use the libs without the cli. but open to feedback on that.

kiendang commented on 2019-03-06 01:49 (UTC)

@jshap70 I do maintain my own PKGBUILD files for libnvidia-container-bin, libnvidia-container-tools-bin, nvidia-container-runtime-bin and nvidia-container-runtime-hook-bin at Originally I wanted to keep it to myself since each of these packages was maintained by a different person. But now you maintain all of them would you mind add me as a co-maintainer? I do plan to create a build from source version soon.

jshap commented on 2019-03-04 17:58 (UTC)

adopting this and will take a look at reworking the pkgbuilds soon, if someone else would like to lmk and i'll disown it

jshap commented on 2019-03-04 17:58 (UTC)

adopting this and will take a look at reworking the pkgbuilds soon, if someone else would like to lmk and i'll disown it

lukeyeager commented on 2019-03-04 17:28 (UTC)

Disowning. Suggest next maintainer either builds from source or adds "-bin" suffix.

lukeyeager commented on 2019-03-04 17:27 (UTC)

Disowning. Suggest next maintainer either builds from source or adds "-bin" suffix.

nlgranger commented on 2019-03-03 19:44 (UTC)

Please consider updating this PKGBUILD. Since this is not a "-bin" package, it should probably build the library from the sources. Here is a starting point if that can help: