Maintained by: NLnet Labs

[Unbound-users] Compilation error, unbound 1.5.1

Bob Bitdiddle
Sat Mar 14 12:00:46 CET 2015


When using mingw32 inside cygwin on PC, I get a compilation error:




*./libtool --tag=CC --mode=compile i686-pc-mingw32-gcc -I.
-I/usr/local/ssl/include -g -O2 -flto -pthread -o net_help.lo -c
util/net_help.clibtool: compile:  i686-pc-mingw32-gcc -I.
-I/usr/local/ssl/include -g -O2 -flto -pthread -c util/net_help.c
-DDLL_EXPORT -DPIC -o .libs/net_help.outil/net_help.c: In function
'ub_crypto_id_cb':util/net_help.c:768:2: error: aggregate value used where
an integer was expected*

This is because it appears unbound assumes pthread_t will fit inside an
unsigned long, but mingw32 defines it thusly:











*/* * Generic handle type - intended to extend uniqueness beyond * that
available with a simple pointer. It should scale for either * IA-32 or
IA-64. */typedef struct {    void * p;                   /* Pointer to
actual object */    unsigned int x;             /* Extra information -
reuse count etc */} ptw32_handle_t;typedef ptw32_handle_t pthread_t;*

So the* void CRYPTO_set_id_callback(unsigned long (*func)(void));* API
provided by openssl doesn't seem to work here.  However, in the crypto.h
header file provided by openssl I also see the following APIs:















*/* Don't use this structure directly. */typedef struct
crypto_threadid_st    {    void *ptr;    unsigned long val;    }
CRYPTO_THREADID;/* Only use CRYPTO_THREADID_set_[numeric|pointer]() within
callbacks */void CRYPTO_THREADID_set_numeric(CRYPTO_THREADID *id, unsigned
long val);void CRYPTO_THREADID_set_pointer(CRYPTO_THREADID *id, void
*ptr);int CRYPTO_THREADID_set_callback(void
(*threadid_func)(CRYPTO_THREADID *));void
(*CRYPTO_THREADID_get_callback(void))(CRYPTO_THREADID *);void
CRYPTO_THREADID_current(CRYPTO_THREADID *id);int CRYPTO_THREADID_cmp(const
CRYPTO_THREADID *a, const CRYPTO_THREADID *b);void
CRYPTO_THREADID_cpy(CRYPTO_THREADID *dest, const CRYPTO_THREADID
*src);unsigned long CRYPTO_THREADID_hash(const CRYPTO_THREADID *id);*

Presumably these could be used to rewrite the code path that's apparently
assuming an unsigned long at the moment.  Should unbound be converted over
to use these APIs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20150314/c9dd72a6/attachment.html>