I'm trying to play an mp3 file in terminal using C and I followed this link to do so.
I've installed the two libraries libmpg123 and libao. Also, I've compiled the play.c program using the command:
gcc -O2 -o play play.c -lmpg123 -lao
But I get the following error when I run it:
./play: error while loading shared libraries: libao.so.4: cannot open shared object file: No such file or directory
Can you figure it out why it happened.
The executable can be linked, but at run-time, it cannot find the shared libraries. Add the libraries to your LD_LIBRARY_PATH so the program can find them at run time.
Related
I am using gcc 8.1.0 on Windows. To install it I set up Code::Blocks on my computer and updated the environment variable list by adding the path to the gcc.exe program within the installation folder of CodeBlocks. The file editor I used was the built-in editor in Visual Studio. The terminal to compile was the power shell from Visual Studio as well.
In the library development folder I have the files mul.c and mul.h. Their content is irrelevant.
To compile the library I use the command:
gcc -c mul.c
When I run it, it creates a file object mul.o and not mul.lib. I needed to use the option -o mul.lib to successfully create the desired extension file. After placing the header, the .lib file and the main.c in the same parent folder I am obvioudly able to build the executable by running.
gcc main.c -I./include -L/static -lmul -o my_program.exe
I have two questions:
Why does gcc produces a .o if I am in a Windows environment?
I followed a tutorial that compile the static library under Linux and it names it libmul.o, in this way the -lmul option is able to retrieve the library. But if I call my generated static library libul.lib it generates the error:
C:/Program Files/CodeBlocks/MinGW/bin/../lib/gcc/x86_64-w64-ingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmul
collect2.exe: error: ld returned 1 exit status
Are these a normal behaviours by gcc, or is it side effect of making gcc available just by updating the Windows environmental variables list?
Thank you to the community in advance.
GCC comes from the *nix world where libraries have the .a extension. When using GCC+MinGW this remains the case.
Shared libraries in MinGW are .dll files but their libraries for linking are .dll.a files.
The advantage of .a files is that a lot of sources build out of the box on Windows with MinGW, especially when using MSYS2 shell.
If you use -l it will look for .a (or .dll.a for shared build) file adding the lib prefix and the extension automatically.
So -lmul will look for libmul.a (static, e.g. when --static linker flag is given) or libmul.dll.a (shared).
By the way, you are using quite an old GCC 8.1.0.
As I write this current version is 12.2.0. Check https://winlibs.com/ for a standalone download (instructions on how to configure in Code::Blocks are on the site) or use MSYS2's package manager pacman.
I'm trying to open a dynamic library file (.so) using dlopen().
So I created libhello.so file in Linux using gcc and compiled the main.c file with --preload-file libhello.so option.
However, I got the following error in a browser:
(index):29 To use dlopen, you need to use Emscripten's linking support, see https://github.com/emscripten-core/emscripten/wiki/Linking
Should I compile .so file using emcc instead of gcc in order to be used in a web browser?
reference: https://emscripten.org/docs/porting/files/packaging_files.html#preloading-files
So I have source code written in C for the LibIdn2 library. I am looking to port it into C# but running in to some issues along the way and would appreciate some help.
Installed Cygwin along with Make and GCC G++ packages
Successfully able to run the./configure command on the source directory
After this, running the "make" command produces an .exe file.
I have been trying to get a .dll file created but cannot seem to do so using gcc compiler. The command I am running is:
gcc -shared -o idn2.dll src/idn2.c
but it complains that it cant find the header files referenced in the idn2.c source file.
I have checked that in the idn2.h file, dll_Export is defined.
Any ideas how should I proceed? I need to get a dll.
I use
gcc -o mongotest mongotest.c $(pkg-config --cflags --libs libmongoc-1.0)
for compilation mongodb c driver code, and then
LD_LIBRARY_PATH=/usr/local/lib ./mongotest
for run.
If I try without LD_LIBRARY_PATH=/usr/local/lib I have
./mongotest: error while loading shared libraries: libmongoc-1.0.so.0: cannot open shared object file: No such file or directory
How can I run program without LD_LIBRARY_PATH=/usr/local/lib,
Is it correct to do so? How can I debug mongodb c driver programs?
The path /usr/local/lib should be in /etc/ld.so.conf or in one of the files in /etc/ld.so.conf.d/ directory. So the library mongoc will get into the cache when you issue command ldconfig as root.
You can check if library mongoc is in dynamic linker cache by executing this command
ldconfig -p | grep mongoc
If it is you are safe to run your program without explicitly specifying LD_LIBRARY_PATH.
Other way to check if your executable is correctly linked is by getting the linking information with ldd command. It will print all linked libraries.
ldd mongotest
If you can see /usr/local/lib/libmongoc.so.[numbers] that means it is linked with mongoc library.
I want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.