1. Maciej Fijalkowski
  2. hippyvm
Issue #1 new

Network/host functions cause problems on OpenBSD

Edd Barrett
created an issue

Hi,

Here is the next hurdle in getting HippyVM working on OpenBSD.

After applying #9 I am faced with the following compilation error:

...
[26f8f] {translation-task
starting compile_c
[platform:execute] make  in /tmp/usession-default-1/testing_1
[platform:Error] data_rpython_jit_metainterp_pyjitpl.c:1603:2: error: 'ntohs' un
declared here (not in a function)
[platform:Error]   ntohs, /* 322 */
[platform:Error]   ^
[platform:Error] data_rpython_jit_metainterp_pyjitpl.c:1686:2: error: 'htonl' un
declared here (not in a function)
[platform:Error]   htonl, /* 405 */
[platform:Error]   ^
[platform:Error] data_rpython_jit_metainterp_pyjitpl.c:1717:2: error: 'htons' un
declared here (not in a function)
[platform:Error]   htons, /* 436 */
[platform:Error]   ^
[platform:Error] gmake: *** [data_rpython_jit_metainterp_pyjitpl.o] Error 1

After a bit of digging, I have a theory.

In OpenBSD these "functions" are actually macros. sys/types.h pulls in sys/endian.h where we have:

#define ntohs(x) __swap16(x)
#define htonl(x) __swap32(x)
#define htons(x) __swap16(x)

The generated files data_rpython_jit_metainterp_pyjitpl.c and nonfuncnodes_3.c use ntohs, htonl and htons as though they are function pointers, hence the compile error. The macros will not be expanded either, since their names are not ending with parenthesis and an argument.

Looking on a Linux machine, these symbols seem to be functions (unless __OPTIMIZE__ is set, yay), so maybe this explains the discrepancy.

I was able to work around this by adding a hack as follows:

/* XXX XXX XXX */
u_int16_t _ntohs(u_int16_t net16) { return ntohs(net16); }                      
u_int32_t _htonl(u_int32_t host32) { return htonl(host32); }                    
u_int16_t _htons(u_int16_t host16) { return htons(host16); }                    
/* XXX XXX XXX */

Then updating all references to ntohs, htonl and htons with _ntohs, _htonl and _htons respectively.

Of course this is not a fix and at this stage I am uncertain as to whether this is actually an RPython bug, rather than a HippyVM bug. What I do know is that the RPython I am using to translate HippyVM successfully translates PyPy.

Does anyone have any input on how I should proceed with this?

Comments (1)

  1. Edd Barrett reporter

    Armin Rigo has pointed me to rpython/rlib/_rsocket_rffi.py where in the definition of these functions I should pass macro=True on platforms where this is the case. Experimenting with this and will send a diff if it works.

  2. Log in to comment