CODEWITHSUNDEEP
armcross-compiling
pBlack
pBlack

Reputation: 102

UNIX: Cannot find file or directory after cross-compiling a binary that uses shared object files

I am able to successfully cross-compile a binary file that can run on an ARM system such as Rasberry Pi. Without linking to a third-party library, normal C++ code runs on the device successfully (I.E. cout << "Hello World!" << endl;).

The issue I'm running into is that when I run the executable after it's been linked against a third-party library, I get the standard UNIX error "No such file or directory." when the binary tries to access the shared object file. I have the file it's looking for copied into the usr/lib folder, the usr/local/lib folder, and the folder where the executable is sitting itself.

Also, I went and added a good value to LD_LIBRARY_PATH so the runtime linker can search at these locations. My guess is that the "system" maybe hiding these files from the executable?

And to add more information, I ran the readelf command on the binary and the shared object file and it gives me the proper descriptions of the file. It tells me that the binary file is a 32-bit file and requires this shared object library file that I mentioned it cannot find. Even during link time in the build phase, I add the following linker command -Wl,-rpath, to set the location of where to look for the shared object file. Please note I'm compiling on a Macintosh Machine, and not on the Rasberry Pi itself. Hence cross-compiling.

I have a feeling it's a setting, because the object file is visible/valid in multiple locations. If anyone has experienced this before, please any advice is appreciated. Thanks in advance.

Upvotes: 1

Views: 372

Answers (1)

pBlack
pBlack

Reputation: 102

I actually figured out the problem recently.

The problem was that I was using Eclipse. The third party library files I was using were named in the format "libSHAREDFILENAME.so". Eclipse doesn't like that very much when setting up which libraries to use in the IDE. It expects you to strip off the "lib" and the ".so" portion from the file name. So a file named "libSHAREDOBJECT.so" should be referenced as "SHAREDOBJECT" in Eclipse. It doesn't like the "lib" prefix or the ".so" suffix.

Upvotes: 1

Related Questions