I'm trying to develop a plugin for alsa. I compiled my plugin as a shared library and copies it to
/usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_myplug.so
Then I try to test it using arecord and get the following error
arecord --device=my_plug_test blah.pcm
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_myplug.so
arecord: main:682: audio open error: No such device or address
But the file does clearly exist. I'm wondering if there is something about using .so files that i'm overlooking. Anyone have any ideas?
Could be some other dependency not found. Try:
ldd /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_myplug.so
Or, is it possible your system is expecting 32-bit but you compiled 64-bit or vice versa?
Check with:uname -a
Related
After successfully building and compiling sleuthkit library [4.2 version], I tried to write an introspection tool using the library.. Thing is whenever i am trying to compile the program in order to test it and I am using a function from the library API I'm get the following error :
error while loading shared libraries: libtsk.so.13: cannot open shared object file: No such file or directory
I found thought that this file exists in /usr/local/lib folder . Am i missing something ? ./configure && make didn't give me any errors.. and I am including -ltsk on the makefile!
My pc information : XEN hypervisor [Ubuntu 12.04 x64bit] and i am trying to investigate a guest vm running ubuntu 12.04 x32bit
Thanks in advance
I found a solution to the problem , if I install -dev package...
sudo apt-get install libtsk-dev
Also read this useful article... Understood why exactly that happened .
I wanted to start cross compiling for raspberry pi2 on Ubuntu 32bit (in virtual box), so I downloaded the toolchain on the github site (https://github.com/raspberrypi/tools) and tried to compile a simple hello world program with the command (I've included the path to the bin folder that contains arm-linux-gnueabihf-gcc-4.8.3 to the PATH variable.):
arm-linux-gnueabihf-gcc-4.8.3 HelloWorld.c
However, I always get the following error message:
path/to/the/linker/in/the/toolchain/ld:/path/to/the/libc.so.6file/in/the/toolchain/libc.so.6: file format not recognized; treating as linker script
and subsequently a syntax error.
When I look into libc.so.6, I see a single line containing:
libc-2.13.so
The libc-2.13.so file is present in the same folder as the libc.so.6 file. When I invoke
file libc-2.13.so
I get:
libc-2.13.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=dbd0cdca5a677bea1417be1272f4c5ef43bd3e22, for GNU/Linux 2.6.26, stripped
I don't know what could cause this error since obviously the linker from the toolchain and the libc.so.6 file from the toolchain are processed so the file format should be recognized, right?
Can someone point me in the right direction here? Thanks!
I will suggest you alternate way to do Cross compilation. I tried it and it works. You can use crosstool-NG. It gives you graphical way to setup your toolchain for cross compilation. There are lot of option for setting up toolchain. You can explore that.
Now you are doing for ARM-RPi but tomorrow if your Target CPU changed then it will be very easy to reconfigure the toolchain again.
You can find easy steps given in this article. I hope this works for you.
When I look into libc.so.6, I see a single line containing:
libc-2.13.so
I just ran into this.
The problem is way simpler than you think. When you un-gz'd and untar'd the toolchain, what happened is that libc.so.6 became a text file. It is supposed to be a "symbolic link" file pointing at the correct file "libc-2.13.so".
If you are using windows and 7-Zip, make sure to click "Run AS Administrator" when you start 7-zip. If you simply drag and drop, the error is not so obvious.
In my first effort, I had to include the path to gcc in the command. Then I just compiled programs on the RPi.
~/toolchain/raspbian-toolchain-gcc-4.7.2-linux32/bin/arm-linux-gnueabihf-gcc whets.c
I want to create a standalone executable from a C file so that the libraries that I'm using don't have to be installed on the computer that I'm running the executable on.
I'm using the libssh and libconfig libraries, both of which may need to be installed on the machine I'm running the executable on.
When I run my binary on a machine that doesn't have these libraries installed, I get:
error while loading shared libraries: libssh.so.4: cannot open shared object file: No such file or directory
Is there a way I can compile my program.c file so that it has the libssh binaries included within it?
See this Link http://api.libssh.org/master/libssh_linking.html about how to link the static version of the libssh. There must be similar instructions for libconfig.
I would ultimately like to modify and compile the existing Linux USB storage driver and test it. For the first step, I wanted to compile the module as is.
I downloaded the latest Linux kernel (version 3.12) and extracted it to ~/linux-3.12.
I found the driver I wanted to compile: drivers/usb/storage, but when I ran make, I got the following error:
make: *** No targets. Stop.
I found many guides online, but none of them worked for the USB storage driver. All I want is to compile this one module and get the .ko so I can test it out.
NOTE: I'm running Ubuntu 13.04 64-bit, and uname -r outputs 3.8.0-30-generic - I'm not sure if that's the problem, but I managed to compile the whole Kernel before. I don't want to do that now because it takes an eon.
If you wanted to build the drivers/usb/storage module you would do this:
make M=drivers/usb/storage
from the root directory of the kernel tree. Before doing so, you will need to make sure that your configuration is the same as the config of the running kernel.
You can't simply take the source code for one kernel and use it to build modules for another one. The module needs to be built from the same source and with the same configuration as the kernel itself.
Basically, you need to find the source code for the Ubuntu kernel you're running. In Ubuntu, as in Debian, that can be done with 'apt-get source '. The package name is probably something like 'linux-image-3.8-2-amd64'.
Once you have the source code you need to find the configuration of your running kernel. Fortunately Ubuntu keeps that in /boot/config-3.8-....
Copy that config to your kernel source tree as .config and run 'make oldconfig'. Now you should be able to build the module (assuming it's not already built into your kernel!).
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.
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.