Undefined reference to 'memset@GLIBC_2.2.5' on Jetson Xavier, not on Dell/A5000

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

I have a (Cuda) video application based on a library that compiles, links, and runs fine on a Dell/Ubuntu/A5000 system, with Cuda 12.1.
When building the same code, i.e. the library, on a freshly flashed Jetson Xavier with JetPak 511, it compiles fine, but the link phase fails with a lot of “undefined reference to xxx@GLIC_yyy” where xxx in: memset, strncpy, __stack_chk_fail, … , and yyy in: 2.4, 2.2.5, etc.:

Linking “libptgde.so” (aarch64)…
/usr/local/cuda/bin/nvcc -ccbin g++ --shared -m64 -Xcompiler -Wall -Xcompiler -O2 -Xcompiler -fPIC -Xcompiler -DPTGDE_EXPORTS -Xcompiler -fvisibility=hidden -Xcompiler -I/usr/local/include/opencv4 -Xlinker --no-undefined -gencode arch=compute_52,code=sm_52 -gencode arch=compute_53,code=sm_53 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_61,code=sm_61 -gencode arch=compute_62,code=sm_62 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_72,code=sm_72 -gencode arch=compute_75,code=sm_75 -gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86 -gencode arch=compute_87,code=sm_87 -gencode arch=compute_87,code=compute_87 -o libptgde.so PTGDE.o CudaColorAdjust.o CudaDEFn.o CudaMotionAdaptive2.o -lopencv_core -lopencv_cudaarithm -lopencv_cudaimgproc -lopencv_imgproc

/usr/bin/ld: PTGDE.o: in function CUDA::resetBuffers(PTGDE_PARAMETER&) [clone .isra.0]': PTGDE.cpp:(.text+0x76c): undefined reference to __stack_chk_fail@GLIBC_2.4’
/usr/bin/ld: PTGDE.o: in function PTGDE_resetBuffers': PTGDE.cpp:(.text+0x84c): undefined reference to memset@GLIBC_2.2.5’
/usr/bin/ld: PTGDE.cpp:(.text+0x8b8): undefined reference to memset@GLIBC_2.2.5' /usr/bin/ld: PTGDE.cpp:(.text+0x118c): undefined reference to __stack_chk_fail@GLIBC_2.4’
/usr/bin/ld: PTGDE.o: in function PTGDE_createParameter': PTGDE.cpp:(.text+0x1488): undefined reference to strncpy@GLIBC_2.2.5’

Any pointers towards the reason for this and a solution would be greatly appreciated.

3

Hi,

Could you try to add -lc in the Makefile to see if it helps?
Thanks.

4

I did what you suggested (see below). Same result I think. (And more info below …)

/usr/local/cuda/bin/nvcc -ccbin g++ -lc --shared -m64 -Xcompiler -Wall -Xcompiler -O2 -Xcompiler -fPIC -Xcompiler -DPTGDE_EXPORTS -Xcompiler -fvisibility=hidden -Xcompiler -I/usr/include/opencv4 -Xlinker --no-undefined -gencode arch=compute_52,code=sm_52 -gencode arch=compute_53,code=sm_53 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_61,code=sm_61 -gencode arch=compute_62,code=sm_62 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_72,code=sm_72 -gencode arch=compute_75,code=sm_75 -gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86 -gencode arch=compute_87,code=sm_87 -gencode arch=compute_87,code=compute_87 -o libptgde.so PTGDE.o CudaColorAdjust.o CudaDEFn.o CudaMotionAdaptive2.o -lopencv_core -lopencv_cudaarithm -lopencv_cudaimgproc -lopencv_imgproc
/usr/bin/ld: PTGDE.o: in function CUDA::resetBuffers(PTGDE_PARAMETER&) [clone .isra.0]': PTGDE.cpp:(.text+0x76c): undefined reference to __stack_chk_fail@GLIBC_2.4’
/usr/bin/ld: PTGDE.o: in function PTGDE_resetBuffers': PTGDE.cpp:(.text+0x84c): undefined reference to memset@GLIBC_2.2.5’
/usr/bin/ld: PTGDE.cpp:(.text+0x8b8): undefined reference to `memset@GLIBC_2.2.5’

For full disclosure:

  • I flashed JP511 onto the microSD, started, and then I cloned, built and installed opencv and contrib 4.5.5.
  • Also, not a Makefile/compile expert, just want to get to a point where I can run our library+app and start analyzing and improve the GPU performance and efficiency for our code.
5

Hi,

Does your app have a dependency on a specific GLIBC version?
Please help to check it.

Thanks.

6

ThX for that response! Looking at our code I did find something that seems to indicate some Glibc “symbol versioning” that I was not aware of. Our code includes an include file with ~3700 statements like this one:

asm(“.symver __stack_chk_fail,__stack_chk_fail@GLIBC_2.4”);

I am assuming this means that our code is requesting to be linked with the 2.4 version of “__stack_chk_fail()”, presumably an older version?

I have no experience with this but I now have something to study.

Next questions:

  • Why does this not happen on a Dell laptop+GPU with regular ubuntu 20.04 running the same code? Except that the cuda tool kit is the newest. Is this an Arm vs x64 issue?
  • Do you have any pointers to any documentation that I can read to learn what I have to do to accomplish this on the Jetson?
  • Is this versioning necessary? Are there functional differences between an older and a newer version of Glibc routines? Such as the one above, or strncpy()? I would think that any version has to behave exactly according to the good old man page?
7

Hi,

1. A possible reason is that the default GLIBC version is different.
Is it possible to get the version of the desktop in the compiling log?

2. Unfortunately we don’t have a doc for this since GLIBC is a third-party library.

3. A common cause is some API change between versions which causes some incompatible errors.
JetPack 5.1.1 is also Ubuntu 20.04. Maybe you can try to upgrade the CUDA lib to 12 to align all the package versions as desktop.

Thanks.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.