SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
FixMyError.net
C++ New Added 10 September 2026

C++: relocation R_X86_64_32S can not be used when making a shared object

A shared library must be loadable at any address, so every object in it needs position independent code. The object triggering this is nearly always from a static library built without -fPIC and then linked into a .so, which is why the advice to recompile applies to that dependency rather than to the file being built.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Which object is at fault: the linker names it just before the advice
make 2>&1 | grep -B3 'recompile with -fPIC'

# Confirm a static library lacks PIC
readelf --relocs libfoo.a | grep -c R_X86_64_32S

# Rebuild the dependency with PIC and relink
make CFLAGS='-fPIC -O2' CXXFLAGS='-fPIC -O2'
./configure --with-pic && make

# CMake: set it on the target, or globally for the build
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE ON)
cmake -S . -B build -DCMAKE_POSITION_INDEPENDENT_CODE=ON

# Distributions ship a PIC variant for exactly this reason: prefer it
apt-file search libfoo_pic.a

# Building an executable instead of a library also removes the constraint

How to diagnose C++ errors

C++ errors fall into two very different worlds. Compile and link errors (undefined reference, multiple definition, template substitution failure) are deterministic and are almost always about declarations, the One Definition Rule, or link order. Runtime memory errors (segfaults, double free, use-after-free) are non-deterministic and should never be debugged by reading code alone; a sanitizer will find in seconds what code review misses for days.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Rebuild with sanitizers before anything else: -fsanitize=address,undefined -fno-omit-frame-pointer -g. AddressSanitizer reports the exact allocation and free sites for use-after-free and double-free.
  2. For undefined-reference errors, check link order, remembering that with GNU ld libraries must come after the objects that use them, and check for a C/C++ linkage mismatch that needs extern "C".
  3. Use nm -C libfoo.a | grep symbol to confirm the symbol is actually present and to see the demangled signature. A signature that differs by a const is a different symbol.
  4. Enable core dumps (ulimit -c unlimited) and open them in gdb with gdb ./binary core, then bt full. A stack trace beats speculation.
  5. For template errors, read the message from the bottom up. The final line is usually the real constraint that failed; everything above is instantiation context.

Tools worth reaching for

  • -fsanitize=address,undefined
  • valgrind
  • gdb / lldb
  • nm -C
  • ldd

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

gcc.gnu.org

Related C++ errors

See all 11 C++ errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.