I got a problem of linking an OpenSSL library into an existing project.
Where I do get it wrong?
Below are the steps I have followed.
I have downloaded the SSL library, configured and installed it. It gets installed in /usr/local/ssl.
2) I have copied libcrypto.a and libssl.a from /usr/local/ssl/lib into my project, something like /mnt/linux/bla/bla/lib.
3) Then I edit the make file and added path of libssl libcrpto there. The path added is one that is in project like /mnt/linux/bla /bla
3) make
4) build project via slick edit
When it builds I get a long error chain, like
../lib/libssl.a(t1_enc.o) :In function 't1sl_steup_key_block: undefined ref
Now, I guess copying .a files into project could be problem. Is there is any alternative for that or should I use ln -s to link .a files form /usr/local/openssl/lib into my project library folder? Below is the error.
Debug/FC5/m2pa.o -ldl -lpthread -ltdapi ../septel/gctlib.lib ../lib/libpq.a ../asn1/lib/libasn1per.a ../mysql/lib/libmysqlclient.a -L../lib ../asn1/lib/libasn1rt.a -lm -lcrypt -lcrypto -lssl -rdynamic
../lib/libssl.a(ssl_lib.o): In function `SSL_set_quiet_shutdown':ssl_lib.c:(.text+0x670): multiple definition of `SSL_set_quiet_shutdown'
../mysql/lib/libmysqlclient.a(ssl.o):ssl.cpp:(.text+0x125c): first defined here
/usr/bin/ld: Warning: size of symbol `SSL_set_quiet_shutdown' changed from 45 in ../mysql/lib/libmysqlclient.a(ssl.o) to 12 in ../lib/libssl.a(ssl_lib.o)
../lib/libssl.a(ssl_lib.o): In function `SSL_get_quiet_shutdown':ssl_lib.c:(.text+0x680): multiple definition of `SSL_get_quiet_shutdown'
../mysql/lib/libmysqlclient.a(ssl.o):ssl.cpp:(.text+0x12down' changed from 35 in ../mysql/lib/libmysqlclient.a(ssl.o) to 8 in ../lib/libssl.a(ssl_lib.o)
../lib/libssl.a(ssl_err2.o): In function `SSL_load_error_strings':ssl_err2.c:(.text+0x4): undefined reference to `ERR_load_crypto_strings'
../lib/libssl.a(ssl_algs.o): In function `SSL_library_init':ssl_algs.c:(.text+0x4): undefined reference to `EVP_des_cbc'
:ssl_algs.c:(.text+0xc): undefined reference to `EVP_add_cipher'
:ssl_algs.c:(.text+0x11): undefined reference to `EVP_des_ede3_cbc'
:ssl_algs.c:(.text+0x19): undefined reference to `EVP_add_cipher'
:ssl_algs.c:(.text+0x1e): undefined reference to `EVP_idea_cbc'
Have you tried using the libssl and libcrypto already installed in your /usr/lib directory (assuming you've installed the dev packages for both)? Once that compiles and runs without error using the default install, you can build your new libssl/libcrypto(?) from source, install to usr/local, and rebuild using the usr/local versions of the libraries.
You need to add the flag -lssl and -lcrypto in your makefile'
For example:
gcc somefile.c -o someprogram -lssl -lcrypto
Related
I am working on open62541 open source project.I have built the project using Cmake as mentioned here at the following webpage open62541.org and generated the open62541.c ,open62541.h files in the project's build folder.Then I created a new folder called C_project inside the build folder and copied the generated files into this folder.
Now I am trying to build a minimal server(C_Project/myServer.c) by following the steps given at the following page open62541/sever.I am getting the following link errors.
C:\SPB_Data\open62541\build\C_Projects\OPC_UA>cmd /c gcc -std=c99 open62541.c myServer.c -lws2_32 -o myServer.exe > output.txt
C:\Users\PAVAN-~1\AppData\Local\Temp\cc1s9pOw.o:myServer.c:(.text+0x98): undefined reference to `__imp_UA_ServerConfig_setMinimalCustomBuffer'
C:\Users\PAVAN-~1\AppData\Local\Temp\cc1s9pOw.o:myServer.c:(.text+0xd8): undefined reference to `__imp_UA_Log_Stdout'
C:\Users\PAVAN-~1\AppData\Local\Temp\cc1s9pOw.o:myServer.c:(.text+0x132): undefined reference to `__imp_UA_Server_new'
C:\Users\PAVAN-~1\AppData\Local\Temp\cc1s9pOw.o:myServer.c:(.text+0x146): undefined reference to `__imp_UA_Server_getConfig'
C:\Users\PAVAN-~1\AppData\Local\Temp\cc1s9pOw.o:myServer.c:(.text+0x165): undefined reference to `__imp_UA_Server_run'
C:\Users\PAVAN-~1\AppData\Local\Temp\cc1s9pOw.o:myServer.c:(.text+0x178): undefined reference to `__imp_UA_Server_delete'
collect2.exe: error: ld returned 1 exit status
I used the following command to build the project:
$ gcc -std=c99 open62541.c myServer.c -o myServer
I tried to find the solutions for this by searching in the web. The only thing that I could get out of that is it might be a error due to dll files. Kindly help.
-open62541.lib specifies that the result of compilation should be written to file pen62541.lib.
And -o myServer.exe says that it should be written to myServer.exe instead.
And GCC will then ignore the first output file name.
Solution: remove the - from the library name.
I had similar problem as you when I made the CMake build with BUILD_SHARED_LIBS on.
For me it was working when I installed open62541 with CMake options UA_ENABLE_AMALGAMATION on and UA_NAMESPACE_ZERO full (rest default)
I compiled with the command
gcc -std=c99 myserver.c open62541.c -o server -lws2_32
Inside the selected folder are just the files open62541.c/.h and myserver.c
I am trying to compile a program within a docker container built from the Alpine 3.7 base image. The program uses argp.h, and includes it as #include <argp.h>. I have installed argp-standalone and verified that it is making it onto the image. The file argp.h is located in usr/include, however when I compile my program using the following commands:
gcc -W -Wall -Wextra -I/usr/include -c -o progname.o progname.c
gcc -largp -o progname progname.o
I get the following error:
progname.o: In function `parse_opt':
progname.c:(.text+0x4c9): undefined reference to `argp_failure'
progname.c:(.text+0x50f): undefined reference to `argp_failure'
progname.c:(.text+0x555): undefined reference to `argp_failure'
progname.c:(.text+0x59b): undefined reference to `argp_failure'
progname.c:(.text+0x5ce): undefined reference to `argp_error'
progname.c:(.text+0x5f4): undefined reference to `argp_error'
progname.o: In function `main':
progname.c:(.text+0x1397): undefined reference to `argp_parse'
collect2: error: ld returned 1 exit status
make: *** [Makefile:9: progname] Error 1
I have:
Ensured that the version of argp.h which is on the image does in fact include the argp_failure, argp_parse, and argp_error functions.
Tried moving argp.h into different locations on the machine (e.g. into the same directory where compilation is taking place, into /usr/lib)
Tried compiling with -l and -L.
The relevant packages also installed in the image are build-base, make, and gcc.
When compiling on an Ubuntu image these same commands work fine, even without the -largp and -I/usr/include flags. What could be happening differently within an Alpine image which would cause this not to work?
Edit
As per #Pablo's comment, I'm now compiling it as follows:
gcc -W -Wall -Wextra -I/usr/include -L/usr/lib -c -o progname.o progname.c
gcc -largp -o progname progname.o
After having verified that the static library, libargp.a, is located in /usr/lib. However, the same problem still persists.
Edit 2
Compiling as follows (and once again as per #Pablo's suggestion) has resolved the error I was having:
gcc -W -Wall -Wextra -I/usr/include -L/usr/lib -c -o progname.o progname.c
gcc -o progname progname.o /usr/lib/libargp.a
However, I am still curious why, using the exact same library and instructions, this would fail to compile in an Alpine image while compiling without issue in an Ubuntu image.
I am still curious why, using the exact same library and instructions, this would fail to compile in an Alpine image while compiling without issue in an Ubuntu image.
The reason for the linking error on Alpine may be kind of surprising, and is actually not specific to Alpine.
While this fails to link:
gcc -largp -o progname progname.o
This works:
gcc -o progname progname.o -largp
The reason is the order of parameters passed to the linker, and it related to the linking algorithm. Typically, in the linking command line objects are specified first (and possibly user's static libraries in any), then libraries using -l. The standard linker algorithm is explained perfectly in Eli Bendersky's article, Library order in static linking:
Object files and libraries are provided in a certain order on the command-line, from left to right. This is the linking order. Here's what the linker does:
The linker maintains a symbol table. This symbol table does a bunch of things, but among them is keeping two lists:
A list of symbols exported by all the objects and libraries encountered so far.
A list of undefined symbols that the encountered objects and libraries requested to import and were not found yet.
When the linker encounters a new object file, it looks at:
The symbols it exports: these are added to the list of exported symbols mentioned above. If any symbol is in the undefined list, it's removed from there because it has now been found. If any symbol has already been in the exported list, we get a "multiple definition" error: two different objects export the same symbol and the linker is confused.
The symbols it imports: these are added to the list of undefined symbols, unless they can be found in the list of exported symbols.
When the linker encounters a new library, things are a bit more interesting. The linker goes over all the objects in the library. For each one, it first looks at the symbols it exports.
If any of the symbols it exports are on the undefined list, the object is added to the link and the next step is executed. Otherwise, the next step is skipped.
If the object has been added to the link, it's treated as described above - its undefined and exported symbols get added to the symbol table.
Finally, if any of the objects in the library has been included in the link, the library is rescanned again - it's possible that symbols imported by the included object can be found in other objects within the same library.
When -largp appears first, the linker does not include any of its objects in the linking procedure, since it doesn't have any undefined symbols yet. If the static library is provided by path, and not with -l, then all of its objects are added to the linking procedure.
I am compiling my code with
gcc -o ./sample/createUsageXMLd ./obj/createUsageXML.o -L../../../third_party/lib/openssl-fips/2.0/LSBGCC64 -L../../../third_party/lib/curl/7.45.0/LSBGCC64 -lssl -lcrypto
But I get error
/
usr/bin/ld: warning: libssl.so.1.0.0, needed by ../../../third_party/lib/curl/7.45.0/LSBGCC64/libcurl.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libcrypto.so.1.0.0, needed by ../../../third_party/lib/curl/7.45.0/LSBGCC64/libcurl.so, not found (try using -rpath or -rpath-link)
../../../third_party/lib/curl/7.45.0/LSBGCC64/libcurl.so: undefined reference to `SSL_CTX_set_srp_username'
../../../third_party/lib/curl/7.45.0/LSBGCC64/libcurl.so: undefined reference to `SSL_CTX_set_srp_password'
collect2: error: ld returned 1 exit status
I have the following in my
libraries third party folder
$ cd third_party/lib/openssl-fips/2.0/LSBGCC64/
$ ls
libcrypto.a libcrypto.so libcrypto.so.1.0.0 libssl.a libssl.so libssl.so.1.0.0
You also need to provide the name of the library that you wish to link,
gcc file.c -o file -L/path/to/libs -llibname
In your case, try providing -lssl after including the path to your libraries (which you've done using -L). Note that the prefix "lib" and suffix ".so" are not required.
I tried installing curl with yum install. I checked the version of installed curl.It was 7.29.0. My compilation was successful. Later I degraded the version of curl from 7.45.0 to 7.29.0 in third_party folder. Now it compiles fine
The problem I have is the "undefined reference to '_imp__...' " error that comes up when I build my project. I am using Windows 7, MinGW, Eclipse and .lib and .dll file that I did not make, but I took directly from the company that sold me their product.
I link with the -l command the HRDL.lib file and i have the PicoHRDL.dll at the same directory. The lib file is found (I'm sure about this), but the error comes up. I have included the complete path with the -L command. I have included the header file with the declarations of the functions, I get the undefined reference to, but the error is still there.
I have contacted both Eclipse support and Picotech support (the said company) but they weren't able to locate the problem till now.
These are the commands:
gcc -O0 -g -Wall -c -fmessage-length=0 -o ACD_SOURCE.o "..\\ACD_SOURCE.c"
gcc "-LC:\\Users\\Falamana\\Desktop\\Eclipse\\ADC_project1\\Libraries" -shared -o libADC_24_DataLogger_App.exe ACD_SOURCE.o -lHRDL
These are the errors:
ACD_SOURCE.o: In function `main':
C:\Users\Falamana\Desktop\Eclipse\ADC_project1\Debug/../ACD_SOURCE.c:70:
undefined reference to `_imp__HRDLGetUnitInfo#16'
C:\Users\Falamana\Desktop\Eclipse\ADC_project1\Debug/../ACD_SOURCE.c:99:
undefined reference to `_imp__HRDLCloseUnit#4'
ACD_SOURCE.o: In function `SelectUnit':
C:\Users\Falamana\Desktop\Eclipse\ADC_project1\Debug/../ACD_SOURCE.c:115:
undefined reference to `_imp__HRDLGetUnitInfo#16'
C:\Users\Falamana\Desktop\Eclipse\ADC_project1\Debug/../ACD_SOURCE.c:167:
undefined reference to `_imp__HRDLGetUnitInfo#16'
In my case it helpt to add -mwindows flag to linker options.
Note that in your compiling information, the -L option symbol should be out of the quote. That's to say, the
gcc "-LC:\Users\Falamana\Desktop\Eclipse\ADC_project1\Libraries" -shared -o libADC_24_DataLogger_App.exe ACD_SOURCE.o -lHRDL
should be
gcc -L"C:\Users\Falamana\Desktop\Eclipse\ADC_project1\Libraries" -shared -o libADC_24_DataLogger_App.exe ACD_SOURCE.o -lHRDL
So please check your configuration of the lib directory in whatever IDE you are using, util the gcc line of compiling information looks normal( util -L stands right ahead of the quote character).
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