With a bit of fiddling, I have gotten Pyd working on Linux using GDC 0.20.

http://pyd.dsource.org/

SVN repository:
http://svn.dsource.org/projects/pyd/trunk

Some notes:

(1) StackThreads doesn't work on GDC. Therefore, Pyd's support for automatically wrapping opApply doesn't work on Linux. I had already wrapped all of the uses of StackThreads in some version statements, so it was a simple matter to tell CeleriD to just not use StackThreads when compiling with GDC.

(2) Whenever I link an .so together using GDC, it gives me this warning:

/usr/bin/ld: warning: creating a DT_TEXTREL in object.

I have no idea what this means, and the resulting .so works fine, but it's still ominous. Anyone have any insight?

(3) GDC doesn't support using the .ptr property of delegates as an lvalue (and, presumably, the .funcptr property, though I haven't tried it). Using .ptr and .funcptr as lvalues is useful when emulating pointers to member functions (as Pyd does). I have fallen back on the old struct/union trick for now.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Kirk McDonald wrote:
> With a bit of fiddling, I have gotten Pyd working on Linux using GDC 0.20.
> 
> http://pyd.dsource.org/
> 
> SVN repository:
> http://svn.dsource.org/projects/pyd/trunk
> 
> Some notes:
> 
> (1) StackThreads doesn't work on GDC. Therefore, Pyd's support for automatically wrapping opApply doesn't work on Linux. I had already wrapped all of the uses of StackThreads in some version statements, so it was a simple matter to tell CeleriD to just not use StackThreads when compiling with GDC.
> 
> (2) Whenever I link an .so together using GDC, it gives me this warning:
> 
> /usr/bin/ld: warning: creating a DT_TEXTREL in object.
> 
> I have no idea what this means, and the resulting .so works fine, but it's still ominous. Anyone have any insight?
> 
> (3) GDC doesn't support using the .ptr property of delegates as an lvalue (and, presumably, the .funcptr property, though I haven't tried it). Using .ptr and .funcptr as lvalues is useful when emulating pointers to member functions (as Pyd does). I have fallen back on the old struct/union trick for now.

Please report these issues with gdc in bugzilla so that they can be fixed or at least documented.  I'm not sure how carefully david reads the non-D.gnu newsgroups and regardless, just a good habit... :)

The StackThreads issue is unclear.. it could be gdc but might well be stackthreads itself.

Thanks and good work,
Brad

Brad Roberts wrote:
> Kirk McDonald wrote:
>> With a bit of fiddling, I have gotten Pyd working on Linux using GDC 0.20.
>>
>> http://pyd.dsource.org/
>>
>> SVN repository:
>> http://svn.dsource.org/projects/pyd/trunk
>>
>> Some notes:
>>
>> (1) StackThreads doesn't work on GDC. Therefore, Pyd's support for automatically wrapping opApply doesn't work on Linux. I had already wrapped all of the uses of StackThreads in some version statements, so it was a simple matter to tell CeleriD to just not use StackThreads when compiling with GDC.
>>
>> (2) Whenever I link an .so together using GDC, it gives me this warning:
>>
>> /usr/bin/ld: warning: creating a DT_TEXTREL in object.
>>
>> I have no idea what this means, and the resulting .so works fine, but it's still ominous. Anyone have any insight?
>>
>> (3) GDC doesn't support using the .ptr property of delegates as an lvalue (and, presumably, the .funcptr property, though I haven't tried it). Using .ptr and .funcptr as lvalues is useful when emulating pointers to member functions (as Pyd does). I have fallen back on the old struct/union trick for now.
> 
> Please report these issues with gdc in bugzilla so that they can be fixed or at least documented.  I'm not sure how carefully david reads the non-D.gnu newsgroups and regardless, just a good habit... :)
> 
> The StackThreads issue is unclear.. it could be gdc but might well be stackthreads itself.
> 
> Thanks and good work,
> Brad

The StackThreads issue is totally clear. From the source:

    //GDC uses a different calling conventions, need to reverse engineer them later

This just after a version(DigitalMars) block defining some other important version statements. The end result is some very important chunks of code with inline asm aren't used, and thus StackThreads doesn't compile. So it's not that it's broken, it's that GDC support hasn't been written, yet.

As for posting on Bugzilla, I'll do that next.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Brad Roberts wrote:
> 
> The StackThreads issue is unclear.. it could be gdc but might well be stackthreads itself.

It's StackThreads itself.  The code is exclusively DMD/x86 at the moment.


Sean