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