Fix: 'wrong ELF class: ELFCLASS64' Loading a Module

You add a Metamod plugin or an AMX Mod X module, restart, and the console prints a line like this before the module fails to load:

dlopen failed: /path/to/module_amxx.so: wrong ELF class: ELFCLASS64

This is not a corrupt file and it is not a bad path. It is an architecture mismatch: GoldSrc HLDS and ReHLDS are 32-bit processes, and a 32-bit process can only dlopen() a 32-bit shared object. The .so you dropped in is a 64-bit build (ELFCLASS64), so the loader rejects it outright. The fix is always the same shape — replace the file with the correct 32-bit build — but you have to find which file is wrong first.

1. Confirm the server itself is 32-bit

Before blaming the module, prove the process it loads into is 32-bit. Run file on the server binary:

file hlds_linux
file engine_i486.so

A stock GoldSrc server reports ELF 32-bit LSB executable, Intel 80386. That is expected and correct — there is no 64-bit HLDS. Everything the engine loads at runtime must match that 32-bit target. This is the same root cause behind 'No such file or directory' on a 64-bit host: the whole stack is i386.

2. Find the offending .so with file

The error message names the exact path that failed — start there. Run file on it:

file addons/amxmodx/modules/mysql_amxx.so

A good module reports ELF 32-bit LSB shared object, Intel 80386. The broken one reports ELF 64-bit LSB shared object, x86-64. That single word — 32-bit vs 64-bit — is the whole diagnosis. If the message did not name a path clearly, scan every module and plugin binary at once:

file addons/amxmodx/modules/*.so addons/metamod/dlls/*.so

Anything that prints x86-64 is the culprit. On a normal install every one of these should say Intel 80386.

3. Replace it with the 32-bit build

Modules ship in both flavours, and the download page or archive almost always contains a separate 32-bit file. AMX Mod X module archives include the correct _amxx.so for GoldSrc; the 64-bit variant in the same package is meant for a 64-bit engine you are not running. Pull the 32-bit .so and overwrite the wrong one:

cp mysql_amxx_i386.so addons/amxmodx/modules/mysql_amxx.so
file addons/amxmodx/modules/mysql_amxx.so   # confirm Intel 80386

If you compiled the module yourself, you built for the host architecture by mistake. Rebuild with a 32-bit toolchain — pass -m32 to the compiler and install the 32-bit development libraries — so the output is ELFCLASS32.

4. Check nothing is dragging in 64-bit system libraries

A module can be 32-bit and still fail if it links against a system library and LD_LIBRARY_PATH points the loader at 64-bit copies first. The same wrong ELF class message then names a system .so (for example a libssl or libmysqlclient) rather than your module. Inspect the environment the server runs under:

echo $LD_LIBRARY_PATH
ldd addons/amxmodx/modules/mysql_amxx.so

ldd lists the shared libraries the module needs and where the loader resolves each one. If a dependency resolves to a path under /usr/lib/x86_64-linux-gnu/, the loader is handing a 32-bit binary a 64-bit library. Install the i386 version of that library (see installing 32-bit libraries) so the correct copy exists under /usr/lib/i386-linux-gnu/, and make sure the server's launch environment does not force the 64-bit path ahead of it.

Common errors

• Message names a system library, not your module — a dependency is being resolved to a 64-bit copy. Install the i386 version and fix LD_LIBRARY_PATH.
• You replaced the file but the error persists — you overwrote the wrong path, or a second copy of the module exists elsewhere in the search path. Re-run the file scan across every .so.
• 'cannot open shared object file: No such file or directory' instead — different problem: the file is missing or a dependency is absent, covered in module failed to load.
• Self-compiled module is always 64-bit — you omitted -m32 or lack the 32-bit dev headers. The build silently targets the host.
• Engine binary itself reports 64-bit — you downloaded the wrong server package entirely; GoldSrc HLDS is 32-bit only. Re-fetch the Linux dedicated server files.

Verification

Run file once more on the file the error named and confirm it now reads ELF 32-bit LSB shared object, Intel 80386. Restart the server and watch the startup log: the module should list as loaded rather than throwing the ELFCLASS64 line. For an AMX Mod X module, confirm it at runtime from the server console:

amxx modules

The module should read running. If every .so in your file scan reports Intel 80386 and the module still will not load, the problem has moved on from architecture to a missing dependency — trace it with ldd as in step 4.