www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Undefined reference to _d_throw

reply "Steve Teale" <steve.teale britseyeview.com> writes:
I'm linking gtkd-2 compiled with gdc (4.8.2) in a project 
compiled with dmd (2.063), and I get an undefined external 
_d_throw.

Do I need to build both with the same compiler?
Nov 02 2013
next sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Saturday, 2 November 2013 at 10:04:18 UTC, Steve Teale wrote:
 I'm linking gtkd-2 compiled with gdc (4.8.2) in a project 
 compiled with dmd (2.063), and I get an undefined external 
 _d_throw.

 Do I need to build both with the same compiler?
Having now rebuilt gtkd-2 with dmd, it appears that the answer is yes. The dmd version gets rid of the undefined _d_throw.
Nov 02 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-02 11:04, Steve Teale wrote:
 I'm linking gtkd-2 compiled with gdc (4.8.2) in a project compiled with
 dmd (2.063), and I get an undefined external _d_throw.

 Do I need to build both with the same compiler?
Neither DMD, GDC or LDC are binary compatible with each other. -- /Jacob Carlborg
Nov 02 2013
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
 Do I need to build both with the same compiler?
Neither DMD, GDC or LDC are binary compatible with each other.
Thanks Jacob. My next linking problem is that I have lots of undefined externals relating to libpthread. I suspect this may be a CodeBlocks configuration error. I've tried every whichway but have not found a way round this yet. Most frustrating.
Nov 02 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-02 13:54, Steve Teale wrote:

 Thanks Jacob. My next linking problem is that I have lots of undefined
 externals relating to libpthread. I suspect this may be a CodeBlocks
 configuration error. I've tried every whichway but have not found a way
 round this yet. Most frustrating.
How are you compiling? DMD automatically links with libpthread. You can pass the -v (verbose) flag to DMD to see what command it uses for linking. Otherwise you could try and explicitly link with libpthread: dmd main.d -L-lpthread -- /Jacob Carlborg
Nov 02 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 2 November 2013 13:53, Jacob Carlborg <doob me.com> wrote:

 On 2013-11-02 13:54, Steve Teale wrote:

  Thanks Jacob. My next linking problem is that I have lots of undefined
 externals relating to libpthread. I suspect this may be a CodeBlocks
 configuration error. I've tried every whichway but have not found a way
 round this yet. Most frustrating.
How are you compiling? DMD automatically links with libpthread. You can pass the -v (verbose) flag to DMD to see what command it uses for linking. Otherwise you could try and explicitly link with libpthread: dmd main.d -L-lpthread
Really? I thought that was dmd.conf telling the compiler to do that.... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 02 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-02 15:45, Iain Buclaw wrote:

 Really?  I thought that was dmd.conf telling the compiler to do that....
No, linking with libphobos2, libpthread and libm is hard coded into DMD. The command used to link: gcc main.o -o main -m64 -L/Users/doob/.dvm/compilers/dmd-2.063.2/bin/../lib -lphobos2 -lpthread -lm My dmd.conf file: [Environment] DFLAGS=-I% P%/../imports -I% P%/../src/phobos -I% P%/../src/druntime/import -L-L% P%/../lib -- /Jacob Carlborg
Nov 02 2013
prev sibling parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
 externals relating to libpthread. I suspect this may be a 
 CodeBlocks
 configuration error. I've tried every whichway but have not 
 found a way
 round this yet. Most frustrating.
How are you compiling? DMD automatically links with libpthread. You can pass the -v (verbose) flag to DMD to see what command it uses for linking. Otherwise you could try and explicitly link with libpthread: dmd main.d -L-lpthread
CodeBlocks is supervising the compilation. I had added the libraries to its recipe in the wrong order: pthread m phobos2 The opposite way round it links OK, bu there's still something strange going on. When I try to run it, it fails with: ./compo: error while loading shared libraries: libphobos2.so.0.2: cannot open shared object file: No such file or directory This is true, there is no such file. In /usr/lib/i386-linux-gnu there's only libphobos2.so - a real file - which in my understanding should be a link to an actual shared library file. Is there a working shared Phobos library in 2.063, or is this a .deb file error. If I have /usr/lib/i386-linux-gnu/libphobos.a instead of phobos2, the program links and at least attempts to run. It may crash later, but that's my fault. This is not just a CodeBlocks thing. I made a simple makefile instead that links the libraries in the right order. That links, but also fails with the missing Phobos shared library error.
Nov 02 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-02 21:12, Steve Teale wrote:

 CodeBlocks is supervising the compilation. I had added the libraries to
 its recipe in the wrong order:

 pthread
 m
 phobos2

 The opposite way round it links OK, bu there's still something strange
 going on. When I try to run it, it fails with:

 ./compo: error while loading shared libraries: libphobos2.so.0.2: cannot
 open shared object file: No such file or directory

 This is true, there is no such file. In /usr/lib/i386-linux-gnu there's
 only libphobos2.so - a real file - which in my understanding should be a
 link to an actual shared library file.

 Is there a working shared Phobos library in 2.063, or is this a .deb
 file error. If I have /usr/lib/i386-linux-gnu/libphobos.a instead of
 phobos2, the program links and at least attempts to run. It may crash
 later, but that's my fault.

 This is not just a CodeBlocks thing. I made a simple makefile instead
 that links the libraries in the right order. That links, but also fails
 with the missing Phobos shared library error.
Shared libraries are quite a new thing in D. I'm pretty sure it's supposed to link with the static library by default. Usually you can force linking with a static library by doing -L-l:/path/to/staticlibrary.a. Note the colon in the beginning of the path. Although I don't know if you can do that with Phobos. It seems like CodeBlocks is doing something strange here. -- /Jacob Carlborg
Nov 02 2013
parent Mike Wey <mike-wey example.com> writes:
On 11/02/2013 10:08 PM, Jacob Carlborg wrote:
 On 2013-11-02 21:12, Steve Teale wrote:

 CodeBlocks is supervising the compilation. I had added the libraries to
 its recipe in the wrong order:

 pthread
 m
 phobos2

 The opposite way round it links OK, bu there's still something strange
 going on. When I try to run it, it fails with:

 ./compo: error while loading shared libraries: libphobos2.so.0.2: cannot
 open shared object file: No such file or directory

 This is true, there is no such file. In /usr/lib/i386-linux-gnu there's
 only libphobos2.so - a real file - which in my understanding should be a
 link to an actual shared library file.

 Is there a working shared Phobos library in 2.063, or is this a .deb
 file error. If I have /usr/lib/i386-linux-gnu/libphobos.a instead of
 phobos2, the program links and at least attempts to run. It may crash
 later, but that's my fault.

 This is not just a CodeBlocks thing. I made a simple makefile instead
 that links the libraries in the right order. That links, but also fails
 with the missing Phobos shared library error.
Shared libraries are quite a new thing in D. I'm pretty sure it's supposed to link with the static library by default. Usually you can force linking with a static library by doing -L-l:/path/to/staticlibrary.a. Note the colon in the beginning of the path. Although I don't know if you can do that with Phobos. It seems like CodeBlocks is doing something strange here.
You could try putting: :libphobos2.a in the list of libraries for CodeBlocks, as it doesn't require the full path. -- Mike Wey
Nov 03 2013
prev sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
On 02/11/13 21:12, Steve Teale wrote:
 The opposite way round it links OK, bu there's still something strange going
on. When I try to run it, it fails with:
 
 ./compo: error while loading shared libraries: libphobos2.so.0.2: cannot open
shared object file: No such file or directory
 
 This is true, there is no such file. In /usr/lib/i386-linux-gnu there's only
libphobos2.so - a real file - which in my understanding should be a link to an
actual shared library file.
 
 Is there a working shared Phobos library in 2.063, or is this a .deb file
error. If I have /usr/lib/i386-linux-gnu/libphobos.a instead of phobos2, the
program links and at least attempts to run. It may crash later, but that's my
fault.
 
 This is not just a CodeBlocks thing. I made a simple makefile instead that
links the libraries in the right order. That links, but also fails with the
missing Phobos shared library error.
 
Yes, this is a .deb error for 2.063.2, which will be fixed on next release. There are fixed deb packages for the current version at http://d-apt.sourceforge.net/ -- Jordi Sayol
Nov 03 2013