www.digitalmars.com         C & C++   DMDScript  

D.gnu - Generated binary size

reply "Dicebot" <public dicebot.lv> writes:
I was experimenting with `--gc-sections` effect on D code (with 
great results) and have noticed that GDC binaries are much bigger 
than DMD ones. I do understand that it is not a priority goal 
right now but still curious, does anyone know what makes such 
notable (~50%) difference?
(64-bit OS)

--------
import std.stdio, std.algorithm;

void main()
{
     auto arr = [ 1, 2, 3 ];
     writeln( arr.map!( a => a*2 )() );
}
--------
$ gdc -ofhello-gdc -O3 hello.d
$ dmd -ofhello-dmd -release -inline -O hello.d
$ ls -la
# ...
-rwxr-xr-x 1 dicebot users  819647 Sep 13 13:38 hello-dmd
-rwxr-xr-x 1 dicebot users 1386355 Sep 13 13:39 hello-gdc
-------
Sep 13 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 13:45, Dicebot wrote:
 I was experimenting with `--gc-sections` effect on D code (with great results)

Can you expand on this? Never heard of it before and can't find it in gdc --help or manpages.
Sep 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 11:58:53 UTC, Joseph Rushton 
Wakeling wrote:
 On 13/09/13 13:45, Dicebot wrote:
 I was experimenting with `--gc-sections` effect on D code 
 (with great results)

Can you expand on this? Never heard of it before and can't find it in gdc --help or manpages.

`--gc-sections` is ld flag that enabled garbage collection of unreferenced sections in resulting binary. For it to work gcc/gdc need to be run with `-fdata-sections`and `-ffunction-sections` placing each symbol into own section. That will, for example, remove template function bodies that got inlined for all calls. For template-heavy code with good inliner it can reduce binary sizes tremendously (running it on snippet from this topic will reduce gdc binary size to almost match dmd one).
Sep 13 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 13 Sep 2013 13:45:58 +0200
schrieb "Dicebot" <public dicebot.lv>:

 I was experimenting with `--gc-sections` effect on D code (with 
 great results) and have noticed that GDC binaries are much bigger 
 than DMD ones. I do understand that it is not a priority goal 
 right now but still curious, does anyone know what makes such 
 notable (~50%) difference?
 (64-bit OS)
 
 --------
 import std.stdio, std.algorithm;
 
 void main()
 {
      auto arr = [ 1, 2, 3 ];
      writeln( arr.map!( a => a*2 )() );
 }
 --------
 $ gdc -ofhello-gdc -O3 hello.d
 $ dmd -ofhello-dmd -release -inline -O hello.d
 $ ls -la
 # ...
 -rwxr-xr-x 1 dicebot users  819647 Sep 13 13:38 hello-dmd
 -rwxr-xr-x 1 dicebot users 1386355 Sep 13 13:39 hello-gdc
 -------

It seems like the gdc compiled program has more symbols for some reason: ---------- nm hello-dmd --defined-only | wc -l 3834 nm hello-gdc --defined-only | wc -l 5451 ---------- Here's a "diff" of the defined symbols: https://gist.github.com/jpf91/6550247
Sep 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 12:51:13 UTC, Johannes Pfau wrote:
 It seems like the gdc compiled program has more symbols for some
 reason:

 ----------
 nm hello-dmd --defined-only | wc -l
 3834
 nm hello-gdc --defined-only | wc -l
 5451
 ----------

 Here's a "diff" of the defined symbols:
 https://gist.github.com/jpf91/6550247

Yep and `--gc-sections` gets it down to: ``` $ nm hello-gdc --defined-only | wc -l 3894 ``` I was curious though what kind of code gen optimization dmd uses here (as opposed to gdc) as simple experiments show that it does not remove unused template instances.
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 14:02, Dicebot wrote:
 `--gc-sections` is ld flag that enabled garbage collection of unreferenced
 sections in resulting binary. For it to work gcc/gdc need to be run with
 `-fdata-sections`and `-ffunction-sections` placing each symbol into own
section.
 That will, for example, remove template function bodies that got inlined for
all
 calls. For template-heavy code with good inliner it can reduce binary sizes
 tremendously (running it on snippet from this topic will reduce gdc binary size
 to almost match dmd one).

Ahh, OK. Related query -- is there any way of telling the compiler (gdc/gdmd or preferably any of the D compilers) to strip out unused symbols/functions/data from the binary? I have a module that includes a quite large array of immutable data (used for test purposes), but when this is compiled in with other code it adds about 10MB (!) to the executable size, even when the executable never uses it. It'd be nice to be able to strip that out automatically rather than having to tweak the build script manually to leave out that module -- it's so much simpler to have the Makefile simply build using the whole library source. [*] [* Yes, yes, I know, I should abandon Make and sort out a decent built system at long last ...]
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 15:14, Joseph Rushton Wakeling wrote:
 Related query -- is there any way of telling the compiler (gdc/gdmd or
 preferably any of the D compilers) to strip out unused symbols/functions/data
 from the binary?

I ask because I just tried compiling with the -fdata-sections and -ffunction-sections options enabled, and the binaries I got were still including that lovely 10MB bonus ... :-P
Sep 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 13:14:49 UTC, Joseph Rushton 
Wakeling wrote:
 Ahh, OK.

 Related query -- is there any way of telling the compiler 
 (gdc/gdmd or preferably any of the D compilers) to strip out 
 unused symbols/functions/data from the binary?

 I have a module that includes a quite large array of immutable 
 data (used for test purposes), but when this is compiled in 
 with other code it adds about 10MB (!) to the executable size, 
 even when the executable never uses it.

It is exactly what `gdc -fdata-sections -Xlinker --gc-sections app.d` will do. Be careful though, if you use dynamic loading of shared libraries (or build your app as library) that may result in weird stuff when applied to all sources :)
Sep 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 13:25:03 UTC, Dicebot wrote:
 It is exactly what `gdc -fdata-sections -Xlinker --gc-sections 
 app.d` will do.

 Be careful though, if you use dynamic loading of shared 
 libraries (or build your app as library) that may result in 
 weird stuff when applied to all sources :)

On my machine: ----- $ cat a.d immutable long[100_000] arr = 1; void main() { } ---- $ gdc -O3 a.d $ ls -la # ... -rwxr-xr-x 1 dicebot users 1276934 Sep 13 15:21 a.out ---- $ gdc -O3 -fdata-sections a.d -Xlinker --gc-sections $ ls -la # ... -rwxr-xr-x 1 dicebot users 434859 Sep 13 15:21 a.out ----
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 15:25, Dicebot wrote:
 On Friday, 13 September 2013 at 13:14:49 UTC, Joseph Rushton Wakeling wrote:
 Related query -- is there any way of telling the compiler (gdc/gdmd or
 preferably any of the D compilers) to strip out unused symbols/functions/data
 from the binary?

 I have a module that includes a quite large array of immutable data (used for
 test purposes), but when this is compiled in with other code it adds about
 10MB (!) to the executable size, even when the executable never uses it.

It is exactly what `gdc -fdata-sections -Xlinker --gc-sections app.d` will do.

Tried it. It reduces 12 MB executables to 11 MB -- but if I manually exclude the module responsible for the big data, executable sizes fall to 2 MB.
Sep 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 13:36:45 UTC, Joseph Rushton 
Wakeling wrote:
 Tried it.  It reduces 12 MB executables to 11 MB -- but if I 
 manually exclude the module responsible for the big data, 
 executable sizes fall to 2 MB.

Then it is likely to be marked as referenced by something :( Can you try to reduce this case? Would be interesting to investigate.
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 15:36, Joseph Rushton Wakeling wrote:
 Tried it.  It reduces 12 MB executables to 11 MB -- but if I manually exclude
 the module responsible for the big data, executable sizes fall to 2 MB.

Sorry, I'm talking nonsense. I managed to accidentally build using ldmd2, which was responsible for the small executable sizes. The +10 MB executable size seems to be entirely down to gdc.
Sep 13 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 September 2013 14:42, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 13/09/13 15:36, Joseph Rushton Wakeling wrote:
 Tried it.  It reduces 12 MB executables to 11 MB -- but if I manually
 exclude
 the module responsible for the big data, executable sizes fall to 2 MB.

Sorry, I'm talking nonsense. I managed to accidentally build using ldmd2, which was responsible for the small executable sizes. The +10 MB executable size seems to be entirely down to gdc.

I expect this is because the phobos/druntime libraries shipped with dmd are (a) without debugging symbols and (b) stripped. If you were to strip libphobos after installing gdc, then you would see a significant drop in size. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 13 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 September 2013 16:24, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 13 September 2013 14:42, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 On 13/09/13 15:36, Joseph Rushton Wakeling wrote:
 Tried it.  It reduces 12 MB executables to 11 MB -- but if I manually
 exclude
 the module responsible for the big data, executable sizes fall to 2 MB.

Sorry, I'm talking nonsense. I managed to accidentally build using ldmd2, which was responsible for the small executable sizes. The +10 MB executable size seems to be entirely down to gdc.

I expect this is because the phobos/druntime libraries shipped with dmd are (a) without debugging symbols and (b) stripped. If you were to strip libphobos after installing gdc, then you would see a significant drop in size.

In this way, I'd also expect those who build gdc from source would have large executables than those who install gdc through a package manager/installer. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 17:24, Iain Buclaw wrote:
 I expect this is because the phobos/druntime libraries shipped with
 dmd are (a) without debugging symbols and (b) stripped.

 If you were to strip libphobos after installing gdc, then you would
 see a significant drop in size.

Could be. I do build with the --enable-checking=release option, what else do I need to do ... ?
Sep 13 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 13 Sep 2013 18:10:24 +0200
schrieb Joseph Rushton Wakeling <joseph.wakeling webdrake.net>:

 On 13/09/13 17:24, Iain Buclaw wrote:
 I expect this is because the phobos/druntime libraries shipped with
 dmd are (a) without debugging symbols and (b) stripped.

 If you were to strip libphobos after installing gdc, then you would
 see a significant drop in size.

Could be. I do build with the --enable-checking=release option, what else do I need to do ... ?

Use make install-strip instead of "make install"
Sep 13 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 13 Sep 2013 16:25:47 +0100
schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 On 13 September 2013 16:24, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 
 In this way, I'd also expect those who build gdc from source would
 have large executables than those who install gdc through a package
 manager/installer.

The example from the original post is still valid though. Even with a stripped libphobos the executable produced by gdc is almost twice as big. ls -lh /usr/lib | grep phobos -rw-r--r-- 1 root root 18M 7. Sep 03:15 libgphobos2.a -rw-r--r-- 1 root root 12M 7. Sep 03:42 liblphobos.a -rw-r--r-- 1 root root 13M 7. Sep 03:42 liblphobos-debug.a -rw-r--r-- 1 root root 30M 25. Aug 19:08 libphobos2.a
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 18:30, Johannes Pfau wrote:
 Use
 make install-strip
 instead of "make install"

Hmm, well, I just reinstalled GDC using make install-strip, rebuilt the programs in question and they're still coming out as 12 MB ... Could it be static vs. shared druntime/Phobos?
Sep 13 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--001a1133063eb307a104e6471816
Content-Type: text/plain; charset=ISO-8859-1

On Sep 13, 2013 5:41 PM, "Joseph Rushton Wakeling" <
joseph.wakeling webdrake.net> wrote:
 On 13/09/13 18:30, Johannes Pfau wrote:
 Use
 make install-strip
 instead of "make install"

Hmm, well, I just reinstalled GDC using make install-strip, rebuilt the

 Could it be static vs. shared druntime/Phobos?

Can you check if it in fact strips binaries? (you can check with 'file') Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a1133063eb307a104e6471816 Content-Type: text/html; charset=ISO-8859-1 <p><br> On Sep 13, 2013 5:41 PM, &quot;Joseph Rushton Wakeling&quot; &lt;<a href="mailto:joseph.wakeling webdrake.net">joseph.wakeling webdrake.net</a>&gt; wrote:<br> &gt;<br> &gt; On 13/09/13 18:30, Johannes Pfau wrote:<br> &gt;&gt;<br> &gt;&gt; Use<br> &gt;&gt; make install-strip<br> &gt;&gt; instead of &quot;make install&quot;<br> &gt;<br> &gt;<br> &gt; Hmm, well, I just reinstalled GDC using make install-strip, rebuilt the programs in question and they&#39;re still coming out as 12 MB ...<br> &gt;<br> &gt; Could it be static vs. shared druntime/Phobos?<br> &gt;</p> <p>Can you check if it in fact strips binaries? (you can check with &#39;file&#39;)</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) = (c &amp; 0x0f) + &#39;0&#39;;</p> --001a1133063eb307a104e6471816--
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 19:22, Iain Buclaw wrote:
 Can you check if it in fact strips binaries? (you can check with 'file')

bin/gdc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped lib64/libgphobos2.a: current ar archive libgphobos2.a is 72 MB in size, while LDC breaks Phobos up into 2 parts, libphobos-ldc.a (20 MB) and libphobos-ldc-debug.a (33 MB).
Sep 13 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 September 2013 18:28, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 13/09/13 19:22, Iain Buclaw wrote:
 Can you check if it in fact strips binaries? (you can check with 'file')

bin/gdc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped lib64/libgphobos2.a: current ar archive libgphobos2.a is 72 MB in size, while LDC breaks Phobos up into 2 parts, libphobos-ldc.a (20 MB) and libphobos-ldc-debug.a (33 MB).

du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.a -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 13 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/09/13 20:09, Iain Buclaw wrote:
 du -h lib64/libgphobos2.a
 73M    lib64/libgphobos2.a

 strip --strip-unneeded  lib64/libgphobos2.a

 du -h lib64/libgphobos2.a
 18M    lib64/libgphobos2.a

Ahh, OK. Is there any way in which to ensure that the build splits Phobos up into library and debugging symbols la LDC? Could be useful, no?
Sep 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
 du -h lib64/libgphobos2.a
 73M    lib64/libgphobos2.a

 strip --strip-unneeded  lib64/libgphobos2.a

 du -h lib64/libgphobos2.a
 18M    lib64/libgphobos2.a

Well, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:
 On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
 du -h lib64/libgphobos2.a
 73M    lib64/libgphobos2.a

 strip --strip-unneeded  lib64/libgphobos2.a

 du -h lib64/libgphobos2.a
 18M    lib64/libgphobos2.a

Well, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)

--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:
 On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:
 On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw 
 wrote:
 du -h lib64/libgphobos2.a
 73M    lib64/libgphobos2.a

 strip --strip-unneeded  lib64/libgphobos2.a

 du -h lib64/libgphobos2.a
 18M    lib64/libgphobos2.a

Well, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)

--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;)

Well, with --strip-debug it is back to the original situation in the very first comment, numbers there are with --strip-debug (what is the potential danger with --strip-unneeded?)
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 21:02, Dicebot <public dicebot.lv> wrote:
 On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:
 On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:
 On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
 du -h lib64/libgphobos2.a
 73M    lib64/libgphobos2.a

 strip --strip-unneeded  lib64/libgphobos2.a

 du -h lib64/libgphobos2.a
 18M    lib64/libgphobos2.a

Well, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)

--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;)

Well, with --strip-debug it is back to the original situation in the very first comment, numbers there are with --strip-debug (what is the potential danger with --strip-unneeded?)

--strip-unneeded could potentially cause lots of undefined reference errors on static libraries. Shared libraries don't suffer this because symbols are put into a special section which strip knows not to touch. General rule of them: binaries: strip <file> static libraries: strip --strip-debug <file> shared libraries: strip --strip-unneeded <file> -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 September 2013 at 21:05:18 UTC, Iain Buclaw wrote:
 --strip-unneeded could potentially cause lots of undefined 
 reference
 errors on static libraries.  Shared libraries don't suffer this
 because symbols are put into a special section which strip 
 knows not
 to touch.

 General rule of them:

 binaries: strip <file>
 static libraries: strip --strip-debug <file>
 shared libraries: strip --strip-unneeded <file>

Ok, thanks. What may cause twice the difference in the original post then? :)
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 22:05, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 15 September 2013 21:02, Dicebot <public dicebot.lv> wrote:
 On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:
 On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:
 On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
 du -h lib64/libgphobos2.a
 73M    lib64/libgphobos2.a

 strip --strip-unneeded  lib64/libgphobos2.a

 du -h lib64/libgphobos2.a
 18M    lib64/libgphobos2.a

Well, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)

--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;)

Well, with --strip-debug it is back to the original situation in the very first comment, numbers there are with --strip-debug (what is the potential danger with --strip-unneeded?)

--strip-unneeded could potentially cause lots of undefined reference errors on static libraries. Shared libraries don't suffer this because symbols are put into a special section which strip knows not to touch.

Just tested on my system, original size = 74240. strip-debug size = 17800. strip-unneeded size = 17448. So --strip-debug should is sufficient in reducing binary sizes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 22:07, Dicebot <public dicebot.lv> wrote:
 On Sunday, 15 September 2013 at 21:05:18 UTC, Iain Buclaw wrote:
 --strip-unneeded could potentially cause lots of undefined reference
 errors on static libraries.  Shared libraries don't suffer this
 because symbols are put into a special section which strip knows not
 to touch.

 General rule of them:

 binaries: strip <file>
 static libraries: strip --strip-debug <file>
 shared libraries: strip --strip-unneeded <file>

Ok, thanks. What may cause twice the difference in the original post then? :)

As per my initial post, strip not being ran on the library after installation. :-) The makefile for libphobos/libdruntime certainly doesn't strip the libraries for you when you make strip-install. At least not yet... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 13 September 2013 at 19:48:12 UTC, Joseph Rushton 
Wakeling wrote:
 Is there any way in which to ensure that the build splits 
 Phobos up into library and debugging symbols à la LDC?  Could 
 be useful, no?

LDC does not strip the library into a release build and debugging symbols (yet) – the '-debug' version just contains a debug build (i.e. with assertions and debug info enabled) of the standard library. Whether this is the best idea going forward can certainly be discussed (considering that the user most probably doesn't expect to get a non-optimized build of the standard library when using -g). David
Sep 15 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 September 2013 at 21:30:17 UTC, Iain Buclaw wrote:
 As per my initial post, strip not being ran on the library after
 installation. :-)

 The makefile for libphobos/libdruntime certainly doesn't strip 
 the
 libraries for you when you make strip-install.  At least not 
 yet...

As per my answer, those result are _with_ "--strip-debug" :P (stripping is done automatically by package manager utilities like `makepkg` when you build package in Arch)
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 23:01, Dicebot <public dicebot.lv> wrote:
 On Sunday, 15 September 2013 at 21:30:17 UTC, Iain Buclaw wrote:
 As per my initial post, strip not being ran on the library after
 installation. :-)

 The makefile for libphobos/libdruntime certainly doesn't strip the
 libraries for you when you make strip-install.  At least not yet...

As per my answer, those result are _with_ "--strip-debug" :P (stripping is done automatically by package manager utilities like `makepkg` when you build package in Arch)

If the size of the library is 70MB+ then it most certainly isn't running --strip-debug on the library. I can guarantee you at least this. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 September 2013 at 22:30:11 UTC, Iain Buclaw wrote:
 If the size of the library is 70MB+ then it most certainly isn't
 running --strip-debug on the library.  I can guarantee you at 
 least
 this. :-)

It is 18Mb (you are probably mixing my posts with Joseph ones, they are unrelated)
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 23:48, Dicebot <public dicebot.lv> wrote:
 On Sunday, 15 September 2013 at 22:30:11 UTC, Iain Buclaw wrote:
 If the size of the library is 70MB+ then it most certainly isn't
 running --strip-debug on the library.  I can guarantee you at least
 this. :-)

It is 18Mb (you are probably mixing my posts with Joseph ones, they are unrelated)

Stop renaming yourself between Dicebot and Joseph then! :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 15 September 2013 at 21:52:29 UTC, David Nadlinger 
wrote:
 LDC does not strip the library into

s/strip/split/ David
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 September 2013 23:01, Dicebot <public dicebot.lv> wrote:
 On Sunday, 15 September 2013 at 21:30:17 UTC, Iain Buclaw wrote:
 As per my initial post, strip not being ran on the library after
 installation. :-)

 The makefile for libphobos/libdruntime certainly doesn't strip the
 libraries for you when you make strip-install.  At least not yet...

As per my answer, those result are _with_ "--strip-debug" :P (stripping is done automatically by package manager utilities like `makepkg` when you build package in Arch)

gdc's druntime also pulls in libgcc so that will be one factor to a larger executable. Having a look at ldd output, the gdc produced binary also links in libm, whereas dmd's doesn't. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 16 September 2013 00:15, David Nadlinger <code klickverbot.at> wrote:
 On Sunday, 15 September 2013 at 21:52:29 UTC, David Nadlinger wrote:
 LDC does not strip the library into

s/strip/split/

I knew what you meant. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 15 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 16/09/13 01:03, Iain Buclaw wrote:
 Stop renaming yourself between Dicebot and Joseph then! :o)

Flee, flee! Our secret identities have been revealed! :-O
Sep 16 2013