I'm doing some compile works recently.
After updated openssl1.1.1f to openssl1.1.1h, I met some compile errors for packages using the openssl headers "bio.h" and "evp.h".
That's because openssl1.1.1h add something like this:
/*
* name is cast to lose const, but might be better to route through a
* function so we can do it safely
*/
#ifdef CONST_STRICT
/*
* If you are wondering why this isn't defined, its because CONST_STRICT is
* purely a compile-time kludge to allow const to be checked.
*/
int BIO_read_filename(BIO *b, const char *name);
# else
# define BIO_read_filename(b,name) (int)BIO_ctrl(b,BIO_C_SET_FILENAME, \
BIO_CLOSE|BIO_FP_READ,(char *)(name))
# endif
If the CONST_STRICT marco is defined, you have to implement the api yourself otherwise you will get an undefined reference error during linkage phase.
I wonder what compile option I have to add to make the CONST_STRICT marco NOT defined?
Thanks in advance!
I miss-understood what the comment in the openssl header file means, thanks to Guillaume Petitjean who corrected me.
The error I got is due to other cause. One of my packages has an older version of openssl in it, and it installed it's header files after it's being built. In that version the api BIO_read_filename was not implemented by marco definition but in a source file. I modified the makefile of the package to not install the older openssl header file and the error are gone.
Related
I was compiling some 'C' code that uses openssl under Fedora 27 (version 1.1.0g-1). I made some needed changes (from the 1.0.2 version of my code) and things now compile o.k. again.
I then tried to compile with the option "OPENSSL_API_COMPAT=0x10100000L" which I understand causes the compiler to not include APIs deprecated in openssl version 1.1.
Now, my code won't compile and seems to not find the definitions of things like BN_bin2bn() and BN_free().
Looking at the headers, /usr/include/openssl/dh.h doesn't even include bn.h at all with this option set.
So, are the BN_xxxx functions now all deprecated in 1.1?
Looking at the openssl 1.1 documents in places like https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes doesn't mention this being the case.
The description of BN_bin2bn() at https://www.openssl.org/docs/man1.1.0/crypto/BN_bin2bn.html doesn't indicate this as deprecated as far as I can see.
Am I missing something? If these functions are deprecated, I would like to know what I'm supposed to use instead (for dh.h things, etc.).
Thanks;
.....c:927:8: error: implicit declaration of function ‘BN_bin2bn’; did you mean ‘OBJ_nid2sn’? [-Werror=implicit-function-declaration]
p = BN_bin2bn(dh1024_p, sizeof dh1024_p, NULL);
^~~~~~~~~
The BN functions are still present and non-deprecated. Check out the lack of relevant #ifs preceding line 180 in https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/include/openssl/bn.h
Looks like they must've just done some header-refactoring to eliminate header coupling. In fact, in the dh header for 1.1 we now see
# if OPENSSL_API_COMPAT < 0x10100000L
# include <openssl/bn.h>
# endif
at line 20 in https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/include/openssl/dh.h. So moving forward they don't include the bignum header automatically. This sounds exactly like improving the header coupling.
Try explicitly adding #include <openssl/bn.h> after your include of dh.h.
I am developing a C application, and using Eclipse CDT IDE, which I find great. The project uses Glib,Gtk,and GStreamer , so whenever I use some of their features in a file, I need to include:
#include <glib.h>
#include <gtk/gtk.h>
#include <gst/gst.h>
The code compiles without any error, since the PATH variable to search those headers is set correctly in a CMakeLists.txt.
However, while working on the project, I found annoying errors highlighting in my code, regarding type definitions like gchar or GValue or GTKApplication; the error outlined is "symbol **** could not be resolved". These definitions are inside a header file that my Eclipse IDE cannot find (included by glib.h), if not at compile time (indeed the program compiles correctly). Instead, the type GError , defined in gst.h , is not highlighted as an error by the pre-compiler.
I would like then that my Eclipse IDE could search on nested headers (#include inside an #inlcude inside...) to find those type definition, in order so to not have those annoying errors highlighting. How can I do so? I would not like to have to include directly all files where the type definitions are done.
EDIT: As Jonah Graham outlined, the problem is not beacuse Eclispe does a "single-step research" on the headers, since it inspects includes inside other includes like any other IDE. It is a CMake bug with c and Eclipse
Thanks in advance.
The problem you are facing is a CMake bug*. CMake adds __cplusplus into the defined symbols unconditionally, which means that glib headers are not parsed properly when in C mode. You can see this clearly by opening gmacros.h around the definition for G_BEGIN_DECLS:
Because CMake told CDT __cplusplus is defined, it thinks G_BEGIN_DECLS is also defined, which makes code like this from gtypes.h parse incorrectly:
G_BEGIN_DECLS
/* Provide type definitions for commonly used types.
* These are useful because a "gint8" can be adjusted
* to be 1 byte (8 bits) on all platforms. Similarly and
* more importantly, "gint32" can be adjusted to be
* 4 bytes (32 bits) on all platforms.
*/
typedef char gchar;
...
Of course with no gchar defined, everything else is going to go badly.
Luckily there is a quick workaround until the problem is resolved in CMake, remove __cplusplus from the info in CDT.
Open Project Properties
C/C++ Include Paths and Symbols
Remove __cplusplus from the list and press OK
(sometimes necessary) Right-click on project -> Index -> Rebuild
* There may be some other workarounds if you know CMake better. The bug says also it will be fixed for the next release of CMake.
I've added a new function wiringPiVersion() to wiringPi, but after I build and install the shared library, when I attempt to compile a small C program around it, I get:
wpi_ver.c:(.text+0xc): undefined reference to `wiringPiVersion'
However, when I include it in an XS based Perl module, all works well. I don't know enough about C to figure out what's going wrong here, and I've been searching for the better part of two hours trying different things to no avail.
Here's my small C program to test the new function:
#include <stdio.h>
#include <wiringPi.h>
int main (){
char * ver = wiringPiVersion();
printf("wiringPi version: %s\n", ver);
return 0;
}
Compilation that throws the error:
gcc -o ver wpi_ver.c -lwiringPi
The addition to wiringPi's header file:
extern char * wiringPiVersion(void);
The wiringPi's .c file addition:
#define WPI_VERSION "2.36"
char * wiringPiVersion(void){
return WPI_VERSION;
}
In my Perl module's XS file, I have:
char *
wiringPiVersion()
...and my Perl module's Makefile.PL
LIBS => ['-lwiringPi'],
...and after re-installing the Perl module, I can access the function without any issues in a test script.
I'm hoping this is something simple I'm overlooking which someone may be able to point out. My question is, how do I rectify this?
So it turned out that there were two .so files generated when I rebuilt wiringPi... one in the wiringPi's build directory way under my home directory, and the other in /usr/local/lib.
After a tip in comments, I added the library path explicitly:
gcc -o ver wpi_ver.c -L/usr/local/lib -lwiringPi
...and it all fell together and works as expected:
$ ./ver
wiringPi version: 2.36
Note: I have sent Gordon the patch in hopes it gets included in the next wiringPi cut.
Update: I received an email back from Gordon and he stated that currently, only the gpio application has the ability to report the version, so he advised that he's going to add something similar to my patch in a future release.
Although already solved, I added this answer to show what gave me the hint.
Error message "undefined reference" points to a linker error (cf. answer on SO), so its about checking if the correct library is drawn.
I am programming stm8s and sht20 from sensirion company with I2C on the IAR. I'm using sht20 sample code: this link
I edited this sample code to my mcu. Then, for example I included i2c_hal.h to my main.c, but functions not working in my main.c file and IAR error is
ERROR LI005 no defition for I2c_Init()
Linking error
For example:
main.c
#include "stm8s.h"
#include "i2c_hal.h"
I2c_Init();
i2c_hal.h
#ifndef I2C_HAL_H
#define I2C_HAL_H
void I2c_Init ();
#endif
i2c_hal.c
#include "I2C_HAL.h"
void I2c_Init ()
{
SDA=LOW;
SCL=LOW;
SDA_CONF=LOW;
SCL_CONF=LOW;
SDA=HIGH;
SCL=HIGH;
}
I copied sht20 files to my project directory. What should I do for this error?
The header file is read by the preprocessor not the linker; if you get as far as linking, it is not a header file issue. The three basic build steps for C code are:
preprocess
compile
link
Your build is failing at the link state. The linker requires all compiled object files and any necessary libraries that constitute your application as input. In your case the most likely issue is that you have not compiled and linked i2c_hal.c (or strictly compiled i2c_hal.c and linked i2c_hal.obj). In the IAR IDE you simply explicitly add i2c_hal.c to your project along with main.c, and all should be good (all other dependencies being satisfied).
I suspect that i2c_hal.c will infact fail compilation since it is missing any declaration of SDA, SCL etc. - you probably need to include stm8s.h there also.
In general the process looks like this (this diagram actually omits pre-processing - i.e. expansion of headers, macros and conditional compilation etc. - but it was the otherwise clearest example I found; the original page does however mention the pre-processor stage, and the preprocessor is normally run automatically when you invoke the compiler in any case):
I have also the same issue with the spi. I got hal_spi_init() linking problem. To resolve the issue you need to enable the I2C in your stm32 hal drivers. In stm32xx_hal_conf.h file we have different #define modules. There you can enable the I2C module or just include the defined symbol in your IAR tool. Then Issue resolved
You need to add the C source files to the project. Header files shall not have any code or data, only the declarations of types , extern variables, macros, static inline functions and function prototypes.
I want to use some features of OpenSSL(1.0.1j) on multiple devices. One requirement is to minimize the size of the code. The OpenSSL code is linked statically to mine. I am only using the RSA_public_decrypt, BIO and PEM->RSA decoding methods. To achieve this, i'm currently compiling OpenSSL not the standard autotools way. I have already stripped out some code that i never use. The only symbol i can not resolve is _BIGNUM_it.
It is declared in asn1t.h with:
DECLARE_ASN1_ITEM(BIGNUM)
and
#define DECLARE_ASN1_ITEM(name) \
extern const ASN1_ITEM name##_it;
It is used in rsa_asn1.c:
ASN1_SIMPLE(RSA, n, BIGNUM),
ASN1_SIMPLE(RSA, e, BIGNUM),
which resolves to:
#define ASN1_SIMPLE(stname, field, type) ASN1_EX_TYPE(0,0, stname, field, type)
and
#define ASN1_EX_TYPE(flags, tag, stname, field, type) { \
(flags), (tag), offsetof(stname, field),\
#field, ASN1_ITEM_ref(type) }
and
#define ASN1_ITEM_ref(iptr) (&(iptr##_it))
I searched for other symbols used that way. They were implemented using IMPLEMENT_ASN1_TYPE(). I searched all OpenSSL Code for something like that using BIGNUM and didn't find anything. Also I tried to use IMPLEMENT_ASN1_TYPE(BIGNUM) in the code, which resulted in thousands of errors.
Is this something provided from the outside? Do i miss a .c file? If yes, which?
Thanks for your help!
I found the symbol in asn1/x_bignum.c.