Something weird. Pike 8.0.1916 compiles gtk2 fine, but 9.0.10 from git doesn't, 
trying to figure that out.






On Thursday, April 17, 2025 at 04:51:36 PM EDT, H. William Welliver 
<[email protected]> wrote: 





Sorry, I guess I never mentioned that. I’m testing against 9.0, but I suspect 
the problem exists in 8.x as well.

> On Apr 17, 2025, at 4:50 PM, Lance Dillon <[email protected]> wrote:
> 
> Also, is there a specific version you are patching against? 8.0, 8.1, or 9.0?
> 
> 
> 
> 
> 
> 
> 
> On Thursday, April 17, 2025 at 04:46:30 PM EDT, Lance Dillon 
> <[email protected]> wrote: 
> 
> 
> 
> 
> 
> Is this a compile time error, or a runtime error?  If runtime, is there 
> example code you have that seems to trigger it?
> 
> 
> 
> 
> 
> 
> On Thursday, April 17, 2025 at 04:05:16 PM EDT, H. William Welliver 
> <[email protected]> wrote: 
> 
> 
> 
> 
> 
> Hi Lance-
> 
> Thanks for the assistance. I’ve attached the patch to this message, it should 
> detect the presence of GdkNativeWindow. Let me know how it works for you (and 
> the result of that test in the configure output).
> 
> 
> 
> 
>> On Apr 17, 2025, at 3:26 PM, Lance Dillon <[email protected]> wrote:
>> 
>> I could test
>> 
>> Yahoo Mail: Search, Organize, Conquer
>> 
>> 
>>>  
>>>  
>>> On Thu, Apr 17, 2025 at 15:18, H. William Welliver
>>> <[email protected]> wrote:
>>> 
>>> 
>>>  
>>> I compiled pike on a system that has a version of GTK2 that includes a 
>>> typedef for GdkNativeWindow that the GTK2 code doesn’t specifically 
>>> address. The compiler (a recent clang) errors on these implicit casts to 
>>> and from GdkNativeWindow (which I believe resolves to a platform dependent 
>>> pointer) and integers that the pike glue deals with. I was able to solve 
>>> the errors but wanted to get some feedback before I commit it, as I get the 
>>> impression that GdkNativeWindow was something added somewhere along the 
>>> way, so there probably may need to be some configure glue added. Is anyone 
>>> using the GTK2 module that might be able to test these changes to see if 
>>> they cause problems elsewhere? Or should I commit a best-guess fix and wait 
>>> to see how pikefarm reacts?
>>> 
>>> Bill
>>> 
>>> 
> 

Reply via email to