fxruby-users

[Fxruby-users] FXRuby on QNX

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

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...

[Fxruby-users] FXRuby on QNX

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

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...

Re: [Fxruby-users] FXRuby on QNX

[Lyle J. <ly...@kn...>]

On Feb 12, 2004, at 7:06 PM, 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...

That's a new one. Which file(s) from FXRuby is it trying to compile 
when you get this error message?

When you compile code with a C++ compiler, the compiler's supposed to 
(internally) define the __cplusplus symbol. And what I would expect to 
see in a header file like string.h, if there is a "C version" of 
memchr() and a "C++ version" of memchr(), would be something like this:

	#ifdef __cplusplus
	// Here's the C++ declaration...
	const void * memchr(const void *, int, unsigned int);
	#else
	/* Here's the C declaration, without const */
	void * memchr(void *, int, unsigned int);
	#endif

That is, I'd expect the compiler to see one or the other, but not both!

Re: [Fxruby-users] FXRuby on QNX

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

Lyle Johnson wrote:
> 
> On Feb 12, 2004, at 7:06 PM, 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...
> 
> 
> That's a new one. Which file(s) from FXRuby is it trying to compile when 
> you get this error message?

It's in core_wrap.cpp (full error log attached).

> When you compile code with a C++ compiler, the compiler's supposed to 
> (internally) define the __cplusplus symbol. And what I would expect to 
> see in a header file like string.h, if there is a "C version" of 
> memchr() and a "C++ version" of memchr(), would be something like this:
> 
>     #ifdef __cplusplus
>     // Here's the C++ declaration...
>     const void * memchr(const void *, int, unsigned int);
>     #else
>     /* Here's the C declaration, without const */
>     void * memchr(void *, int, unsigned int);
>     #endif
> 
> That is, I'd expect the compiler to see one or the other, but not both!

Here's some more of string.h:

      40  #ifdef __cplusplus
      41   #define _Const_return const
      42  #else
      43   #define _Const_return
      44  #endif
      45
      46  __BEGIN_DECLS
      47
      48  _C_STD_BEGIN
      49  extern _Const_return void *memchr( const void *__s, int __c,
size_t __n );


     122  #ifdef __cplusplus
     123  _C_STD_BEGIN
     124  inline void *memchr(void *_S, int _C, _CSTD size_t _N)
     125          {       /* call with const first argument */


So, from the error messages, it's pretty clear that __cplusplus is
defined at both locations. Looks pretty inconsistent to me, but somehow
building Fox and its examples didn't produce the message.

One of our local QNX programmers had this comment:

> I've encountered problems something like what you are talking about
> with the memchr definition conflict when a package has an ifdef __QNX__
> somewhere that really sets things up for QNX4 and you have to
> change it to if defined(__QNX__) && !defined(__QNXNTO__) (I may not
> have the predefined compiler variables named exactly correctly) because
> the substitution is incorrect for QNX6.

But I don't see any testing of QNX or qnx in the FXRuby source (in fact
those strings don't occur anywhere).

We'll take a look at it together tomorrow, and I'll let you know if we
get anywhere.

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.)