Ld linux wrong elf class elfclass64

Arch Linux

You are not logged in.

#1 2012-11-08 12:36:38

[solved] xdebug — wrong ELF class: ELFCLASS64

Hi! I’m trying to run xdebug on my x64 arch, but without success. I’ve installed it and now when I try to run lampp it says:

I did some search and found that I need to download xdebug again, compile it for x64 and move the xdebug.so file to my folder in lampp.
http://www.designified.com/blog/article … n-os-x-105
http://stackoverflow.com/questions/1242 … ss64-error

I’ve tried to compile it with these parameters:

But I’ve got this problem:

Here’s the config.log file:

I’ve been searching for solution for couple of hours, found some similar topics (like this), but it didn’t help. Thanks for suggestions and advices.

Last edited by micer (2012-11-11 15:25:50)

#2 2012-11-08 16:34:33

Re: [solved] xdebug — wrong ELF class: ELFCLASS64

AFAIK, wrong ELF class means that you are trying to use a 32-bit library with a 64-bit program or vice versa. You might try installing the offending library from the multilib repository to get both versions. If you still get the error, then there are some symbolic link(s) that need to be created so that the program can find the correct library and file.

#3 2012-11-08 16:49:12

Re: [solved] xdebug — wrong ELF class: ELFCLASS64

AFAIK, wrong ELF class means that you are trying to use a 32-bit library with a 64-bit program or vice versa. You might try installing the offending library from the multilib repository to get both versions. If you still get the error, then there are some symbolic link(s) that need to be created so that the program can find the correct library and file.

Источник

Linking Fails With «Wrong ELF Class: ELFCLASS64» or «Wrong ELF Class: ELFCLASS32» (Doc ID 1525411.1)

Last updated on OCTOBER 28, 2020

Applies to:

Symptoms

An ELFCLASS32 or ELFCLASS64 error message from ld.so.1 is observed.

Example scenarios where such a message can be observed

• when using a compiler to compile and link a library or executable
• when directly calling the linker (ld), or ar
• when using tools that process binaries and/or shared libraries, such as ldd
• when trying to start an application
• when trying to load a shared library into an application, for example via dlopen()
• when trying to use a 32-bit plugin in a 64-bit application, and when trying to use a 64-bit plugin in a 32-bit application

This example demonstrates a user error — the 64-bit version of mdb is used, but the 32-bit version of libumem is preloaded.

This example also demonstrates a user error: the -m64 option is used inconsistently. First, a 64-bit object file is created. It is then attempted to link this object file into a 32-bit executable.

A 32-bit application is linked against 64-bit Oracle 11g Database client libraries.

This problem occurs because the Oracle 11g Database by default does not ship 32-bit client libraries.

Cause

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

Symptoms

Example scenarios where such a message can be observed

Cause

Solution

Steps if the Problem is Observed During Application Startup

Steps if the Problem Is Observed While Compiling or Linking

Additional Information for Users of the Template Repository

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Oracle offers a comprehensive and fully integrated stack of cloud applications and platform services. For more information about Oracle (NYSE:ORCL), visit oracle.com. пїЅ Oracle | Contact and Chat | Support | Communities | Connect with us | | | | Legal Notices | Terms of Use

Источник

PlayOnLinux: wrong ELF class: ELFCLASS64 #92

Comments

fragsalat commented Jan 2, 2019

Describe the bug
My goal was to run League of Legends on Linux Mint 19.1 Cinnamon via PlayOnLinux + Wine 3.21-staging. The default install script of play on linux uses winxp + x86 arch as wine base but I also tried amd64 as the error (in my eyes) sais it needs x32 lib.
During startup the following error happens

To Reproduce

1. Linux Mint 19.1 Cinnamon + PlayOnLinux 4.x
2. Install gamemode from git (1.2 or master) (will be installed into /usr/lib/x86_64-linux-gnu)
3. Run POL LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgamemodeauto.so.0 playonlinux
4. The error mentioned above will appear

Expected behavior
I would not see any error and game mode would work properly.

System Info (please complete the following information):

• Linux Mint 19.1
• GameMode 1.2 or master

Additional context
If using gimp instead of playonlinux it works.

The text was updated successfully, but these errors were encountered:

fragsalat commented Jan 2, 2019

I just tested it with a steam game from CLI and got the same error

Vthyarilops commented Jan 2, 2019

That’s not how you are supposed to preload it, go to the game launcher in POL, click Configure, add

to «Command to exec before running this program», close this, not an issue

fragsalat commented Jan 3, 2019 •

@Vthyarilops First of all, thx for pointing out where to place it.
Second thing is that the error is the same and as I wrote indipendent of playonlinux.

And third point is that $LIB doesn’t exist on Linux Mint and I had to write the path directly, which is as I think not the problem.

Vthyarilops commented Jan 3, 2019

Sorry I jumped on this to quickly, I just tested a 32 bit prefix on Mint 18.1 and it had the same error. I guess gamemode is 64 bit only, honestly not sure.

ikeyd commented Jan 7, 2019

You’d need it built for 32-bit and 64-bit, and make use of the $LIB variable (ld.so) in LD_PRELOAD to ensure the correct build is preloaded

fragsalat commented Jan 11, 2019

Ok I’ll search how to do this and try it 🙂
I’ll come back with results 🙂

fragsalat commented Jan 14, 2019

@ikeyd I successfully built the gamemode on my 64bit Linux Mint with 32bit but that result in almost the same error.

Using \$LIB env variable (which doesn’t exist) results in this error

Using library built for 32bit with static path

Using library built for 64bit with static path

carlinux commented May 5, 2019

Same problem here. Did you got it working @fragsalat ? I tried everything and it still says Wrong ELF: Class no matter what

aejsmith commented May 7, 2019

I’m unsure exactly how PlayOnLinux works, but it may be that it ends up running a mix of 32-bit and 64-bit processes. Setting LD_PRELOAD will attempt to load that library into any process, and it will only succeed for processes that match the bit-ness of the library set in LD_PRELOAD. Any others will error.

Using this (note the slash before $LIB is needed):
LD_PRELOAD=»/usr/\$LIB/libgamemodeauto.so.0″
should make ld.so pick the appropriate 32- or 64-bit library path for each process.

If that doesn’t work, as long as the library path you’re using for preload is the right one for whether the game itself is 32- or 64-bit, things should still work. You can check that GameMode is active while you have the game running with:
systemctl —user status gamemoded
See the «Status» line, it should tell you whether or not it’s active.

carlinux commented May 7, 2019

That would explain the errors. So apparently is working as intended and the errors are from 32bit processes other than the main ones. It would be good to know what processes get gamemoded then

aejsmith commented May 7, 2019

gamemoded logs when processes make requests and when they exit. You can use something like this to show the log and watch what happens when you run a game: journalctl —user —unit=gamemoded —follow

mauro-miatello commented Aug 18, 2019 •

I’m trying to use with Lutris, same error
journalctl give me this log:

mdiluz commented Aug 23, 2019

@mmiat that log appears to show things working, mostly. The error you’re seeing is likely benign

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Wrong ELF class with both 32 and 64bits lib

I am trying to solve a challenge by using LD_PRELOAD to load my own strcmp library.
I first tried to compile my library with gcc -shared -fPIC strcmp.c -o strcmp.so , but when I tried to execute my file with LD_PRELOAD=/path/to/lib/strcmp.so ltrace ./exec , I had a the error :

By comparing file /path/to/strcmp.so and file exec , I found out that my exec file was a ELF 32-bit LSB executable and that my lib was a ELF 64-bit LSB shared object.

Then I tried to compile my lib with gcc -m32 -shared -fPIC strcmp.c -o strcmp.so , but when executing I have the same error (but this time with ELFCLASS32) :

Any suggestions? How can I have the same error with both 32 and 64 bits version of my lib?

2 Answers 2

As you noticed, if you have a single 32-bit shared library, you will get that warning when 64-bit programs are run. If you have a single 64-bit library, you get that warning when you run 32-binaries. We need your system to have both 32- and 64-bit versions of your libraries, and to allow the system to choose which one to use as needed. You can accomplish that with the following changes:

• Compile both a 32-bit and 64-bit version of your library, and put them in /usr/lib and /usr/lib64 respectively on RedHat-based systems. Debian uses a different library naming scheme which unfortunately is not very consistent, so I’ll leave it an exercise for the reader to determine the right place to put the two libraries on Debian systems.
• Change your preload to remove all paths, like so: export LD_PRELOAD=strcmp.so This will allow the system to search only the correct library directory when it looks for a 32-bit or 64-bit library.
• If you want to patch only one architecture, say 32-bit, then compile a 32-bit version of your library, and then compile an empty file into a 64-bit shared library of the same name. Place them both as described above.

Note that this only works if you use the system library directories. Even /usr/local/lib and /usr/local/lib64 are not allowed.

Источник

Wrong ELF class: ELFCLASS64 #789

Comments

suptec19 commented Jan 21, 2019

I compiled Open3D in Raspbian (Raspberry Pi3 B+), spending some time to make sure that all the required libraries were correctly intalled. Once finished the compilation, I installed the library in the system. After that I installed the python library, as discribed in the guide. Everything went well and without errors.
I started python3 and to test the library I imported it, but at that point I received the following error:

>>> import open3d Traceback (most recent call last): File » «, line 1, in File «/home/pi/.local/lib/python3.5/site-packages/open3d/__init__.py», line 9, in from open3d.linux import * File «/home/pi/.local/lib/python3.5/site-packages/open3d/linux/__init__.py», line 7, in globals().update(importlib.import_module(‘open3d.linux.open3d’).__dict__) File «/usr/lib/python3.5/importlib/__init__.py», line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) ImportError: /home/pi/.local/lib/python3.5/site-packages/open3d/linux/open3d.so: wrong ELF class: ELFCLASS64

It seems that the library is for 64bit only, and infact in the directory

/.local/lib/python3.5/site-packages/open3d/linux there are these libs:
open3d.cpython-36m-x86_64-linux-gnu.so
open3d.cpython-35m-x86_64-linux-gnu.so
open3d.so

May be Raspbian dosn’t have the right OpenGL drivers?

The text was updated successfully, but these errors were encountered:

Источник