[Unbound-users] Compilation error, unbound 1.5.1

[Bob Bitdiddle]

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?

[W.C.A. Wijngaards]

Hi Bob,

Post by Bob Bitdiddle
*./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.c libtool: 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.o util/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

Fixed in the code repository. It uses unbound's internal thread
numbers (0,1,2..).

Best regards,
Wouter

Post by Bob Bitdiddle
* /* * 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
*/* 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?
_______________________________________________ Unbound-users
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users