I was compiling some code I found on the internet and I was given the error
calcCookie.c:1050: warning: ‘HMAC’ is deprecated (declared at /usr/include/openssl/hmac.h:103)
calcCookie.c:1050: warning: ‘EVP_sha1’ is deprecated (declared at /usr/include/openssl/evp.h:666)
when I googled the libraries I couldn't find anything about the symbols being deprecated, I just found a reference to the symbols I used.
http://www.openssl.org/docs/crypto/hmac.html etc.
Do you have any tricks/websites that you can use to find the replacement for deprecated symbols?
First of all, try to find up-to-date documentation for the library.
If that does not work, the warning message from the compiler tells you the file name and line number where the symbol was declared. Look there and hopefully you fill find a comment that explains why it is deprecated and what the alternative is.
If that does not work, then you can look at the version history of the library. Find the first revision where the symbol was marked as deprecated. Look at the commit message and the other changes that were happening around the same time to get a clue about what is going on.
Are/Were you by chance compiling on OSX?
Apple has decided to deprecate OpenSSL and replace it with CommonCrypto.
Why is Apple Deprecating OpenSSL in MacOS 10.7 (Lion)?
Related
I wrote a library which is intended to be used in C as well.
Compiling the library to a .dll/.so/.lib itself is well documented and works as expected.
However, I cannot find anything regarding the corresponding header files.
The only documentation for something like this that I found, is the --header cli argument which was supposedly (to be?) removed.
Can't find it in the https://nim-lang.org/docs/nimc.html page, nor in the help-page of my installation.
Nim-Version:
$ nim -v
Nim Compiler Version 1.6.0 [Windows: amd64]
Compiled at 2021-10-19
In the documentation for the exportc pragma, it only explains the naming and how it can be used.
Same goes for the backend-integration Page, which also doesn't state anything helpful regarding header files.
Is there a proper way to generate the header-files from nim-source code, or do I have to write these manually?
You can use the Genny nimble package to generate a C header file (and also Python and Node.js bindings!) for your Nim library.
Besides that, writing the header manually would be the next best choice. Well, the --header option does still happen to work, but it's not recommended to use it as it's undocumented and unsupported.
During the development of a small project using statically linked OpenSSL 1.0.2e I encountered a strange error in VS13:
Error LNK2001: unresolved external symbol _BN_is_zero
Quite often, this happens when you forget to properly liked .lib file in the project properties, but all of the properties were double-checked - they are correct.
Configuration - Release, MT, libs are MT, bh.h included.
And even if one of the libraries is not linked properly, I should have multiple compiler errors complaining about unresolved external symbols of all the elements used in the project, but in my case unresolved external symbol is the only BN_is_zero.
After quick googling there wasn't found any issues, related to openssl bugs and I guess that the problem resides at my project.
Any tips will be appreciated.
UPD
Here is some screens:
I actually forked the csrp github project and compiled it against the particular openssl libraries you are pointing at. I had to slightly modify test_srp.c and src.c to add some code that isn't available on VS2013. A fork of csrp with the changes applied and the visual studio project for VS2013 to compile it can be found here:
https://github.com/sigmoidal/csrp
Note that you need to change the paths of the openssl path on BOTH the debug and release versions to reflect your VS Configuration Properties:
C/C++ > General > Additional Include Directories
D:\dev\openssl\openssl-1.0.2e-vs2013\include
(you should not point it to $openssl_path/include/openssl, it will not work)
and also:
Linker > Input > Additional Dependencies:
For release configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MT.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MT.lib
For debug configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MTd.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MTd.lib
(notice the "d" suffix on debug libs)
Compiled ok for me.
I'm guessing here, but according to the OpenSSL source BN_is_zero is defined as a macro:
http://osxr.org/openssl/source/crypto/bn/bn.h#0407
So perhaps the module that is compiled into srp.obj is making a call to BN_is_zero but is not including bn/bn.h and in the absence of a prototype the compiler is generating a default one.
If this is the case, including the bn.h definitions should avoid the linker error.
It was tricky, but I've finally solved it based on the Drew MacInnis tips.
The matter is that openssl 1.0.2e broke the BN_is_zero functionality by simply removing the macros-containing header from sources. So, the solution is:
Download the bn.h include file from 1.0.1h (or here)
Place bn.h to %OPENSSL_HOME%/crypto/bn directory
Change #include <openssl/bn.h> for #include <../crypto/bn/bn.h>
I have a Eclipse project using C programming language. I have been stuck with a problem related to linker error since two days now. I have checked various forums to find a solution. Tried a lot of the suggestions but could not resolve it. So as a last resort, i am asking question here. My main program MotorRun.c has code which calls functions in the static library FtMscLib_Static_LIBCMT_Release.Lib which is in Libs folder in the path C:\FT-Project\Common\Libs. I am using MinGW gcc compiler.
When i run the makefile, it generates an error:
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:\FT-Project\Common\Libs\FtMscLib_Static_LIBCMT_Release.Lib
collect2.exe: error: ld returned 1 exit status
The code run by the makefile is
gcc "-LC:\\FT-Project\\Common\\Libs" -shared -o libRoboCopMinGW.exe "src\\MotorRun.o" "-lC:\\FT-Project\\Common\\Libs\\FtMscLib_Static_LIBCMT_Release.Lib"
By looking at the execution code, we can see that the paths and library name has been set correctly, but the linker just cannot find it so that it can link the library with my MotorRun.o object file. Hope someone can help me in finding a solution.
The program MotorRun.c is a very simple one, so i am not posting it here. But if necessary i can update it later. Thanks in advance!
The correct linker syntax is typically something like:
-Lpath_to_library_directory -lname
where the library filename (for a Windows static library) would be name.lib. So your above linker line needs to lose the .lib part. You may also need to prefix the -l argument with another argument -static, to instruct the linker to search for the static library FtMscLib_Static_LIBCMT_Release.Lib otherwise it might try to find the DLL instead.
By the way, there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW, so feel free to search for these also. The MinGW web pages also have numerous tips on the same topic.
So for an assignment I need to use GnuTLS. I have downloaded gnutls by following this guide http://www.bauer-power.net/2014/06/how-to-install-gnutls-3123-from-source.html
However, using any of the gnutls functions, similar to how they are used in the official gnutls documentation (http://www.gnutls.org/manual/html_node/Client-examples.html), displays several errors after building. All errors follow this format:
...pathtofile:line#/..undefined reference to 'gnutls_...'
I understand that this might be a linking problem, however I am quite new to this type of environment. What should I do? I have tried to install gnutls again several times.
I am using Ubuntu 14.04, gnutls-3.1.23 and eclipse Luna.
Thanks in advance.
You probably have an error on your link line.
Add the flag -lgnutls to the ld command (or, if just one C file, the compile line).
When I was compiling a new software, I encountered a bunch of errors emitted by ld.
/usr/lib/libstreamanalyzer.so.0: undefined reference to `xmlSAXUserParseMemory#LIBXML2_2.4.30'
/usr/lib/libstreamanalyzer.so.0: undefined reference to `xmlCtxtResetPush#LIBXML2_2.6.1'
/usr/lib/libstreamanalyzer.so.0: undefined reference to `xmlCreatePushParserCtxt#LIBXML2_2.4.30'
This seems to be confusing. Linker is supposed to be looking for symbols in objects, not library names, but it seems in this case those before the # is the function name/symbol, and LIBXML2_2.6.1 is a library name. And for dynamic library, the soname x.y.z version should only matter in dynamic linking stage, that is when the executable actually runs.
So what does this error really means, and what part of the above assumptions are wrong?
Edit:
The problem appears after installing libxml2 2.7.8. It is gone after libxml2 is upgraded to 2.9.1.
When I was compiling a new software, I encountered a bunch of errors
No, you didn't. You encountered errors when linking, which is different from compiling.
Linker is supposed to be looking for symbols in objects
UNIX linkers also look for symbols in libraries (both archive and shared).
LIBXML2_2.6.1 is a library name
No, it's not. It's a symbol version, which happens to reflect the library in which that symbol was defined.
So what does this error really means
This error means: when libstreamanalyzer.so.0 was linked, it was linked against a library (most likely libxml2.so) that provided versioned symbols xmlSAXUserParseMemory#LIBXML2_2.4.30, etc.
You are now linking your binary against some other version of libxml2, one which does not provide these symbols, and your binary will not work.