• Matthew Caron (9/9) Jun 14 2012 So, we've been toying with using D on embedded systems, and one of the
• Jacob Carlborg (5/10) Jun 14 2012 D does not currently support shared libraries. Although I don't know if
• Matthew Caron (28/30) Jun 14 2012 That's odd, because when I build a target and run file on it, I get:

Matthew Caron <Matt.Caron redlion.net> writes:

So, we've been toying with using D on embedded systems, and one of the 
things that struck us as strange is that our emitted binaries don't link 
against a shared libphobos, and indeed, one does not even seem to be 
created when building GDC. Was this a conscious design decision? If so, 
why? Are there any plans to change it to use a shared library?
-- 
Matthew Caron, Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office

Jacob Carlborg <doob me.com> writes:

On 2012-06-14 14:36, Matthew Caron wrote:
 So, we've been toying with using D on embedded systems, and one of the
 things that struck us as strange is that our emitted binaries don't link
 against a shared libphobos, and indeed, one does not even seem to be
 created when building GDC. Was this a conscious design decision? If so,
 why? Are there any plans to change it to use a shared library?

D does not currently support shared libraries. Although I don't know if 
GDC has done some modifications to support this.

-- 
/Jacob Carlborg

Matthew Caron <Matt.Caron redlion.net> writes:

On 06/14/2012 08:51 AM, Jacob Carlborg wrote:
 D does not currently support shared libraries. Although I don't know if
 GDC has done some modifications to support this.

That's odd, because when I build a target and run file on it, I get:

dpodder: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.24, 
BuildID[sha1]=0xe9c821eaff6b93c800cb093c3acf022b86d5dff6, not stripped

and then ldd says:

(matt hiro) ~/workspace/code/dpodder (master)$ ldd dpodder
         linux-vdso.so.1 =>  (0x00007fff013ff000)
         libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x00007ff32345a000)
         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff323160000)
         librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff322f57000)
         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x00007ff322d41000)
         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007ff322b24000)
         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff322766000)
         /lib64/ld-linux-x86-64.so.2 (0x00007ff323722000)
         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff322562000)

So, at some level, gdc does link against C shared libraries....

(and for the curious, I'm working on a program to replace hpodder, only 
written in D, because I did not feel like learning haskell to fix the 
issues with it, but I did want to learn D, and it seemed a fairly 
reasonably scoped project).
-- 
Matthew Caron, Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office