Undefined reference to RSA_generate_key in OpenSSL? [duplicate] - c

This question already has answers here:
Linking libssl and libcrypto in GCC [duplicate]
(2 answers)
Closed 6 years ago.
I have the following code in the file rsatest.c. I'm trying to generate a RSA key pair.
#include <openssl/rsa.h>
#include <openssl/pem.h>
int main(){
RSA *rsa = RSA_generate_key((const int) 1024,(const int) 3, 0, 0);
return 0;
}
I'm compiling this with
gcc -I../include/ -L . -lcrypto -lssl rsatest.c
and I get the following error.
undefined reference to `RSA_generate_key'
Am I linking the library files in the wrong order? I made the libcrypto.a and libssl.a on windows (64 bit), with msys and mingw, and I'm running the code on the same system.
RSA_generate_key has been declared in rsa.h. Is it not defined in libcrypto.a?
EDIT :
I tried this too,
gcc -I../include rsatest.c -L . -lcrypto -lssl
and I understand that the linker will look for definitions in the libraries going from left to right.
However, I get new undefined references to various functions in
rand_win.o and c_zlib.o
I looked up online and found the missing symbols in the libraries gdi32 and zlib. So I added
-lz and -lgdi32
The compiler did not complain about a missing library, so I assume they are present with mingw. And still, I get the same output.
I also used nm, and found that the symbols were indeed undefined in rand_win.o and c_zlib.o.
Why cant the linker seem to find definitions in these libraries?

Change the order in your gcc command.
gcc -I../include/ rsatest.c -L . -lcrypto -lssl
As far as I know linker has a list of undefined symbols. When it processes libcrypto.a and libssl.a it does not have anything in the list of undefined symbols so he just drops the libraries. Then after processing rsatest it has something in its list but it does not look for symbols in already processed libraries.

Related

Add a .a library to cmake project [duplicate]

This question already has answers here:
CMake link to external library
(6 answers)
Closed 4 years ago.
I have a libname.a static library that works fine when I use gcc:
gcc -c main.c -o main.o ;
gcc main.o libname.a main
But now I would like to use CMake as the project is getting big, but I got this message and and I don't know how to include it in an appropriate way. (I tried link_target_library and/or link_directories and/or set(CMAKE_CC_FLAGS "absolute_path/libname.a").
Note that I don't have any source code for libname.a.
/usr/bin/ld: cannot find -llibname
As said in my comment target_link_libraries(${PROJECT_NAME} ${CMAKE_SOURCE_DIR}/libname.a) works. I can't really tell what the reason for your problem is (maybe you used target_link_library instead of target_link_libraries ?).

-lm doesnt work unless it's at the end of the command [duplicate]

This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 2 years ago.
Im currently writing a program for a uni asssessment and they have a set line to compile it, so if it doesn't work with that it won't be accepted.
They command they use is
gcc -Wall -ansi -lm program.c -o program.out
My program will not compile that way, and it'll give me a undefined referance error (Referring to my log10 using math.h library)
if i use:
gcc -Wall -ansi program.c -o program.out -lm
it works
What could be my issue?
Im using windows 10 64bit and have windows bash installed and gcc.
This would be explained if your instructors are using gold and you are using GNU ld. These are two linkers, both are part of the GNU project, and both are commonly used with GCC.
If you are using GNU ld, you get the "traditional" behavior:
The order of specifying the -L and -l options, and the order of specifying -l options with respect to pathname operands is significant.
This means that you have to put -lm after any object files and libraries that depend on it.
However, if you are using gold, the -l options may appear first.
If you have gold installed on your system, you can test it yourself.
Here is what I get:
$ gcc -lm program.c
/tmp/ccJmBjmd.o: In function `main':
program.c:(.text+0x15): undefined reference to `sin'
collect2: error: ld returned 1 exit status
But if I use gold, it works fine:
$ gcc -lm program.c -fuse-ld=gold
-lm needs to be at the end of the command, most likely in the first case with the literal the compiler is optimizing out the call to any function and therefore does not need to link against the library. This is called constant folding and for example we can see in the gcc docs on Other Built-in Functions Provided by GCC says:
GCC includes built-in versions of many of the functions in the
standard C library. The versions prefixed with __builtin_ are always
treated as having the same meaning as the C library function even if
you specify the -fno-builtin option. (see C Dialect Options) Many of
these functions are only optimized in certain cases; if they are not
optimized in a particular case, a call to the library function is
emitted.

Unable to link to libgfortran.a [duplicate]

This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 8 years ago.
I have gfortran installed on my system and the file libgfortran.a can be found at /usr/lib/gcc/x86_64-linux-gnu/4.6/. Using nm I made sure that the function _gfortran_compare_string is defined in there:
$ nm /usr/lib/gcc/x86_64-linux-gnu/4.6/libgfortran.a | grep _gfortran_compare_string
Returns
0000000000000000 T _gfortran_compare_string
0000000000000000 T _gfortran_compare_string_char4
But, the linker of my CUDA-C program throws errors:
/usr/local/cuda-6.0/bin/nvcc --cudart static -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/home/chung/lapack-3.5.0 -link -o "pQP" ./src/pQP.o -lgfortran -llapacke -llapack -lcublas -lblas -lcurand
nvcc warning : The 'compute_10' and 'sm_10' architectures are deprecated, and may be removed in a future release.
/home/chung/lapack-3.5.0/liblapack.a(ilaenv.o): In function `ilaenv_':
ilaenv.f:(.text+0x81): undefined reference to `_gfortran_compare_string'
and later on another error, again related to libgfortran:
/home/chung/lapack-3.5.0/liblapack.a(xerbla.o): In function `xerbla_':
xerbla.f:(.text+0x49): undefined reference to `_gfortran_st_write'
xerbla.f:(.text+0x54): undefined reference to `_gfortran_string_len_trim'
xerbla.f:(.text+0x66): undefined reference to `_gfortran_transfer_character_write'
xerbla.f:(.text+0x76): undefined reference to `_gfortran_transfer_integer_write'
xerbla.f:(.text+0x7e): undefined reference to `_gfortran_st_write_done'
xerbla.f:(.text+0x87): undefined reference to `_gfortran_stop_string'
But, again using nm, I found that _gfortran_st_write, etc are defined in libgfortran.a.
Links: Complete log and source code.
Note: Lapack makes use of libgfortran. I recently installed lapack and ran all the tests and they all passed.
You need to change the order in which you specify static libraries to the linker. If you do something like this:
nvcc --cudart static -L/usr/lib/gcc/x86_64-linux-gnu/4.6 \
-L/home/chung/lapack-3.5.0 -link -o "pQP" ./src/pQP.o \
-llapacke -llapack -lcublas -lblas -lcurand -lgfortran
You should find it will work.
The underlying reason (and this is a trait of the gcc/gnu toolchain and not anything to do with nvcc) is that linking dependency lists for static libraries are parsed from left to right by the gnu linker. If you specify a static library before any library which depends on it, it will be skipped because it has no dependencies in the link list at the point in processing when it is first encountered.

Can't link against WinPcap library wpcap.lib ("undefined reference to")

I am trying to build an example program which uses WinPcap-functions. I’m working under Windows 7 64 Bit edition with MinGW. I am able to compile the C-code to an object file, but I can’t link against wpcap.lib.
My linker call looks like this:
gcc -L ../../lib/x64 send_packet.o -lwpcap -o WinPcapTest.exe
With this call I get the following errors:
undefined reference to pcap_open
undefined reference to pcap_sendpacket
undefined reference to pcap_geterr
Obviously I am not linking against wpcap.lib, but I don’t know why. The library is definitely found. If I change the lib include path for example, I get this error:
cannot find -lwpcap
Why does the linker find the lib but does not link against it? Thanks for your help.
Try listing you libraries after binary definition. As far as I remember, with provided gcc command, ld would be symbol matching for pcap symbols between send_packet.o and libwpcap.lib but not with WinPcapTest.exe. I would suggest moving -lwpcap at the end:
gcc -I ..\..\..\Downloads\WpdPack_4_1_2\WpdPack\Include ..\send_packet.c -L ..\..\..\Downloads\WpdPack_4_1_2\WpdPack\Lib\x64 -O0 -g3 -Wall -o WinPcapTest.exe -lwpcap

Linking libssl and libcrypto in GCC [duplicate]

This question already has an answer here:
Errors that refer to a bunch of unresolved OpenSSL symbols that clearly exist?
(1 answer)
Closed 6 years ago.
I'm attempting to use OpenSSL's EVP interface to do some encryption. I'm pretty sure my code is right, but I can't seem to get it to compile. I'm using GCC, and Ubuntu 32-bit precise with libssl-dev installed and at the latest version.
The project currently consists of one file, program.c.
#include <openssl/evp.h>
...
i = EVP_BytesToKey(EVP_aes_256_cbc(), EVP_sha1() ... );
...
EVP_CIPHER_CTX_init(e_ctx);
among other various calls.
Here is how I invoke gcc:
gcc -Wall -g -lssl -lcrypto -o program program.c
Then I get output like this
/home/andy/program/program.c:31: undefined reference to `EVP_sha1'
/home/andy/program/program.c:31: undefined reference to `EVP_aes_256_cbc'
/home/andy/program/program.c:31: undefined reference to `EVP_BytesToKey'
/home/andy/program/program.c:44: undefined reference to `EVP_CIPHER_CTX_init'
So the include is clearly working:
andy#ProgStation2:/usr/include$ find . | grep evp.h
./openssl/evp.h
Here is the output of locate libcrypto. My best guess is that this is a stupid location for it and is why my link is failing, so I tried -L/usr/lib/i386-linux-gnu before -lcrypto with no luck as well.
/lib/i386-linux-gnu/libcrypto.so.1.0.0
I'm kind of stumped. If anyone wants to make me feel like a fool, I'd be very excited to figure out what i'm doing wrong!
It turns out it was something stupid. In the linker step, I was using gcc -Wall -g -lssl -lcrypto -o program program.o. I needed to move the library links to after the object file I was linking, and put libssl before libcrypto:
gcc -Wall -g -o program program.o -lssl -lcrypto
Try including headers using -I option, Look into directory for library using -L and finally specifying the library name with -l
Just making guess here, please specify path based on actual location.
gcc -g -Wall -L/usr/lib -I/usr/include -lssl -lcrypto -o program program.c
Hope it may help.

Resources