Specific errors:

[cc] In file included from /home/tsit/jogamp232-loongarch64/gluegen/src/junit/com/jogamp/gluegen/test/junit/generation/test1.c:5: [cc] /usr/include/stdlib.h:563:25: note: Expected 'void *' but argument is of type 'const char *' [cc] extern void free (void *__ptr) __THROW; [cc] ~~~~~~^~~~~ [cc] Starting link [cc] /usr/bin/ld: libtest1.so: No symbol version section for versioned symbol 'memcpy@GLIBC_2.0' [cc] /usr/bin/ld: nonrepresentable section on output [cc] collect2: error: ld returned 1 exit statusCopy the code

There are many posts about this kind of mistake. What that means is that there is no function. To be specific:

Tsit @ tsit - loong: ~ / jogamp232 loongarch64 / gluegen $strings/usr/lib/loongarch64 - - the gnu/Linux libc. So. 6 | grep GLIBCGLIBC_2. 27 Glibc_2.28 GLIBC_PRIVATE GNU C Library (Debian GLIBC 2.28-10.lnd.26) stable release version 2.28. sit@tsit-loong:~/jogamp232-loongarch64/gluegen$ objdump -T /usr/lib/loongarch64-linux-gnu/libc.so.6 | fgrep memcpy 000000000008d328 w df.text 0000000000000008 glibc_2.27 wmemcpy 00000000000EEb78 g df.text 000000000000001c glibc_2.27 __wmemcpy_chk 0000000000086588 g df.text 00000000000003f4 glibc_2.27 memcpy 00000000000ed228 g df.text 0000000000000014 GLIBC_2. 27 __memcpy_chkCopy the code
  • Solution 1
G++ -o main main. c-lm-ldl-lrtCopy the code
  • Solution 2
G++ -wl,--no-as-needed -o main main. c-lm-ldl-lrtCopy the code
  • Ultimate solution

Back to the question itself. We normally call the function memcpy, no matter where we call it, and this doesn’t happen. Why is this happening here? It must be the way the code is written. Based on this idea, let’s search GLIBC. Sure enough, we found a file glibc-compat-symbols.h, the content is:

#ifndef __GLIBC_COMPAT_SYMBOLS_H__ #define __GLIBC_COMPAT_SYMBOLS_H__ 1 /** * * Note: Patching a specific glibc symbol version is only required if *not* statically linking glibc, * which should be preferred. * * Note: JogAmp's minimum GLIBC is 2.4 due to '__stack_chk_fail' (stack overflow checking) * * GLIBC 2.4-March 2006 - Standard For LSB 4.0, Used in SLES 10 * * We could add compile/link option '-fno-stack-protector', however stack protection seems reasonable * and a pre 2006 distribution a bit too 'far fetched' for our multimedia bindings anyway. * * Check build-in macro definitions via 'gcc -dM -E - < /dev/null' */ #if defined(__linux__) /* Actually we like to test whether we link against GLIBC .. */ #if defined(__GNUC__) #if defined(__aarch64__) #define GLIBC_COMPAT_SYMBOL(FFF) __asm__(".symver " #FFF "," #FFF "@ GLIBC_2. 4"); # elif defined (__arm__) # define GLIBC_COMPAT_SYMBOL (FFF) __asm__ (". Symver "# FFF", "# FFF" @ GLIBC_2. 4 "); # elif defined (__amd64__) # define GLIBC_COMPAT_SYMBOL (FFF) __asm__ (". Symver "# FFF", "# FFF" @ GLIBC_2. 2.5 "); #else #define GLIBC_COMPAT_SYMBOL(FFF) __asm__(".symver "#FFF "," #FFF" @glibc_2.0"); #endif /*__amd64__*/ #elif defined(__clang__) #if defined(__aarch64__) #define GLIBC_COMPAT_SYMBOL(FFF) asm(".symver " # # FFF ", "FFF" @ GLIBC_2. 4 "); #elif defined(__arm__) #define GLIBC_COMPAT_SYMBOL(FFF) asm(".symver "#FFF "," #FFF" @glibc_2.4 "); #elif defined(__amd64__) #define GLIBC_COMPAT_SYMBOL(FFF) asm(".symver "#FFF "," #FFF" @glibc_2.2.5 "); #else #define GLIBC_COMPAT_SYMBOL(FFF) asm(".symver "#FFF "," #FFF" @glibc_2.0 "); #endif /*__amd64__*/ #else #warning GLIBC_COMPAT_SYMBOL not supported with current compiler on GNU/Linux #define GLIBC_COMPAT_SYMBOL(FFF) #endif #else #warning GLIBC_COMPAT_SYMBOL not supported with target OS #define GLIBC_COMPAT_SYMBOL(FFF) #endif GLIBC_COMPAT_SYMBOL(memcpy) #endif /*__GLIBC_COMPAT_SYMBOLS_H__*/Copy the code

There was a string called glibc_2.0. That should make it easier.

Option 1: Change 2.0 to 2.27 (or the corresponding string).

Method two: simply change to “”. This way, everyone is happy wherever you compile.