Re: [Fxruby-users] FXRuby on QNX

[Joel V. <vj...@us...>]

Joel VanderWerf wrote:
> 
> Hi, I've got Fox working on QNX6.2.1, and I've got ruby working, but 
> FXRuby doesn't build for me. Anybody else try this?
> 
> The problems atm have to so with constness in C++:
> 
> /usr/include/string.h: In function `void * memchr(void *, int, unsigned 
> int)':
> /usr/include/string.h:125: declaration of C function `void * memchr(void 
> *, int, unsigned int)' conflicts with
> /usr/include/string.h:49: previous declaration `const void * 
> memchr(const void *, int, unsigned int)' here
> 
> ...and more like that
> 
> When you include string.h with __cplusplus defined, these declarations 
> become inconsistent. I tried a minimal .cpp example (based on hello.cpp 
> from Fox) that includes "string.h", but couldn't recreate the problem. 
> So probably something is misconfigured in FXRuby, but what precisely...

Well, I still don't understand it, but I do have a kludgy workaround. I 
just put the following file in ext/fox/include:

==== ruby.h ====
#include "string.h"
#include "/usr/local/lib/ruby/1.8/i386-nto-qnx6.2.1/ruby.h"
================

This forces string.h to be read without the extern "C" context, which is 
what seems to be causing the problem. It's not really particularly an 
FXRuby problem. It could be solved (I think) by swig-ruby if the 
#include "ruby.h" were preceded by #include "string.h" in the wrap 
files. Or better yet, it could be solved in ruby.h, since this is likely 
to come up with any C++ extension on QNX, by including "string.h" near 
the top of the file (conditional on QNX, I suppose).

Anyway, the FXRuby build succeeds with this change.

Now I have to try to build FXRuby statically when I build ruby, because 
disabling shared objects seems to be necessary on QNX for ruby 
extensions that are linked statically with other libraries. (Or at least 
that's what happens with readline.)