digitalmars.D - Trying to build Tango as dynamic library on linux
- Jacob Carlborg (19/19) Jun 10 2010 I though I would try to build tango as a dynamic library with dmd on
- jpf (22/22) Jun 27 2010 Hi,
- Jacob Carlborg (5/27) Jun 27 2010 I'll have a look at these links later and see if I can do something
- jpf (6/13) Jun 27 2010 Btw: I filed the issue on the dmd bugtracker.
- Jacob Carlborg (4/17) Jun 27 2010 Thanks
- Jacob Carlborg (6/28) Jun 29 2010 I've managed to solve the linker error as shown on the last link and
- jpf (10/53) Jun 29 2010 Same problem here. (With the dmd and druntime patches, so it's not
- Jacob Carlborg (4/55) Jun 30 2010 That is a good idea, I don't think there is a mailing list for druntime.
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
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
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
On 27.06.2010 19:25, Jacob Carlborg wrote:On 2010-06-27 12:35, jpf wrote: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).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.
Jun 27 2010
Jacob Carlborg <doob me.com> On 2010-06-27 19:58, jpf wrote:On 27.06.2010 19:25, Jacob Carlborg wrote:Thanks -- /Jacob CarlborgOn 2010-06-27 12:35, jpf wrote: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).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.
Jun 27 2010
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
On 29.06.2010 11:08, Jacob Carlborg wrote:On 2010-06-27 12:35, jpf wrote:Same problem here. (With the dmd and druntime patches, so it's not 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 PfauHi, 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?
Jun 29 2010
On 2010-06-29 19.55, jpf wrote:On 29.06.2010 11:08, Jacob Carlborg wrote:That is a good idea, I don't think there is a mailing list for druntime. -- Jacob CarlborgOn 2010-06-27 12:35, jpf wrote:Same problem here. (With the dmd and druntime patches, so it's not 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?)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?
Jun 30 2010