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
On 16 September 2013 00:15, David Nadlinger 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';
On 15 September 2013 23:01, Dicebot 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 wh
On Sunday, 15 September 2013 at 21:52:29 UTC, David Nadlinger
wrote:
LDC does not strip the library into
s/strip/split/
David
On 15 September 2013 23:48, Dicebot 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 probabl
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)
On 15 September 2013 23:01, Dicebot 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 wh
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
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) –
On 15 September 2013 22:07, Dicebot 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 sect
On 15 September 2013 22:05, Iain Buclaw wrote:
> On 15 September 2013 21:02, Dicebot wrote:
>> On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:
>>>
>>> On 15 September 2013 20:46, Dicebot wrote:
On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw 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
On 15 September 2013 21:02, Dicebot wrote:
> On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:
>>
>> On 15 September 2013 20:46, Dicebot wrote:
>>>
>>> On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
du -h lib64/libgphobos2.a
73Mlib64/libgph
On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:
On 15 September 2013 20:46, Dicebot wrote:
On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw
wrote:
du -h lib64/libgphobos2.a
73Mlib64/libgphobos2.a
strip --strip-unneeded lib64/libgphobos2.a
du -h lib64/libgphobo
On 15 September 2013 20:46, Dicebot wrote:
> On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
>>
>> du -h lib64/libgphobos2.a
>> 73Mlib64/libgphobos2.a
>>
>> strip --strip-unneeded lib64/libgphobos2.a
>>
>> du -h lib64/libgphobos2.a
>> 18Mlib64/libgphobos2.a
>
>
> Well, lo
On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:
du -h lib64/libgphobos2.a
73Mlib64/libgphobos2.a
strip --strip-unneeded lib64/libgphobos2.a
du -h lib64/libgphobos2.a
18Mlib64/libgphobos2.a
Well, looks like you have just found a bug in default Arch Linux
makepkg.conf
On 13/09/13 20:09, Iain Buclaw wrote:
du -h lib64/libgphobos2.a
73Mlib64/libgphobos2.a
strip --strip-unneeded lib64/libgphobos2.a
du -h lib64/libgphobos2.a
18Mlib64/libgphobos2.a
Ahh, OK.
Is there any way in which to ensure that the build splits Phobos up into library
and debugging
On 13 September 2013 18:28, Joseph Rushton Wakeling
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),
On Sep 13, 2013 5:41 PM, "Joseph Rushton Wakeling" <
joseph.wakel...@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
programs in question and t
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 archiv
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?
Am Fri, 13 Sep 2013 16:25:47 +0100
schrieb Iain Buclaw :
> On 13 September 2013 16:24, Iain Buclaw 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 origin
Am Fri, 13 Sep 2013 18:10:24 +0200
schrieb Joseph Rushton Wakeling :
> 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 g
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 -
On 13 September 2013 16:24, Iain Buclaw wrote:
> On 13 September 2013 14:42, Joseph Rushton Wakeling
> 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,
On 13 September 2013 14:42, Joseph Rushton Wakeling
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
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
y
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 responsib
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 th
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 la
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 sourc
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-s
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 tem
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://gis
Am Fri, 13 Sep 2013 13:45:58 +0200
schrieb "Dicebot" :
> 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
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-
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.
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)
38 matches
Mail list logo
