On 2010-06-27 12:35, jpf wrote:
Hi,
are you still working on that? I tried to use druntime as a dynamic library on
Linux, and I had exactly the same problem. (version node not found for symbol
_d_th...@4)
Googling showed that this problem has been discussed before:
http://digitalmars.com/d/archives/digitalmars/D/libphobos_as_.so_54793.html

So because of the extern(Windows) / _stdcall calling convention, dmd emits the 
@4
( 
http://en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows
)
If I understand this
http://people.redhat.com/drepper/symbol-versioning
correctly, ELF uses symbol names like _d_th...@4 as n...@version. As there is no
entry for version 4, linking fails. I guess mac is not affected, because Mach-O
accepts _d_th...@4 as a symbol name.

It seems like nothing has changed since then.
http://www.dsource.org/projects/druntime/browser/trunk/src/rt/deh2.d
http://www.dsource.org/projects/druntime/browser/trunk/src/rt/deh.c

_d_throw is still extern(Windows) / _stdcall and i guess dmd would still emit 
calls
to _d_th...@4 if _d_throw was changed to extern(C).

Btw: Someone seems to have found a basic workaround for the name mangling 
problem:
http://www.curoles.com/j/dso/dso.html

But i guess, this should really be fixed in the compiler and druntime.

I've managed to solve the linker error as shown on the last link and then got the same problem (segmentation fault) as on that site. Is this a problem with the compiler or the runtime?

--
/Jacob Carlborg

Reply via email to