In a directory I have a C file and its header
/home/test/c_pro
f.c
f.h
libf.so
I have compiled the f.c into a dll called libf.so using the following command
gcc -c -fPIC f.c -o f.o
gcc f.o -shared -o f.so
I want to use this in my Rust project.
So in Rust project I have a build.rs
println!("cargo:rustc-link-search=/home/test/c_pro");
println!("cargo:rustc-link-lib=dylib=f")
When I run a cargo build the build fails with the following errors
/home/test/c_pro/f.so: undefined reference to `EC_KEY_new_by_curve_name'
collect2: error: ld returned 1 exit status
In my f.c I do some imports from openssl
#include <openssl/bio.h>
#include <openssl/bn.h>
#include <openssl/ecdsa.h>
#include <openssl/obj_mac.h>
and use symbols from these libraries.
Any ideas as to why the build fails? I am following the official doc and am relying on 2 build parameters
cargo:rustc-link-search so that cargo can know that he has to do a look up in this directory as well.
cargo:rustc-link-lib=dylib to tell what dynamic library to link to.
What am I missing here folks?
Thanks in advance.
EDIT+UPDATE:
I did as pointed out by #Uli Schlachter and it compiles but I get a runtime error stating that libf.so is not found.
ldd ./target/debug/test_f
libf.so => not found.
Any ideas?
Compile your shared object with
gcc -c -fPIC f.c -o f.o
gcc f.o -shared -o f.so -lssl
Let's say we have a library libutils which implements two functions: function1 and function2. And let's say function2 uses library libanother (so libutils depends on libanother).
Now I want to build my application that uses function1 only:
g++ myapplication.cpp -o my application -lutils
Is it required to include libanother in linkage:
g++ myapplication.cpp -o my application -lutils -lanother
Is there any linker requirements concerning that? Does the answer depend on whether the libraries libutils and libanother are shared or static?
Some first principles
Three kinds of files can be input to the linkage of a program:
object files
static libraries
shared libraries
But only two of those kinds of files can actually be linked into the program:
object files and shared libraries.1
If you input any object file p.o to the linkage of a program the linker
links it into the program unconditionally.
If you input a static library libx.a to the your linkage, the linker extracts from libx.a each archive member
libx.a(q.o) that it needs to carry on the linkage and links it into
the program. An archive member libx.a(q.o) is needed if it defines at least one
symbol that has been referenced, but not yet defined, in some file (object file or
shared library) that has already been linked into the program.
If you input a shared library liby.so, the story forks:-
If the linker (ld) option --as-needed is in effect when liby.so is reached,
then liby.so will be linked into the program if it is needed in the same sense as an archive member libx.a(q.o).
If --as-needed is not in effect, then liby.so is linked unconditionally, like
an object file.
If you invoke the linker via one of your distro's GCC frontends (gcc, g++, gfortran...) in the usual
way, then you will always get the --as-needed behaviour for shared libraries by default, or always not get it, as long as your
GCC toolchain remains the same, because your distro's build of GCC will configure --as-needed
as a default linkage option, or not, according to that distro's appraisal of the pros and cons of doing so.
Debian-derived distros (Ubuntu et al.) have defaulted to --as-needed in recent years. Last time I looked,
Redhat-derived distros (Fedora et al.) did not.2
When any file file.{o|so} is linked into the program it introduces 0 or more unresolved references into the program. Those unresolved references are
references to symbols in file.{o|so} that are not defined in file.{o|so} or in any other file already linked into the program.
The linker must resolve all references by the time it has finished the linkage of the
program, or the linkage fails with unresolved reference errors. Files must be input and linked that provide definitions for
all of the symbols that are referenced in the files that are linked.
Down to your case
When you say:
my application ... uses function1 only
you mean that some file will be linked that references function1. It's simple
to assume this file is some object file that will be linked unconditionally,
say the one that defines main, e.g.
main.c
#include <stdio.h>
extern void function1(void);
void call_function1(void) {
function1();
}
int main(void)
{
puts("Hello World!");
}
which we compile to an object file:
$ gcc -Wall -c main.c
Notice that main.o references function1 despite the fact that we cannot
run a program with that main function in any way that will call
function1. main.o defines a function,
call_function1, that calls function1; so function1 is referenced in main.o.
call_function1 is not referenced itself, but function1 is. If we look at
the symbol table of main.o:
$ nm main.o
0000000000000000 T call_function1
U function1
U _GLOBAL_OFFSET_TABLE_
000000000000000c T main
U puts
the symbols annotated T are defined. The ones annotated U are referenced
but not defined. So when we try to link main.o into a program:
$ gcc -o prog main.o
/usr/bin/ld: main.o: in function `call_function1':
main.c:(.text+0x5): undefined reference to `function1'
collect2: error: ld returned 1 exit status
we need to input a file that defines function1, even though a program linked
with this main.o cannot possibly call function1.
Your function1 is defined, somehow, within a library libutils, which also
defines function2. Your program does not reference function2, but
the definition of function2 references one or more symbols, say function3, that are defined,
somehow, within another library libanother.
Do you need to add libanother, as well as libutils to the linkage of your
program?
From first principles, we know you must add libanother to your linkage if you link a file that references function3.
function3 is referenced in the definition of function2. So you must link with libanother
if you link a file that contains the definition of function2.
Do you need to link such a file?
That depends on the implementation of libutils itself.
Case 1
Suppose you have implemented libutils as a static library in which you have
archived an object file that defines function1 and another object file that
defines function2. Like so:
function1.c
#include <stdio.h>
void function1(void)
{
puts(__func__);
}
function2.c
extern void function3();
void function2(void)
{
function3();
}
Compile the source files:
$ gcc -Wall -c function1.c function2.c
Archive the object files:
$ ar rcs libutils.a function1.o function2.o
Link prog like:
$ gcc -o prog main.o libutils.a
No problem. Run:
$ ./prog
Hello World!
Let's do the linkage again, this time with diagnostics to show what
object files and shared libraries were actually linked:
$ gcc -o prog main.o libutils.a -Wl,-trace
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o
main.o
(libutils.a)function1.o
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6 (//lib/x86_64-linux-gnu/libc.so.6)
(//usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
Most of those inputs are boilerplate object files and shared libraries that
gcc adds to program linkage by default. The files that we built are just:
main.o
(libutils.a)function1.o
The archive member libutils.a(function2.o) wasn't linked at all, because
no file was linked that references function2. So it doesn't matter that
libutils.a(function2.o) makes an undefined reference to function3. libutils.a(function2.o)
might as well not exist. The linkage:
$ gcc -o prog main.o libutils.a
is exactly the same linkage as:
gcc -o prog main.o function1.o
Case 2
Suppose you've implemented libutils as a static library that contains
one object file that defines both function1 and function2:
function12.c
#include <stdio.h>
void function1(void)
{
puts(__func__);
}
extern void function3(void);
void function2(void)
{
function3();
}
Compile that file:
$ gcc -Wall -c function12.c
Recreate libutils.a:
$ rm libutils.a
$ ar rcs libutils.a function12.o
Relink prog:
$ gcc -o prog main.o libutils.a -Wl,-trace
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o
main.o
(libutils.a)function12.o
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6 (//lib/x86_64-linux-gnu/libc.so.6)
(//usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: libutils.a(function12.o): in function `function2':
function12.c:(.text+0x32): undefined reference to `function3'
/usr/bin/ld: link errors found, deleting executable `prog'
collect2: error: ld returned 1 exit status
This time, as the -trace output shows, our object files:
main.o
(libutils.a)function12.o
were linked. main.o referenced function1, so the linker searched libutils.a
for an object file that defines function1. It found function12.o and linked
it, including the definition of function2 as well as the definition of function1.
The definition of function2 introduced an unresolved reference to function3,
into the program. No file was linked that resolved that reference, so the
linkage failed:
function12.c:(.text+0x32): undefined reference to `function3'
It doesn't matter that function2 cannot be called by the program -
just like it doesn't matter that function1 cannot be called.3
Case 3
You have implemented libutils as a shared library, by linking position-independent
object files function1.o and function2.o compiled from function1.c and function2.c
respectively:
$ gcc -Wall -fPIC -c function1.c function2.c
$ gcc -shared -o libutils.so function1.o function2.o
Notice here that although the shared library libutils.so is an ELF file produced
by linkage (not an ar archive of object files), we are able to link it successfully
despite the fact that function2.o contains an undefined reference to function3.
It is fine to link a shared library with undefined references. See its symbol table:
$ nm libutils.so
0000000000004030 b completed.7930
w __cxa_finalize##GLIBC_2.2.5
0000000000001060 t deregister_tm_clones
00000000000010d0 t __do_global_dtors_aux
0000000000003e18 t __do_global_dtors_aux_fini_array_entry
0000000000004028 d __dso_handle
0000000000003e20 d _DYNAMIC
0000000000001150 t _fini
0000000000001110 t frame_dummy
0000000000003e10 t __frame_dummy_init_array_entry
00000000000020f0 r __FRAME_END__
0000000000002020 r __func__.2361
0000000000001115 T function1
0000000000001142 T function2
U function3
0000000000004000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
000000000000202c r __GNU_EH_FRAME_HDR
0000000000001000 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U printf##GLIBC_2.2.5
0000000000001090 t register_tm_clones
There is U function3. But you can't link a program with undefined references:
$ gcc -o prog main.o libutils.so -Wl,-trace
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o
main.o
libutils.so
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6 (//lib/x86_64-linux-gnu/libc.so.6)
(//usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: libutils.so: undefined reference to `function3'
/usr/bin/ld: link errors found, deleting executable `prog'
collect2: error: ld returned 1 exit status
When we link:
main.o
libutils.so
the linkage fails just as with:
main.o
(libutils.a)function12.o
or indeed:
$ gcc -o prog main.o function1.o function2.o
/usr/bin/ld: function2.o: in function `function2':
function2.c:(.text+0x5): undefined reference to `function3'
collect2: error: ld returned 1 exit status
So:
Is it required to link in all dependencies?
Yes, when you're linking a program. But understand what the dependencies of
a program are:
The dependencies of the program are object files and/or shared libraries
that define the symbols that are referenced in the object files and shared libraries
that are actually linked.
A static library is never one those. It is a container of object files from which
the linker will extract and link ones that are dependencies of the program and ignore
the rest.
[1] What the linker does to link an object file into a program is fundamentally
different from what it does to link a shared library.
Roughly, to link an object file, it physically merges the parts of which the object
file is composed into the corresponding parts of the output program.
Roughly, to link a shared library liby.so, the linker just writes some concise information in
a standard format into the program that will be parsed by the runtime loader,
instructing it to find and load liby.so and merge the parts of which it is
composed into the process of the executed program.
[2] You can check whether your GCC toolchain defaults to --as-needed or not
by grepping for that option in the verbose output of a default GCC linkage, e.g.
$ gcc -v -o prog main.o function1.o 2>&1 | grep '\--as-needed'
[3] We can compile object files with a non-default compilation option -ffunction-sections
and link them in programs with a non-default linker option -gc-sections, with the
effect that the linker will be able to discard definitions of functions that
cannot called, so that they cannot give rise to any references that impose useless
dependencies on the program.
If no call made from second library, it is not required. Typically linker will give error if function in linking for which library or its definition is not present during linking as undefined.
I was trying this on my 64 bit ubuntu:
First I've got a simple program
$ cat test.c
int f(int x){
int i=(x/42);
return i;
}
int main(){
return 0;
}
Then I manually specify how it's linked:
$ gcc test.c -nostdlib /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/x86_64-linux-gnu/crtn.o
I got some errors:
/usr/lib/x86_64-linux-gnu/crt1.o：In function ‘_start’中：
(.text+0x12)：unresolved reference to ‘__libc_csu_fini’
/usr/lib/x86_64-linux-gnu/crt1.o：In function ‘_start’：
(.text+0x19)： unresolved reference to ‘__libc_csu_init’
/usr/lib/x86_64-linux-gnu/crt1.o：In function ‘_start’：
(.text+0x25)： unresolved reference to ‘__libc_start_main’
collect2: error: ld returned 1 exit status
I was trying to see how gcc deals with all necessary object files and try to do it manually. How to fix it? Thanks.
How to fix it?
You are missing libc symbols, so you need to link libc:
gcc test.c -nostdlib /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/x86_64-linux-gnu/crtn.o -lc
Bear in mind that if you really want to link something "manually", you will do it with ld, not gcc
I am trying to get OpenSSL to work, but it seems to have a problem with linking. Here is what I did:
I downloaded OpenSSL for Linux from https://www.openssl.org/source/ I tried versions 0.9.8zc, 1.0.0o and 1.0.1j, all with the same result.
I installed each OpenSSL version using ./config, make and sudo make install.
For debugging purposes, I went to /usr/lib/ssl and used sudo chmod -R 777 * to remove any restrictions that could have caused the error.
I created the following program:
main.c:
#include <errno.h>
#include <malloc.h>
#include <resolv.h>
#include <openssl/bio.h>
#include <openssl/ssl.h>
int main(void) {
SSL_load_error_strings();
return EXIT_SUCCESS;
}
I created the following makefile in the same directory as my .c file:
makefile:
all: main.o
cc -o main main.o -L/usr/local/ssl/lib/ -lcrypto -lssl
main.o: main.c
cc -c -Wall main.c -I/usr/local/ssl/include/ -o main.o
When I run the makefile, I get the following error:
cc -o main main.o -L/usr/local/ssl/lib/ -lcrypto -lssl
/usr/local/ssl/lib//libssl.a(ssl_err2.o): In function SSL_load_error_strings':
ssl_err2.c:(.text+0x4): undefined reference toERR_load_crypto_strings'
/usr/local/ssl/lib//libssl.a(ssl_err.o): In function ERR_load_SSL_strings':
ssl_err.c:(.text+0xc): undefined reference toERR_func_error_string'
ssl_err.c:(.text+0x28): undefined reference to ERR_load_strings'
ssl_err.c:(.text+0x3c): undefined reference toERR_load_strings'
collect2: ld returned 1 exit status
make: *** [all] Error 1
What am I doing wrong?
Cheers
Alex
As answered on the maillist by scott_n but for the record here, swap the order to -lssl -lcrypto.
Explanation: for static C libraries in general on nearly all systems, members of library files like libxxx.a are only pulled in by the linker if they define things referenced from translation units already linked i.e. to the left in the command line. OpenSSL libssl has (numerous) references to libcrypto. If you link -lcrypto first, those references haven't been seen, so the libcrypto files aren't linked; then you link -lssl and create the unsatisfied references. In cases of mutual dependency also called recursive dependency you may need to repeat a library like -lcrypto -lssl -lcrypto but OpenSSL has no such "backward" references.
I'm trying to compile a simple JNI application on an embedded Linux platform (a GuruPlug computer), but for some reason it's not linking to libc properly. The Java program I'm compiling is called Test.java:
public class Test {
static {
System.loadLibrary("Test");
}
public static void main(String[] args) {
new Test().printMessage();
}
public native void printMessage();
}
The implementation of printMessage() is in Test.c:
#include <jni.h>
#include <stdio.h>
#include "Test.h"
JNIEXPORT void JNICALL Java_Test_printMessage(JNIEnv *env, jobject obj)
{
printf("Message 123...\n");
}
I'm compiling Test.c with the following command on a bash shell:
gcc -g -shared -static -lc -Wl,-soname,libTest.so -I${JAVA_HOME}/include/ -I${JAVA_HOME}/include/linux/ Test.c -o libTest.so
When I run the above command, I get the error message "R_ARM_TLS_LE32 relocation not permitted in shared object". The full error message is:
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/4.4.5/../../../libc.a(dl-tsd.o)(.text+0x18): R_ARM_TLS_LE32 relocation not permitted in shared object
Despite the error message, the JNI .so file is still written by the compiler, but running the Java application gives the following error message:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jni/libTest.so: /usr/lib/jni/libTest.so: unexpected reloc type 0x03
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1750)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1675)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at Test.<clinit>(Test.java:3)
Could not find the main class: Test. Program will exit.
Does anybody have any idea how to go about fixing this? Admittedly, the above code is a toy example, but I need to get a real JNI library compiling on this platform, and the real JNI library depends on libc. I can't seem to solve this basic issue of linking libc with a JNI library. Any suggestions would be greatly appreciated.
Thanks!
gcc -g -shared -static -lc -Wl,-soname,libTest.so -I${JAVA_HOME}/include/ -I${JAVA_HOME}/include/linux/ Test.c -o libTest.so
There are several problems with the command line above:
the -shared and -static flags are mutually exclusive, and the second overrides the first
when linking shared libraries, you want -fPIC on most architectures
the -lc is in the wrong place (should follow your sources, not precede them), and is not necessary anyway: gcc will add it automatically
you don't strictly need the -soname either; it's just useless clutter
The correct command then is:
gcc -g -shared -fPIC -I${JAVA_HOME}/include -I${JAVA_HOME}/include/linux \
Test.c -o libTest.so