I'm trying to use the command:
gcc -I${HOME}/usr/include -L${HOME}/usr/lib -lsodium test.c
but when I try and run a.out it gives the error:
./a.out: error while loading shared libraries: libsodium.so.4: cannot open shared object file: No such file or directory
but libsodium.so.4 is definitely in the ${HOME}/usr/lib directory. What's going on? test.c is just
#include <stdio.h>
#include "sodium.h"
int main(int argc, char** argv)
{ return (0); }
${HOME}/usr/lib is not in your runtime library path.
You can bake the path into your executable using the gcc option -Wl,-rpath,${HOME}/usr/lib or set the environment variable LD_LIBRARY_PATH=${HOME}/usr/lib before executing the program.
ldd a.out will tell you if libsodium can be found in your runtime library path, and if so, the location of the library.
You need to tell the runtime linker where to find the .so. Typically this is done with the LD_LIBRARY_PATH environment variable, so you would invoke a.out like so (assuming you're using a bash-like shell):
LD_LIBRARY_PATH=${HOME}/usr/lib ./a.out
Please
export LD_LIBRARY_PATH=${HOME}/usr/lib
first and try again.
That export ... will tell loader (ld-linux.so) also search ${HOME}/usr/lib for shared libraries.
Related
I have downloaded libgcrypt library source code and
added my own customize function inside one particular file.
Although compilation/build process of customized shared library is successful, and both nm and objdump show
the customized function is global, it nonetheless shows an error (undefined reference) at linking time.
Here is what I have done:
inside /src/visibility.c file, I have added my custom function,
void __attribute__((visibility("default"))) MyFunction(void)
{
printf("This is added just for testing purpose");
}
build process
./configure --prefix=/usr/local --disable-ld-version-script
sudo make install
nm and objdump command find this custom function as global inside shared library.
nm /usr/local/lib/libgcrypt.so | grep MyFunction
000000000000fbf0 T MyFunction
objdump -t /usr/local/lib/libgcrypt.so | grep MyFunction
000000000000fbf0 g F .text 0000000000000013 MyFunction
Here is my sample code to access my custom function.
//gcrypt_example_test.c
#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>
int main()
{
MyFunction();
return 0;
}
export LD_RUN_PATH=/usr/local/lib
gcc gcrypt_example_test.c -o test -lgcrypt
/tmp/ccA0qgAB.o: In function `main':
gcrypt_example_test.c:(.text+0x3a2): undefined reference to `MyFunction'
collect2: error: ld returned 1 exit status
Edit 1:
I tried all possible way to include function prototype declaration inside header file (/src/gcrypt.h) as follows:
void __attribute__((visibility("default"))) MyFunction(void);
... or:
extern void __attribute__((visibility("default"))) MyFunction(void);
... or:
extern void MyFunction(void);
... or:
void MyFunction(void);
I am still getting the same error (undefined reference) although no build error results in all above cases.
Why is this happening, and what mistake am I making?
Although other global functions which are part of standard shared library and defined inside visibility.c (nm also shows T for those functions) are accessible, why is my customized global function (MyFunction) of the shared library still inaccessible? Thanks!
Any link or explanation to resolve this error will be highly appreciable.
From the GCC documentation (emphasis mine):
Some linkers allow you to specify the path to the library by setting LD_RUN_PATH in your environment when linking.
But, from the GNU ld man page:
-rpath=dir
Add a directory to the runtime library search path. This is used
when linking an ELF executable with shared objects. All -rpath
arguments are concatenated and passed to the runtime linker,
which uses them to locate shared objects at runtime. The -rpath
option is also used when locating shared objects which are needed
by shared objects explicitly included in the link; see the
description of the -rpath-link option. If -rpath is not used
when linking an ELF executable, the contents of the environment
variable "LD_RUN_PATH" will be used if it is defined.
Note that there is no mention at all of the link time library search path.
You need to compile/link with /usr/local/lib in the link time library search path:
gcc gcrypt_example_test.c -o test -L/usr/local/lib -lgcrypt
most likely cause of the problem:
The header file for the library has not been updated to include the prototype for the new function
I don't understand the reason behind why it is working now, but not before. Anyway, I found the way to make the code working after adding customized function inside standard library. This post may help others in future.
I first locate libgcrypt.so and then remove all versions of libgcrypt.so
locate libgcrypt.so
sudo rm /usr/local/lib/libgcrypt.so
sudo rm /usr/local/lib/libgcrypt.so.20
sudo rm /usr/local/lib/libgcrypt.so.20.2.2
then I delete the libgcrypt folder (which I had extracted for building library) to start fresh.
Again, I follow these steps
Step 0 : extract libgcrypt source code
Step 1 : add my custom function, inside /src/visibility.c file
void __attribute__((visibility("default"))) MyFunction(void)
{
printf("This is added just for testing purpose");
}
Step 2 : build library
export LD_RUN_PATH=/usr/local/lib
./configure --prefix=/usr/local --disable-ld-version-script
sudo make install
Step 3: Open another terminal to compile
export LD_RUN_PATH=/usr/local/lib
gcc gcrypt_example_test.c -o test -lgcrypt
Step 4 : run
./test
This is added just for testing purpose
This is working fine now as expected.
What I noticed that __attribute__((visibility("default"))) in function definition and --disable-ld-version-script during build process is very important to make the customized function global, elimination of any makes the customized function local inside shared library(.so) file.
Below changes are working at my end
visibility.h
#include <cstdio>
void __attribute__((visibility("default"))) MyFunction(void);
visibility.cpp
#include "visibility.h"
void MyFunction(void)
{
printf("This is added just for testing purpose");
}
library build command
gcc -shared -o libtest.so -Wall -Werror -fpic -I. visibility.cpp
test.cpp
#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>
#include "visibility.h"
extern void MyFunction();
int main()
{
MyFunction();
return 0;
}
exe build command
gcc test.cpp -o test -I. -L. -ltest -lstdc++
My gcc version is 4.4.7
And of-course I did not try and install the lib under /usr/local/lib but kept it local for quick testing.
I have gone through all the solutions on StackOverflow as well as Ask Ubuntu.
I have a Go program:
package main
import "C"
//export Getint
func Getint() int {
return 2
}
func main() {}
and I have generated .so file for the same with name t.so and header filet.h`
Now I would like to use this function in my C program.
I have written the code but I don't know how to execute it.
#include <stdio.h>
#include <t.h>
int main()
{
int a;
a=Getint();
printf("number : %d",a);
return 0;
}
When I execute it with
gcc c.c t.so
it generates a.out file
but at the time of running a.out with ./a.out it gives an error:
./a.out
Error while loading shared libraries: t.so: can not open shared object file: no such file or directory exists.
then I tried with:
gcc -c c.c -l t.so
So it generates c.o file and it is not executable.
You should use the linker option -rpath, which tells the linker to add information in the executable program where to find runtime libraries like your .so file.
This can be done using the GCC option -Wl which instructs the GCC frontend program to pass an option to the linker:
$ gcc c.c t.so -Wl,-rpath=$(pwd)
This will pass -rpath=$(pwd) to the linker, and $(pwd) causes the shell to call the pwd command to return the current directory.
As long as you don't move the library the program should work.
You can use the environment variable LD_LIBRARY_PATH too, but it's not recommended.
Most probably your loader cannot find the library. Try to put the path to the directory where the libarry is located to LD_LIBRARY_PATH prior to run your binary.
export LD_LIBRARY_PATH=/path/to/my/library
./a.out
.so files are shared object, meaning object that are available to all applications that need them.. that is, shared. Due to this characteristics, they need to be stored in a well known place. Also, they need to be indexed by the dynamic linker.
In linux for instance you typically have a file /etc/ld.so.conf where all directories where shared object are automatically read from are stored
So your options are:
Put your shared object file in a well known place
Put your shared object file in a place of your choice and let the dynamic linker know about it: in linux you can modify ld.so.conf and run ldconfig to update ld indexes
As other suggested write the path of your .so in the env variable LD_LIBRARY_PATH (since dynamic linker reads it before running your application). This must be done at each environment creation
As other suggested use -rpath when compiling. Note that in this way you cannot move your .so file after the compilation
Personally I prefer installing the .so file in a system library path
You should use LD_LIBRARY_PATH to let the dynamic linker find your shared library in the list. Syntax is similar to PATH a list of directories separted by :.
On OSX this environment variable is called DYLD_LIBRARY_PATH.
I am trying to use VLFeat library in C, as given on the website
http://www.vlfeat.org/gcc.html.
I downloaded and installed the library. I use the glnxa64 architecture. The library is located at /A/B/C/vlfeat-0.9.18
My code is as follows:
extern "C" {
#include <vl/generic.h>
#include <vl/sift.h>
}
int main (int argc, const char * argv[])
{
VL_PRINT ("Hello world!") ;
return 0;
}
I compile my code using the following statement,
g++ main.cpp -o vlfeat-test -I/A/B/C/vlfeat-0.9.18 -L/A/B/C/vlfeat-0.9.18/bin/glnxa64/ -lvl
But when I run it, I get the following error
./vlfeat-test: error while loading shared libraries: libvl.so: cannot open shared object file: No such file or directory
When your program is loaded, linux loads the necessary libraries.
You need to create a symbolic link in /usr/lib/ to your libvl.so file
sudo ln -s /home/[YourPATH]/vlfeat-0.9.20/bin/[YourArchitecture]/libvl.so /usr/lib/libvl.so
Before running your test, in the same console:
export LD_LIBRARY_PATH=/A/B/C/vlfeat-0.9.18/bin/glnxa64:$LD_LIBRARY_PATH
then
./vlfeat-test
I think the problem is when your program load. Linux doesn't know where your vl library is.
copy libvl.so to /usr/lib
sudo cp [VLFEAT_PATH]/bin/[YOUR_ARCHITECTURE]/libvl.so /usr/lib
[This worked for same problem when using the .mex files through MATLAB in Ubuntu].
You may need to update the links and cache to the recent shared libraries by running
sudo ldconfig
You can permanently add the library path /A/B/C/vlfeat-0.9.18/bin/glnxa64 or a custom directory with your (links to) shared libraries, e.g., /home/username/lib in the ldconfig files:
sudo vim /etc/ld.so.conf
to add the line(s)
/A/B/C/vlfeat-0.9.18/bin/glnxa64
Verify by running
ldconfig -v | grep libvl.so
I downloaded a library from here. I added the header file in my program but when I try to access the functions of this header file, I get error:
undefined reference to the function for u_open() and u_accept(). I tried to compile the .c files of this header file but I get this error:
undefined reference to main.
I tried everything in my knowledge to solve this issue, but couldn't solve it. Here is the program.
#include "uici.h"
int main()
{
char client[50];
char buf[1024];
u_port_t portnumber;
portnumber=48625;
int fd = u_open(portnumber);
int communFd = u_accept(fd,client,50);
perror("Opened");
fprintf(stderr,"\nComun fd is %d\n\n\n",communFd);
read(communFd,buf,1024);
write(STDOUT_FILENO,buf,1024);
fprintf(stderr,"\n\nReading complete\n");
return 0;
}
What can I do to solve this problem?
Regards
Your header file uici.h declares the functions you're calling in main() (u_open() and u_accept()), but not their implementations, which are in the source files. When the linker tries to create the entire program, it then complains that the implementations can't be found.
The solution is to link all the files together when creating the actual program binary. When using the g++ frontend, you can do this by specifying all the source files together on the command line. For example:
g++ -o main main.c uici.c
will create the main program called "main", assuming that the implementations you need are in uici.c.
edit: In the case you're linking against a prebuilt library for uici, you'll need to specify to the frontend that the library is needed for linking, e.g. with:
g++ -o main main.c -luici
You need to link the library when using gcc like :
gcc nameofprgram.c -l<library>
Use any of these flags while compiling with gcc
-I <searchpath to include files>
-L <searchpath to the lib file>
-l<thelibname>
Ex:
gcc -o myprogram -lfoo -L/home/me/foo/lib myprogram.c
This will link myprogram with the static library libfoo.a in the folder /home/me/foo/lib
I was reading Introduction to GCC and it says if a package has both .a and .so. gcc prefer the shared library. By default the loader searches for shared libraries only in a predefined set of system directories, such as /usr/local/lib and /usr/lib. If the library is not located in one of these directories it must be added to the load path, or you need to use -static option to force it to use the .a library. However, I tried the following:
vim hello.c:
#include <gmp.h>
#include <stdio.h>
int main() {
mpz_t x;
mpz_init(x);
return 0;
}
gcc hello.c -I/opt/include -L/opt/lib -lgmp (my gmp library is in opt)
./a.out
And it runs. The book says it should have the following error:
./a.out: error while loading shared libraries:
libgdbm.so.3: cannot open shared object file:
No such file or directory
(well, the book uses GDBM as example but I used GMP, but this won't matter right?)
However, I did not set LD_LIBRARY_PATH=/opt/lib, and as you can see I did not use -static option either, but a.out still runs.
Can you all tell me why and show me how to get the error described in the book? Yes I want the error so I will understand what I misunderstood.
From your response to my comment:
linux-gate.so.1 => (0xb7746000)
libgmp.so.10 => /usr/lib/i386-linux-gnu/libgmp.so.10 (0xb76c5000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7520000)
/lib/ld-linux.so.2 (0xb7747000)
So, your program is picking up the lib from /usr/lib.
What you can try to do is rename the lib in your /opt/lib, and link against the new name.
mv /opt/lib/libgmp.so /opt/lib/libgmp-test.so
gcc hello.c -I/opt/include -L/opt/lib -lgmp-test
Then try running the program. Also, compare the result of ldd against the new a.out against what you got before.