---
title: "Fix: 'wrong ELF class: ELFCLASS64' Loading a Module"
excerpt: "Why HLDS refuses a 64-bit .so with 'wrong ELF class: ELFCLASS64', how to find the offending file with the file command, and how to get the 32-bit build it actually needs."
category: "errors"
tags: "linux, 32-bit"
image: ""
read_time: "8 min read"
---
<p>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:</p><pre>dlopen failed: /path/to/module_amxx.so: wrong ELF class: ELFCLASS64</pre><p>This is not a corrupt file and it is not a bad path. It is an architecture mismatch: GoldSrc <strong>HLDS and ReHLDS are 32-bit processes</strong>, and a 32-bit process can only <code>dlopen()</code> a 32-bit shared object. The <code>.so</code> 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.</p><h2>1. Confirm the server itself is 32-bit</h2><p>Before blaming the module, prove the process it loads into is 32-bit. Run <code>file</code> on the server binary:</p><pre>file hlds_linux
file engine_i486.so</pre><p>A stock GoldSrc server reports <code>ELF 32-bit LSB executable, Intel 80386</code>. 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 <a href="/tutorials/fix-hlds-no-such-file-32bit">'No such file or directory' on a 64-bit host</a>: the whole stack is i386.</p><h2>2. Find the offending .so with file</h2><p>The error message names the exact path that failed — start there. Run <code>file</code> on it:</p><pre>file addons/amxmodx/modules/mysql_amxx.so</pre><p>A good module reports <code>ELF 32-bit LSB shared object, Intel 80386</code>. The broken one reports <code>ELF 64-bit LSB shared object, x86-64</code>. 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:</p><pre>file addons/amxmodx/modules/*.so addons/metamod/dlls/*.so</pre><p>Anything that prints <code>x86-64</code> is the culprit. On a normal install every one of these should say <code>Intel 80386</code>.</p><h2>3. Replace it with the 32-bit build</h2><p>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 <code>_amxx.so</code> 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 <code>.so</code> and overwrite the wrong one:</p><pre>cp mysql_amxx_i386.so addons/amxmodx/modules/mysql_amxx.so
file addons/amxmodx/modules/mysql_amxx.so # confirm Intel 80386</pre><p>If you compiled the module yourself, you built for the host architecture by mistake. Rebuild with a 32-bit toolchain — pass <code>-m32</code> to the compiler and install the 32-bit development libraries — so the output is ELFCLASS32.</p><h2>4. Check nothing is dragging in 64-bit system libraries</h2><p>A module can be 32-bit and still fail if it links against a system library and <code>LD_LIBRARY_PATH</code> points the loader at 64-bit copies first. The same <code>wrong ELF class</code> message then names a system <code>.so</code> (for example a <code>libssl</code> or <code>libmysqlclient</code>) rather than your module. Inspect the environment the server runs under:</p><pre>echo $LD_LIBRARY_PATH
ldd addons/amxmodx/modules/mysql_amxx.so</pre><p><code>ldd</code> lists the shared libraries the module needs and where the loader resolves each one. If a dependency resolves to a path under <code>/usr/lib/x86_64-linux-gnu/</code>, the loader is handing a 32-bit binary a 64-bit library. Install the i386 version of that library (see <a href="/tutorials/install-32bit-libraries-cs16-linux">installing 32-bit libraries</a>) so the correct copy exists under <code>/usr/lib/i386-linux-gnu/</code>, and make sure the server's launch environment does not force the 64-bit path ahead of it.</p><h2>Common errors</h2><ul><li><strong>Message names a system library, not your module</strong> — a dependency is being resolved to a 64-bit copy. Install the i386 version and fix <code>LD_LIBRARY_PATH</code>.</li><li><strong>You replaced the file but the error persists</strong> — you overwrote the wrong path, or a second copy of the module exists elsewhere in the search path. Re-run the <code>file</code> scan across every <code>.so</code>.</li><li><strong>'cannot open shared object file: No such file or directory' instead</strong> — different problem: the file is missing or a dependency is absent, covered in <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>.</li><li><strong>Self-compiled module is always 64-bit</strong> — you omitted <code>-m32</code> or lack the 32-bit dev headers. The build silently targets the host.</li><li><strong>Engine binary itself reports 64-bit</strong> — you downloaded the wrong server package entirely; GoldSrc HLDS is 32-bit only. Re-fetch the Linux dedicated server files.</li></ul><h2>Verification</h2><p>Run <code>file</code> once more on the file the error named and confirm it now reads <code>ELF 32-bit LSB shared object, Intel 80386</code>. Restart the server and watch the startup log: the module should list as loaded rather than throwing the <code>ELFCLASS64</code> line. For an AMX Mod X module, confirm it at runtime from the server console:</p><pre>amxx modules</pre><p>The module should read <code>running</code>. If every <code>.so</code> in your <code>file</code> 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 <code>ldd</code> as in step 4.</p>
