.. and now it is in [community]
GCC 6.1.1 is currently available in [testing] and matching GDC is
in [community-testing] - both repos can be enabled in your
/etc/pacman.conf
Trying it out before they both get promoted to main repo would be
quite appreciated :)
On Monday, 18 January 2016 at 10:58:52 UTC, Marc Schütz wrote:
Hi!
I'm working on packaging GDC for openSUSE, and I have a few
questions.
Is it possible to make the build process install only D related
files, for example cc1d, but not cc1?
If the above works (or I manually exclude generic
https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/gdc/folders.diff
On Friday, 16 January 2015 at 04:31:17 UTC, Mike wrote:
On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau
wrote:
My best guess is that the strings are always placed in rodata,
never in
separate sections. If you do write("x"), "x" is also in
rodata, the
rodata section can't be remove
On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
So the best option is probably to get rid of this problem by
patching
the compiler (@notypeinfo or -fnortti).
Oh, sorry, I though GDC already does that when TypeInfo is never
actually used. Nevermind then, your version seems t
On Thursday, 15 January 2015 at 11:04:37 UTC, Mike wrote:
If you can explain the mechanics causing this, please enlighten
me. Bug? Enhancement? By design?
Random guess: can it possibly confuse template-based variadics
with runtime variadics? Latter require RTTI to work. If something
like tha
On Tuesday, 13 January 2015 at 14:20:43 UTC, Mike wrote:
On Sunday, 11 January 2015 at 16:57:41 UTC, Johannes Pfau wrote:
That's likely used/caused by the TypeInfo.name property.
Judging by what I'm seeing, I think you're right.
But I'm compiling with -fdata-sections and -Wl,--gc-sections,
On Thursday, 21 August 2014 at 12:31:31 UTC, ketmar via D.gnu
wrote:
On Thu, 21 Aug 2014 12:23:44 +
"Dicebot via D.gnu" wrote:
and there is no support for 2.066 yet, it will take at least
month (or
maybe three) to land. or maybe more. ;-)
What I have expected. Some user
I have just got `gdc` Arch Linux package flagged out of date with
a comment that support for 2.066 frontend is out. Can't remember
any announcement and it seems like false alarm but just to be
extra sure - what is the most simple way to check last supported
version in repo? (4.9 branch)
On Friday, 13 June 2014 at 07:25:27 UTC, Johannes Pfau wrote:
I'd also recommend to delay linux distribution package
updates but I hope that bug will be fixed soon.
Thanks for the warning, really appreciated :)
On Wednesday, 11 June 2014 at 22:50:37 UTC, Iain Buclaw via D.gnu
wrote:
However if the last conversation I had with Johannes was of any
indicator, if you hold onto your horses, you may find this
backported
to work on 4.9.x in the next weeks. :-)
Eagerly waiting for it ;)
Arch Linux has just switched to 4.9 gcc version, matching gdc
packages will be deployed shortly (building those right now).
This means one less user of 4.8 branch ;)
On Tuesday, 14 January 2014 at 20:15:39 UTC, Iain Buclaw wrote:
I trust that won't stay. A change in gcc-4.9 will break it. :)
Any change or only more impactful ones? (I was actually more
interested in 4.8 tag as this is gcc version in Arch)
And thanks btw ;)
On Tuesday, 14 January 2014 at 17:01:02 UTC, Iain Buclaw wrote:
Hi all,
GDC master will be temporarily broken as the frontend merge
with 2.065 (beta? prerelease?) is not yet sync'd up with the
library merge.
This will be fixed up in a couple of hours. :)
Regards
Iain.
Can you create tags
On Monday, 6 January 2014 at 18:59:00 UTC, Iain Buclaw wrote:
Of course ! --gc-sections is just a dirty hack. If you want
smaller
binaries, then you are better off aiding the shared library
support. :)
I don't ever recall any of the core maintainers ever endorsing
that switch
anyway
H
On Friday, 3 January 2014 at 18:14:58 UTC, Mike wrote:
I eventually tracked it down to the fact that I was compiling
with -ffunction-sections and -fdata-sections and linking with
--gc-sections and symbols like...
I never got --gc-sections to work reliably with D without going
dirty, crashes w
On Saturday, 4 January 2014 at 07:59:55 UTC, Timo Sintonen wrote:
In dmd and ides it is common to compile and link everything at
once. the compiler has all information available and may remove
unused code and data.
Actually no D compiler does it out of the box as far as I am
aware. It is a bi
On Thursday, 17 October 2013 at 16:31:21 UTC, Iain Buclaw wrote:
1. gdc looks for both .d and .di files in the include paths, so
that
is not the problem...
Isn't this done in front-end? If .di file is found, *.d won't be
searched.
On Wednesday, 16 October 2013 at 23:09:04 UTC, Iain Buclaw wrote:
Wait, dmd uses /dlang/ now for headers? What a strange
compiler... :o)
More like "What a strange packager" ;) I place all stuff under
/usr/include/dlang/, helps to experiment with all
3 at once. Of course changing paths in that
If anyone wants to patch gdc to use include paths more similar to
usual dmd style, my Arch Linux packaging script can serve as a
simple example :
https://github.com/Dicebot/Arch-PKGBUILDs/tree/master/gdc
(PKGBUILD file is just a special bash script)
On Thursday, 10 October 2013 at 15:17:55 UTC, Iain Buclaw wrote:
pragma(msg, __VERSION__);
Yeah, I mean without creating temporary file and compiling it ;)
Not really big deal, but sounds quite trivial and will simplify
some tooling.
On Thursday, 10 October 2013 at 14:59:05 UTC, Iain Buclaw wrote:
...
That reminds me - is there a gdc flag that makes it print used D
front-end version?
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 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 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 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
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 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 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
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
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.
)
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-
On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
Frankly, when hacking the kernel you use C, period. There are
alternatives, Ada for instance but they have a price tag too.
And
D, with all the warm feelings we might have for it, is not one
of
those alternatives.
Lot of confusion com
On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
And all I'm saying is that if you want to use it on bare metal
then
you have to strip out phobos and re-implement everything from
druntime.
I am mostly aware of this and have studied Xomb sources and
runtime reimplementation quit
On Friday, 6 September 2013 at 13:34:33 UTC, eles wrote:
Any clues?
I think you need own light-weight runtime stubs linked with the
binary. Adam has done some nice experiments in that direction :
http://arsdnet.net/dcode/minimal.zip
On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
On 6 September 2013 10:35, eles wrote:
But there's no equivalent to volatile statements other than
implementing your own low level thread library for use in
kernel-land
to
On Wednesday, 26 June 2013 at 15:45:44 UTC, Iain Buclaw wrote:
Unless Vladimir possibly gives us access to dlang's wiki to
post the documentation content there. I've opened up a new
wiki page for people to contribute to.
http://wiki.gdcproject.org
Thanks
Iain.
Erm, but wiki.dlang.org is o
On Monday, 13 May 2013 at 08:24:52 UTC, Iain Buclaw wrote:
On 13 May 2013 09:11, Dicebot wrote:
Last time I tried such stuff there was a TypeInfo emitted for
templated
structs. Is this still the case?
Why would you use templates in low level (eg: kernel) code?
Why would I chose D over C
Last time I tried such stuff there was a TypeInfo emitted for
templated structs. Is this still the case?
On Wednesday, 8 May 2013 at 12:51:15 UTC, Iain Buclaw wrote:
As of:
https://github.com/D-Programming-GDC/GDC/commit/af5a89409453006fb8e85be0a18d5eeecb950fb2
The D2 testsuite passes on x86/x86_64. This should be kept as
100% for any future pull requests and commits.
Anyone interested in imp
43 matches
Mail list logo
