www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cross-platform DLL's

reply "Craig Black" <cblack ara.com> writes:
When will D be able to compile the same source to a .dll on windows and a 
.so on Linux?

Thanks,

-Craig 
Jun 05 2006
parent reply kris <foo bar.com> writes:
Craig Black wrote:
 When will D be able to compile the same source to a .dll on windows and a 
 .so on Linux?

ddl may resolve this
Jun 05 2006
next sibling parent reply "Craig Black" <cblack ara.com> writes:
"kris" <foo bar.com> wrote in message news:e624e1$du6$1 digitaldaemon.com...
 Craig Black wrote:
 When will D be able to compile the same source to a .dll on windows and a 
 .so on Linux?

ddl may resolve this

Yeah, I guess what I should be asking is, When will DDL 1.0 be available? -Craig
Jun 05 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Craig Black wrote:

 
 "kris" <foo bar.com> wrote in message
 news:e624e1$du6$1 digitaldaemon.com...
 Craig Black wrote:
 When will D be able to compile the same source to a .dll on windows and
 a .so on Linux?

ddl may resolve this

Yeah, I guess what I should be asking is, When will DDL 1.0 be available? -Craig

When it's done ;) Anyway, it's not a very high probability for ELF support being in there. You can follow the progress in the forum at DSource, or at the Trac page. http://www.dsource.org/projects/ddl -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jun 05 2006
prev sibling parent pragma <pragma_member pathlink.com> writes:
In article <e6262v$h39$1 digitaldaemon.com>, Craig Black says...
"kris" <foo bar.com> wrote in message news:e624e1$du6$1 digitaldaemon.com...
 Craig Black wrote:
 When will D be able to compile the same source to a .dll on windows and a 
 .so on Linux?

ddl may resolve this

Yeah, I guess what I should be asking is, When will DDL 1.0 be available?

Well, Lars said it best. The only thing that's keeping an official 1.0 release off the table has been the documentation and the remaining kinks in the OMF loader - I will be applying a new bugfix later tonight. By far and large, DDL is already here and in a usable state. - EricAnderton at yahoo
Jun 05 2006
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <e624e1$du6$1 digitaldaemon.com>, kris says...
Craig Black wrote:
 When will D be able to compile the same source to a .dll on windows and a 
 .so on Linux?

ddl may resolve this

Possibly. The trick here is that Walter has ruled out the possibility of 100% binary compatibility so using DDL 1.0 as a compile-once* solution is a no-go. But should Craig need something that fits the use-case of a dll/so, as a complete D-built dynamic lib, then DDL should work nicely. * - Some food for thought here: As the ABI below the D compiler level is concerned, DMD backs DMC and GDC backs GCC where exception handling and real-width (80/100bit) are concerned. This is a good thing as far as linking with 'native' dynamic and static libs go. While all this puts the current toolset out of the running, it doesn't exclude the possibility of producing completely cross-platform binary solution, at the cost of legacy binary compatibility. It would just require a custom compiler that backs a stricter ABI (maybe by the time we land on the moon again). - EricAnderton at yahoo
Jun 05 2006
parent reply kris <foo bar.com> writes:
pragma wrote:
 In article <e624e1$du6$1 digitaldaemon.com>, kris says...
 
Craig Black wrote:

When will D be able to compile the same source to a .dll on windows and a 
.so on Linux?

ddl may resolve this

Possibly. The trick here is that Walter has ruled out the possibility of 100% binary compatibility so using DDL 1.0 as a compile-once* solution is a no-go. But should Craig need something that fits the use-case of a dll/so, as a complete D-built dynamic lib, then DDL should work nicely. * - Some food for thought here: As the ABI below the D compiler level is concerned, DMD backs DMC and GDC backs GCC where exception handling and real-width (80/100bit) are concerned. This is a good thing as far as linking with 'native' dynamic and static libs go. While all this puts the current toolset out of the running, it doesn't exclude the possibility of producing completely cross-platform binary solution, at the cost of legacy binary compatibility. It would just require a custom compiler that backs a stricter ABI (maybe by the time we land on the moon again). - EricAnderton at yahoo

Perhaps cross-platform binaries might come in useful for those who need to hide the implementation. But for the rest of us, just having a single source base that operates on both (without the need to master the underlying relevant ddl/so mechanics) will be awesome! I suspect it's the latter that Craig was getting at?
Jun 05 2006
parent reply "Craig Black" <cblack ara.com> writes:
"kris" <foo bar.com> wrote in message 
news:e62loh$18ot$1 digitaldaemon.com...
 pragma wrote:
 In article <e624e1$du6$1 digitaldaemon.com>, kris says...

Craig Black wrote:

When will D be able to compile the same source to a .dll on windows and 
a .so on Linux?

ddl may resolve this

Possibly. The trick here is that Walter has ruled out the possibility of 100% binary compatibility so using DDL 1.0 as a compile-once* solution is a no-go. But should Craig need something that fits the use-case of a dll/so, as a complete D-built dynamic lib, then DDL should work nicely.


Compile-once would be very cool, but it is not necessary for my purposes, so I suppose DDL will solve my problems. I also hear DDL provides run-time reflection. I am very interested in this feature. How does it do this? What is the API look like?
 * - Some food for thought here: As the ABI below the D compiler level is
 concerned, DMD backs DMC and GDC backs GCC where exception handling and
 real-width (80/100bit) are concerned.  This is a good thing as far as 
 linking
 with 'native' dynamic and static libs go.  While all this puts the 
 current
 toolset out of the running, it doesn't exclude the possibility of 
 producing
 completely cross-platform binary solution, at the cost of legacy binary
 compatibility.  It would just require a custom compiler that backs a 
 stricter
 ABI (maybe by the time we land on the moon again).

 - EricAnderton at yahoo

Perhaps cross-platform binaries might come in useful for those who need to hide the implementation. But for the rest of us, just having a single source base that operates on both (without the need to master the underlying relevant ddl/so mechanics) will be awesome! I suspect it's the latter that Craig was getting at?

Yes. And much thanks to you and all the other contributors that have made DDL a possibility. If it is what I understand it is, I am somewhat in awe that you have been able to pull it off. -Craig
Jun 06 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <e64858$mr3$1 digitaldaemon.com>, Craig Black says...
Compile-once would be very cool, but it is not necessary for my purposes, so 
I suppose DDL will solve my problems.  I also hear DDL provides run-time 
reflection.  I am very interested in this feature.  How does it do this? 
What is the API look like?

It doesn't do reflection per-se, but it provides the underpinnings to build a runtime reflection system (sans attributes, codegen and AOP of course). In a nutshell, DDL exposes a generic interface for accessing the runtime symbol information for *everything* within the current D executable. If the linker can see it, DDL can see it. All a formal reflection API needs is to intellegently demangle and process this symbol info on demand. At present, DDL does provide some rudimentary reflection via templates for the purposes of binding functions and fields out of loaded binaries - but that's about it. This is about as reflective as DLL or .so files, give or take a bit.
 Perhaps cross-platform binaries might come in useful for those who need to 
 hide the implementation. But for the rest of us, just having a single 
 source base that operates on both (without the need to master the 
 underlying relevant ddl/so mechanics) will be awesome! I suspect it's the 
 latter that Craig was getting at?

Yes. And much thanks to you and all the other contributors that have made DDL a possibility. If it is what I understand it is, I am somewhat in awe that you have been able to pull it off.

Thank you, but don't count yer chickens yet. ;) It does work as-is, but there's some considerable work to be done. Right now, communal data records* are kicking my butt and threating a minor API change - it seems I'm still learning the corner-cases of the OMF. That aside, I am completely confident in the theory behind DDL and what it will do when complete. - EricAnderton at yahoo
Jun 06 2006
parent reply "Craig Black" <cblack ara.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:e64dot$u1q$1 digitaldaemon.com...
 In article <e64858$mr3$1 digitaldaemon.com>, Craig Black says...
Compile-once would be very cool, but it is not necessary for my purposes, 
so
I suppose DDL will solve my problems.  I also hear DDL provides run-time
reflection.  I am very interested in this feature.  How does it do this?
What is the API look like?

It doesn't do reflection per-se, but it provides the underpinnings to build a runtime reflection system (sans attributes, codegen and AOP of course). In a nutshell, DDL exposes a generic interface for accessing the runtime symbol information for *everything* within the current D executable. If the linker can see it, DDL can see it. All a formal reflection API needs is to intellegently demangle and process this symbol info on demand. At present, DDL does provide some rudimentary reflection via templates for the purposes of binding functions and fields out of loaded binaries - but that's about it. This is about as reflective as DLL or .so files, give or take a bit.

So is it possible to traverse all methods of a given class? What about fields?
 Perhaps cross-platform binaries might come in useful for those who need 
 to
 hide the implementation. But for the rest of us, just having a single
 source base that operates on both (without the need to master the
 underlying relevant ddl/so mechanics) will be awesome! I suspect it's 
 the
 latter that Craig was getting at?

Yes. And much thanks to you and all the other contributors that have made DDL a possibility. If it is what I understand it is, I am somewhat in awe that you have been able to pull it off.

Thank you, but don't count yer chickens yet. ;) It does work as-is, but there's some considerable work to be done. Right now, communal data records* are kicking my butt and threating a minor API change - it seems I'm still learning the corner-cases of the OMF. That aside, I am completely confident in the theory behind DDL and what it will do when complete. - EricAnderton at yahoo

I am looking forward to the official 1.0 release. -Craig
Jun 06 2006
parent pragma <pragma_member pathlink.com> writes:
In article <e64k6p$1660$1 digitaldaemon.com>, Craig Black says...
[snip stuff DDL Q&A]

So is it possible to traverse all methods of a given class?  What about 
fields?

It is absolutely possible - the name-mangling spec provides more than enough information to make that work. But as I mentioned before, its kind of outside the scope of DDL as it presently stands. - EricAnderton at yahoo
Jun 06 2006