www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D hates to be dynamic linked

reply g <g g.g> writes:
it is a real pain trying to make a plugin from d.
I love D2 but I would even abandon it if there is solution with a compiler that
at least supports D1 and has a solution for dynamic linking.
Maybe I'm stupid, but tried dmd and ldc (and tango and phobos). And I don't
know if I want to go GDC.
It is so frustrating that DDL was abandoned, even I grabbed a external branch
an is not so outdated, but probably outdated and w/o documentation.
(btw linux)

is there a not so painful way of making plugins?. Or is there still opportunity
with DDL?

I'm open to both phobos, tango, D1 D2

We NEED a way to make plugins from d. And is a must to use freely the features
of D with out getting dirty (or not so dirty) or worse, limited to some features

/*and for your pleasure some of the pain:
-------------------------------------------------------
g-desktop:~/dynamic/ddl/ddl/Samples$ xfbuild +cldc -L-Wl,-Map
-L-Wl,testHost01.map testHost01.d -I../.. -I/home/g2/ldc/import +oftest01 
.objs/host.o: In function
`_D3ddl11ExportClass44__T11ExportClassTC11testIface0110IHasFooBarZ11ExportClass14__T9newObjectZ9newObjectMFZC11testIface0110IHasFooBar':
host:(.gnu.linkonce.t._D3ddl11ExportClass44__T11ExportClassTC11testIface0110IHasFooBarZ11ExportClass14__T9newObjectZ9newObjectMFZC11testIface01
0IHasFooBar+0x214): undefined reference to `_d_newclass'
.objs/ddl-elf-ELFObjLoader.o:(.rodata+0x28): undefined reference to
`_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14getLibraryTypeMFZAa'
.objs/ddl-elf-ELFObjLoader.o:(.rodata+0x2c): undefined reference to
`_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14canLoadLibraryMFS3ddl10FileBuffer10FileBufferZb'
.objs/ddl-elf-ELFObjLoader.o:(.rodata+0x30): undefined reference to
`_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader4loadMFC3ddl14LoaderRegistry14LoaderRegistryS3ddl10FileBuffer10FileBufferZC3ddl14DynamicLibrary14DynamicLibrary'
.objs/ddl-DynamicLibrary.o:(.rodata+0x28): undefined reference to
`_D3ddl14DynamicLibrary14DynamicLibrary9getSymbolMFAaZPS3ddl12ExportSymbol12ExportSymbol'
.objs/ddl-DynamicLibrary.o:(.rodata+0x2c): undefined reference to
`_D3ddl14DynamicLibrary14DynamicLibrary10getModulesMFZAC3ddl13DynamicModule13DynamicModule'
.objs/ddl-DynamicLibrary.o:(.rodata+0x30): undefined reference to
`_D3ddl14DynamicLibrary14DynamicLibrary7getTypeMFZAa'
.objs/ddl-DynamicLibrary.o:(.rodata+0x34): undefined reference to
`_D3ddl14DynamicLibrary14DynamicLibrary13getAttributesMFZHAaAa'
.objs/ddl-DynamicLibrary.o:(.rodata+0x3c): undefined reference to
`_D3ddl14DynamicLibrary14DynamicLibrary18getModuleForSymbolMFAaZC3ddl13DynamicModule13DynamicModule'
.objs/ddl-DynamicLibrary.o:(.rodata+0x40): undefined reference to
`_D3ddl14DynamicLibrary14DynamicLibrary11getResourceMFAaZAh'
.objs/ddl-DynamicModule.o:(.rodata+0x28): undefined reference to
`_D3ddl13DynamicModule13DynamicModule7getNameMFZAa'
.objs/ddl-DynamicModule.o:(.rodata+0x38): undefined reference to
`_D3ddl13DynamicModule13DynamicModule10getSymbolsMFZAS3ddl12ExportSymbol12ExportSymbol'
.objs/ddl-DynamicModule.o:(.rodata+0x3c): undefined reference to
`_D3ddl13DynamicModule13DynamicModule9getSymbolMFAaZPS3ddl12ExportSymbol12ExportSymbol'
.objs/ddl-DynamicModule.o:(.rodata+0x40): undefined reference to
`_D3ddl13DynamicModule13DynamicModule20getSymbolLineNumbersMFZAS3ddl16SymbolLineNumber16SymbolLineNumber'
.objs/ddl-DynamicModule.o:(.rodata+0x44): undefined reference to
`_D3ddl13DynamicModule13DynamicModule13resolveFixupsMFZv'
.objs/ddl-DynamicModule.o:(.rodata+0x48): undefined reference to
`_D3ddl13DynamicModule13DynamicModule10isResolvedMFZb'
.objs/ddl-DynamicLibraryLoader.o:(.rodata+0x28): undefined reference to
`_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14getLibraryTypeMFZAa'
.objs/ddl-DynamicLibraryLoader.o:(.rodata+0x2c): undefined reference to
`_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14canLoadLibraryMFS3ddl10FileBuffer10FileBufferZb'
.objs/ddl-DynamicLibraryLoader.o:(.rodata+0x30): undefined reference to
`_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader4loadMFC3ddl14LoaderRegistry14LoaderRegistryS3ddl10FileBuffer10FileBufferZC3ddl14DynamicLibrary14DynamicLibrary'
collect2: ld returned 1 exit status
-------------------------
sorry if that was pointless*/

sorry if *this* is pointless. (I'm a bit frustrateh)
Feb 19 2010
next sibling parent reply "Craig Black" <craigblack2 cox.net> writes:
I am sorry to hear about your problem, and I'm sure there are others who 
share your pain.  If it is any consolation it is helpful to me to hear this, 
since the software that I intend to port to D relies heavily on plug-ins. 
It is disappointing that something as fundamental as plug-ins are such an 
issue in D.  There has been recent talks about adding support for dynamic 
linking, but it doesn't seem to be a high enough priority yet.  Hopefully it 
will get some attention soon.

-Craig

"g" <g g.g> wrote in message news:hln0i0$dm3$1 digitalmars.com...
 it is a real pain trying to make a plugin from d.
 I love D2 but I would even abandon it if there is solution with a compiler 
 that at least supports D1 and has a solution for dynamic linking.
 Maybe I'm stupid, but tried dmd and ldc (and tango and phobos). And I 
 don't know if I want to go GDC.
 It is so frustrating that DDL was abandoned, even I grabbed a external 
 branch an is not so outdated, but probably outdated and w/o documentation.
 (btw linux)

 is there a not so painful way of making plugins?. Or is there still 
 opportunity with DDL?

 I'm open to both phobos, tango, D1 D2

 We NEED a way to make plugins from d. And is a must to use freely the 
 features of D with out getting dirty (or not so dirty) or worse, limited 
 to some features

 /*and for your pleasure some of the pain:
 -------------------------------------------------------
 g-desktop:~/dynamic/ddl/ddl/Samples$ xfbuild 
 +cldc -L-Wl,-Map -L-Wl,testHost01.map 
 testHost01.d -I../.. -I/home/g2/ldc/import +oftest01
 .objs/host.o: In function 
 `_D3ddl11ExportClass44__T11ExportClassTC11testIface0110IHasFooBarZ11ExportClass14__T9newObjectZ9newObjectMFZC11testIface0110IHasFooBar':
 host:(.gnu.linkonce.t._D3ddl11ExportClass44__T11ExportClassTC11testIface0110IHasFooBarZ11ExportClass14__T9newObjectZ9newObjectMFZC11testIface01
0IHasFooBar+0x214): 
 undefined reference to `_d_newclass'
 .objs/ddl-elf-ELFObjLoader.o:(.rodata+0x28): undefined reference to 
 `_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14getLibraryTypeMFZAa'
 .objs/ddl-elf-ELFObjLoader.o:(.rodata+0x2c): undefined reference to 
 `_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14canLoadLibraryMFS3ddl10FileBuffer10FileBufferZb'
 .objs/ddl-elf-ELFObjLoader.o:(.rodata+0x30): undefined reference to 
 `_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader4loadMFC3ddl14LoaderRegistry14LoaderRegistryS3ddl10FileBuffer10FileBufferZC3ddl14DynamicLibrary14DynamicLibrary'
 .objs/ddl-DynamicLibrary.o:(.rodata+0x28): undefined reference to 
 `_D3ddl14DynamicLibrary14DynamicLibrary9getSymbolMFAaZPS3ddl12ExportSymbol12ExportSymbol'
 .objs/ddl-DynamicLibrary.o:(.rodata+0x2c): undefined reference to 
 `_D3ddl14DynamicLibrary14DynamicLibrary10getModulesMFZAC3ddl13DynamicModule13DynamicModule'
 .objs/ddl-DynamicLibrary.o:(.rodata+0x30): undefined reference to 
 `_D3ddl14DynamicLibrary14DynamicLibrary7getTypeMFZAa'
 .objs/ddl-DynamicLibrary.o:(.rodata+0x34): undefined reference to 
 `_D3ddl14DynamicLibrary14DynamicLibrary13getAttributesMFZHAaAa'
 .objs/ddl-DynamicLibrary.o:(.rodata+0x3c): undefined reference to 
 `_D3ddl14DynamicLibrary14DynamicLibrary18getModuleForSymbolMFAaZC3ddl13DynamicModule13DynamicModule'
 .objs/ddl-DynamicLibrary.o:(.rodata+0x40): undefined reference to 
 `_D3ddl14DynamicLibrary14DynamicLibrary11getResourceMFAaZAh'
 .objs/ddl-DynamicModule.o:(.rodata+0x28): undefined reference to 
 `_D3ddl13DynamicModule13DynamicModule7getNameMFZAa'
 .objs/ddl-DynamicModule.o:(.rodata+0x38): undefined reference to 
 `_D3ddl13DynamicModule13DynamicModule10getSymbolsMFZAS3ddl12ExportSymbol12ExportSymbol'
 .objs/ddl-DynamicModule.o:(.rodata+0x3c): undefined reference to 
 `_D3ddl13DynamicModule13DynamicModule9getSymbolMFAaZPS3ddl12ExportSymbol12ExportSymbol'
 .objs/ddl-DynamicModule.o:(.rodata+0x40): undefined reference to 
 `_D3ddl13DynamicModule13DynamicModule20getSymbolLineNumbersMFZAS3ddl16SymbolLineNumber16SymbolLineNumber'
 .objs/ddl-DynamicModule.o:(.rodata+0x44): undefined reference to 
 `_D3ddl13DynamicModule13DynamicModule13resolveFixupsMFZv'
 .objs/ddl-DynamicModule.o:(.rodata+0x48): undefined reference to 
 `_D3ddl13DynamicModule13DynamicModule10isResolvedMFZb'
 .objs/ddl-DynamicLibraryLoader.o:(.rodata+0x28): undefined reference to 
 `_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14getLibraryTypeMFZAa'
 .objs/ddl-DynamicLibraryLoader.o:(.rodata+0x2c): undefined reference to 
 `_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader14canLoadLibraryMFS3ddl10FileBuffer10FileBufferZb'
 .objs/ddl-DynamicLibraryLoader.o:(.rodata+0x30): undefined reference to 
 `_D3ddl20DynamicLibraryLoader20DynamicLibraryLoader4loadMFC3ddl14LoaderRegistry14LoaderRegistryS3ddl10FileBuffer10FileBufferZC3ddl14DynamicLibrary14DynamicLibrary'
 collect2: ld returned 1 exit status
 -------------------------
 sorry if that was pointless*/

 sorry if *this* is pointless. (I'm a bit frustrateh) 

Feb 19 2010
parent Justin Johansson <no spam.com> writes:
Let me preface by saying that I generally try not to be negative and
have a heaps of praise and hope for what the D language and library
designers are attempting to do.  I don't want to spoil the party,
however I think it's fair to recount my own real-world (*) D
experience.

(*) The success or otherwise of the project I'm working on
literally == food or no food to put on my table.  We are not
talking about a hobby; it's a serious pursuit of my livelihood.

Accordingly ...


Commiserations dear friends.

If it is any extra comfort to also share your pain alongside Craig
et. al., let me tell you that I am (was) much in the same boat.

Having spent six months 12x7 working a project in D1, and hoping
that dynamic linking issues (**), might eventually be resolved, I
gave up on D for serious biz.

(**) Shared objects for the Linux platform, though ultimately aiming
for Windows DLLs and a general cross-platform plug-in architecture.

As a result of D's limitations in this regard, I was forced to
back-port my project to C++ some 8 weeks ago.

Now using Eclipse + C Dev Tools (CDT) and GCC as the IDE and
tool-chain respectively, I feel I'm back to really cooking on gas
once again.

"Oh C++, why did I ever leave you?"

Like yourselves, also having previously raised concerns re
dyna-linking on this NG before, most responses from the top to
both my and other users posts on this very topic have generally
been dismissive of the problem.

However, for me, and apart from all the other issues and
frustrations that *you all know about* with D, the dyna-link thing
was the thing that broke the camel's back, becoming the
ultimate show-stopper.

All was not lost though, I learned quite a few things from my 6
month experience with D that have helped to improve my C++ style,
that which was becoming a bit stale after 20 years of it.

To summarize, my feeling is that D is a great experimental language
but you would not want to bet your farm, let alone your life, on it.

Hopefully with the finalization of D2 and publication of TDPL,
things will start to turn around.  One would also hope that by this
time some higher priority will be assigned to taking care of some
of the more menial, yet absolutely fundamental issues affecting
the real-world development and deployment of D applications.

Sincerely, and with best wishes for D,

Justin Johansson


Craig Black wrote:
 I am sorry to hear about your problem, and I'm sure there are others who
 share your pain.  If it is any consolation it is helpful to me to hear
 this, since the software that I intend to port to D relies heavily on
 plug-ins. It is disappointing that something as fundamental as plug-ins
 are such an issue in D.  There has been recent talks about adding
 support for dynamic linking, but it doesn't seem to be a high enough
 priority yet.  Hopefully it will get some attention soon.

 -Craig

 "g" <g g.g> wrote in message news:hln0i0$dm3$1 digitalmars.com...
 it is a real pain trying to make a plugin from d.
 I love D2 but I would even abandon it if there is solution with a
 compiler that at least supports D1 and has a solution for dynamic
 linking.
 Maybe I'm stupid, but tried dmd and ldc (and tango and phobos). And I
 don't know if I want to go GDC.
 It is so frustrating that DDL was abandoned, even I grabbed a external
 branch an is not so outdated, but probably outdated and w/o
 documentation.
 (btw linux)

 is there a not so painful way of making plugins?. Or is there still
 opportunity with DDL?

 I'm open to both phobos, tango, D1 D2

 We NEED a way to make plugins from d. And is a must to use freely the
 features of D with out getting dirty (or not so dirty) or worse,
 limited to some features


Feb 19 2010
prev sibling next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Fri, 19 Feb 2010 16:41:20 -0500, g wrote:

 it is a real pain trying to make a plugin from d. I love D2 but I would
 even abandon it if there is solution with a compiler that at least
 supports D1 and has a solution for dynamic linking.

There's no way through. I was well on the way to something like Tomcat for D when it dawned on me that which ever way you turn, there's no support for dynamic loading - GDC included (shared libraries don't work). I tried to get some attention for this problem again a couple of weeks ago (see the "special treat" thread), and everyone who replied said "yes, we really need this", but Walter does not want to go there. I just don't understand why this is not at the top of the urgent problems list, unless as I've said before D is just a language that forms a basis for the discussion of cool features that should be in compilers. If that's the case we can all continue to visit the D newsgroups for some intellectual stimulation (in Brit speak that's called intellectual wanking). But for the job, we're stuck with C++, C#, or Java. So sad! Steve
Feb 20 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-02-20 16.53, Steve Teale wrote:
 On Fri, 19 Feb 2010 16:41:20 -0500, g wrote:

 it is a real pain trying to make a plugin from d. I love D2 but I would
 even abandon it if there is solution with a compiler that at least
 supports D1 and has a solution for dynamic linking.

There's no way through. I was well on the way to something like Tomcat for D when it dawned on me that which ever way you turn, there's no support for dynamic loading - GDC included (shared libraries don't work).

I've made a few dynamic libraries on Mac OS X that work.
 I tried to get some attention for this problem again a couple of weeks
 ago (see the "special treat" thread), and everyone who replied said "yes,
 we really need this", but Walter does not want to go there.

 I just don't understand why this is not at the top of the urgent problems
 list, unless as I've said before D is just a language that forms a basis
 for the discussion of cool features that should be in compilers. If
 that's the case we can all continue to visit the D newsgroups for some
 intellectual stimulation (in Brit speak that's called intellectual
 wanking). But for the job, we're stuck with C++, C#, or Java.

 So sad!

 Steve

Feb 20 2010
prev sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Steve Teale wrote:

 On Fri, 19 Feb 2010 16:41:20 -0500, g wrote:
 
 it is a real pain trying to make a plugin from d. I love D2 but I would
 even abandon it if there is solution with a compiler that at least
 supports D1 and has a solution for dynamic linking.

There's no way through. I was well on the way to something like Tomcat for D when it dawned on me that which ever way you turn, there's no support for dynamic loading - GDC included (shared libraries don't work). I tried to get some attention for this problem again a couple of weeks ago (see the "special treat" thread), and everyone who replied said "yes, we really need this", but Walter does not want to go there. I just don't understand why this is not at the top of the urgent problems list, unless as I've said before D is just a language that forms a basis for the discussion of cool features that should be in compilers. If that's the case we can all continue to visit the D newsgroups for some intellectual stimulation (in Brit speak that's called intellectual wanking). But for the job, we're stuck with C++, C#, or Java. So sad! Steve

Well, obviously, there are more pressing things from Walter's perspective. For many programs, dynamic libraries are irrelevant, and there are major issues which are relevant to any programming project in D - dynamically linked or otherwise. So, presumably those are more important. I'm sure that dynamically linked libraries will get to the top of the priority queue eventually, but it looks like those who need it will just have to hold tight for now - as irritating as that may be. Being vocal about it might help push it up, though it might not (Walter tends to care about what he cares about whatever others might say). If it's a true showstopper for you, you can always contribute towards getting it working. Most programs can be written just fine without dynamically linked libraries, so I can certainly see why Walter would not consider it a high priority with everything else on his plate, but I do hope that he gets to it eventually. - Jonathan M Davis
Feb 20 2010
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Jonathan M Davis Wrote:

 Most programs can be written just fine without dynamically linked libraries, 
 so I can certainly see why Walter would not consider it a high priority with 
 everything else on his plate, but I do hope that he gets to it eventually.
 

I disagree here. Yes they can be written, but at some point in time deveopers rewrite it using plugin architecture. From software that I use everyday plugginalble are: file manager(gnome), messenger(pidgin), browser(plugins of different taste, but nevertheless), IDEs(most of them: MSVC, Qt Creator, Eclipse...). I work for the company and all of its software is plugins to bigger programs...
Feb 21 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
g wrote:
 (btw linux)

The first step is to make phobos into a shared .so library. Is anyone willing to try it and sort out just what the issues are?
Feb 21 2010
next sibling parent reply Igor Lesik <curoles yahoo.com> writes:
The first step is to make phobos into a shared .so library. Is anyone willing
to try it and sort out just what the issues are?

I may give it a try, if nobody else wants to jump on it.
Feb 21 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Igor Lesik wrote:
 The first step is to make phobos into a shared .so library. Is
 anyone willing to try it and sort out just what the issues are?

I may give it a try, if nobody else wants to jump on it.

Thanks! dmd has the first step, it supports -fPIC.
Feb 21 2010
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-02-21 19.50, Walter Bright wrote:
 g wrote:
 (btw linux)

The first step is to make phobos into a shared .so library. Is anyone willing to try it and sort out just what the issues are?

I've been trying to do this from time to time on Mac OS X, I've also tried with tango. The issues I've encountered are undefined symbols: Undefined symbols: "__deh_beg", referenced from: __deh_beg$non_lazy_ptr in deh2.o "__deh_end", referenced from: __deh_end$non_lazy_ptr in deh2.o "__Dmain", referenced from: _main in dmain2.o _main in dmain2.o "__minfo_beg", referenced from: __minfo_beg$non_lazy_ptr in moduleinit.o "__minfo_end", referenced from: __minfo_end$non_lazy_ptr in moduleinit.o GDC doesn't have this problem. This is how GDC solves some of the above undefined symbols: __Dmain: GDC doesn't have the C and D main functions in dmain2.d, instead it has another file with the main functions that should not be linked if you build it as a dynamic/shared library. I tried to do this with tango and dmd but then when I built a executable I got undefined symbol on the C main function. __minfo_beg and __minfo_end: Neither GDC or LDC have these. I don't remember how they handle this but it can probably be solved using the function "getsegbyname" or any of the similar functions that exist. For this I would need more precise information in which segment and section they are located. __deh_beg and __deh_end: Both GDC and LDC uses a different exception handling implementation than dmd and don't have these. I have no idea what to do about these. /Jacob Carlborg
Feb 22 2010
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Sun, 21 Feb 2010 16:05:47 -0800, Walter Bright wrote:

 Igor Lesik wrote:
 The first step is to make phobos into a shared .so library. Is anyone
 willing to try it and sort out just what the issues are?

I may give it a try, if nobody else wants to jump on it.

Thanks! dmd has the first step, it supports -fPIC.

So it's real? There's still something wrong though - I had a big bash at shared library about a week ago - no joy. Great Walter - thanks. Igor - please get in touch, I may be able to help. Steve
Feb 24 2010
prev sibling parent Igor Lesik <curoles yahoo.com> writes:
 Igor Lesik wrote:
 The first step is to make phobos into a shared .so library. Is anyone
 willing to try it and sort out just what the issues are?

I may give it a try, if nobody else wants to jump on it.

Thanks! dmd has the first step, it supports -fPIC.

So it's real? There's still something wrong though - I had a big bash at shared library about a week ago - no joy. Great Walter - thanks. Igor - please get in touch, I may be able to help. Steve

Sure. Most probably I will need help. Thanks.
Feb 24 2010