Arch Linux User Repository

@jholmer In the past with similar errors what worked for me was to reinstall the python-onnx package. I'm not saying it's a definite solution, but it could work

I am also receiving the "Could not load library libnvonnxparser.so.10: Unable to open library: libnvonnxparser.so.10 due to /usr/lib/libnvonnxparser.so.10: undefined symbol: _ZTIN8onnx2trt16OnnxTrtExceptionE" error on runtime. I have tried doing a completely clean build. I'm wondering if there is some sort of version incompatibility between this package and a dependency?

@lu0se yes, the '.so' link to 'libnvonnxparser.so.10' is right, otherwise you would get a 'file not found' error. If you are getting a 'Using existing $srcdir/ tree' warning during makepkg, it means that you are not doing a clean build. You should use makepkg --cleanbuild/-C option for doing a clean build when building your packages, or build it in a clean chroot. Try to do it and see if it works.

trtexec --onnx=rife_v4.10.onnx

&&&& RUNNING TensorRT.trtexec [TensorRT v100400] [b26] # trtexec --onnx=/usr/lib/vapoursynth/models/rife/rife_v4.10.onnx --device=0 [09/20/2024-02:01:38] [I] Start parsing network model. [09/20/2024-02:01:38] [E] Could not load library libnvonnxparser.so.10: Unable to open library: libnvonnxparser.so.10 due to /usr/lib/libnvonnxparser.so.10: undefined symbol: _ZTIN8onnx2trt16OnnxTrtExceptionE [09/20/2024-02:01:38] [E] Assertion failure: parser.onnxParser != nullptr

is libnvonnxparser.so.10 link right？is it related to WARNING: Using existing $srcdir/ tree

@dbermond: the forum post is not mine. I got the same/similar error when I tried to edit the PKGBUILD manually to try to build the newer tensorrt against cuda 12.5.

You have a commented out part in the PKGBUILD in which you compile the python bindings.

# python bindings (fails to build with python 3.11) #local _pyver ...

Since my GPU (1060) is no longer supported by tensorrt 10, I had to get the 9 version to work and compile the python bindings for python 3.12 myself.

All I had to do was set another ENV variable and adjust the install command.

in build()...{ ... local -x TENSORRT_MODULE="tensorrt" ... }

the generated whl is located somewhere else, therefore adapt the install command

in package_python-tensorrt() { ...

python -m installer --destdir="$pkgdir" "TensorRT/python/build/bindings_wheel/dist/"*.whl

... }

I cannot say whether everything is correct. But everything compiles and the models also run (rife+upscale via trt).

In case someone might need it.

@milianw I could compile your 'binsim.cu' source file using cuda 12.5.1 by running the exact same nvcc command that you posted in the mentioned nvidia thread. No errors, no warnings, and the 'binsimCUDA' executable builds fine. I cannot answer why you are getting these errors, and further discussing this here will be out of the scope of this AUR web page.

@dbermond: if gcc is not an issue, then why did I see the compile errors from the linked forum thread? I have gcc13 installed, but only

$ ls /usr/include/c++/
14.1.1  v1

So gcc13 will still end up using libstc++ headers from gcc14 which are incompatible. How is this supposed to work?

@milianw Sure, I will be happy to update the package if you provide the fix for this issue that I reported upstream in the same day 10.2 was released. And there is also this another one which I reported, but I could fix it myself. Please notice that if you can fix the first issue, other ones may arise later in the compilation, or even in the python modules, so make sure to check everything. Regarding the gcc usage in cuda, each cuda version uses a specific gcc version. cuda 12.5 uses gcc13 (and not gcc14), so the gcc version is not a problem for us, since the cuda package is already using the correct one.

meh, just updating the versions won't be sufficient since cuda (even 12.5 apparently) is not compatible with gcc 14 system includes: https://forums.developer.nvidia.com/t/cuda-12-4-nvcc-and-gcc-14-1-incompatibility/293295