www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Trying to build Tango as dynamic library on linux

reply Jacob Carlborg <doob me.com> writes:
I though I would try to build tango as a dynamic library with dmd on 
linux, just as I did on mac. Now, I have basically no experiences at all 
developing on linux. I thought that I should try building first before 
fixing the known problems. This is the first error I encountered 
building tango as a dynamic library:

/usr/bin/ld: libtango.so.1.0: version node not found for symbol _d_throw 4
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
--- errorlevel 1

I first build all the files with dmd using the "-fPIC" flag. Then I 
linked them with gcc with this command "gcc -shared 
-Wl,-soname,libtango.so.1 -o libtango.so.1.0 <list of object files> -lz 
-lbz2"

I have no idea what the above linker error means, "version node not 
found..."? I also tried linking with dmd and got the same result. I 
didn't get this error building on mac. Does anyone have any idea how to 
fix this?

-- 
/Jacob Carlborg
Jun 10 2010
parent reply jpf <nospam example.com> writes:
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_throw 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_throw 4 as name version. As there is no
entry for version 4, linking fails. I guess mac is not affected, because Mach-O
accepts _d_throw 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_throw 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.
Jun 27 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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_throw 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_throw 4 as name version. As there is
no
 entry for version 4, linking fails. I guess mac is not affected, because Mach-O
 accepts _d_throw 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_throw 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'll have a look at these links later and see if I can do something about it, thanks. -- /Jacob Carlborg
Jun 27 2010
parent reply jpf <spam example.com> writes:
On 27.06.2010 19:25, Jacob Carlborg wrote:
 On 2010-06-27 12:35, jpf wrote:
 But i guess, this should really be fixed in the compiler and druntime.

I'll have a look at these links later and see if I can do something about it, thanks.

Btw: I filed the issue on the dmd bugtracker. http://d.puremagic.com/issues/show_bug.cgi?id=4398 I also posted a patch for dmd2, dmd1 should be very similar. If the patch is applied to dmd1 as well, tango also needs to be updated(and phobos1).
Jun 27 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-06-27 19:58, jpf wrote:
 On 27.06.2010 19:25, Jacob Carlborg wrote:
 On 2010-06-27 12:35, jpf wrote:
 But i guess, this should really be fixed in the compiler and druntime.

I'll have a look at these links later and see if I can do something about it, thanks.

Btw: I filed the issue on the dmd bugtracker. http://d.puremagic.com/issues/show_bug.cgi?id=4398 I also posted a patch for dmd2, dmd1 should be very similar. If the patch is applied to dmd1 as well, tango also needs to be updated(and phobos1).

Thanks -- /Jacob Carlborg
Jun 27 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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_throw 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_throw 4 as name version. As there is
no
 entry for version 4, linking fails. I guess mac is not affected, because Mach-O
 accepts _d_throw 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_throw 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
Jun 29 2010
parent reply jpf <spam example.com> writes:
On 29.06.2010 11:08, Jacob Carlborg wrote:
 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_throw 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_throw 4 as name version. As
 there is no
 entry for version 4, linking fails. I guess mac is not affected,
 because Mach-O
 accepts _d_throw 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_throw 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?

related to the objcopy workaround) Having a short look at the relevant druntime source, I don't see how this problem could be caused by druntime. My debugging / asm skills aren't very advanced however, so I can't really tell. I guess Sean Kelly or Walter could say more on that. Maybe we should ask on the dmd-devel or the phobos mailing list (or is there a list for druntime?) -- Johannes Pfau
Jun 29 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-06-29 19.55, jpf wrote:
 On 29.06.2010 11:08, Jacob Carlborg wrote:
 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_throw 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_throw 4 as name version. As
 there is no
 entry for version 4, linking fails. I guess mac is not affected,
 because Mach-O
 accepts _d_throw 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_throw 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?

related to the objcopy workaround) Having a short look at the relevant druntime source, I don't see how this problem could be caused by druntime. My debugging / asm skills aren't very advanced however, so I can't really tell. I guess Sean Kelly or Walter could say more on that. Maybe we should ask on the dmd-devel or the phobos mailing list (or is there a list for druntime?)

That is a good idea, I don't think there is a mailing list for druntime. -- Jacob Carlborg
Jun 30 2010