www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GDC in Slackware and a bit about GDC development

reply Eugene Wissner <belka caraus.de> writes:
Hi,

lately I finally got some time to create GDC package for 
Slackware Linux [1].
Slackware ships gcc 5.3.0, therefore GDC package is the latest 
version from "gcc5" branch. It has phobos and druntime 2.076.0-b1 
and the frontend somewhere between 2.075 and 2.076.
Since Slackware packages are built by plain shell scripts, I 
thought I make an announce, because it can be used as a reference 
by people, who whant to build the latest GDC from source. The 
only difference between Slackware and mainstream Linux 
distributions (Ubuntu, Debian) I'm aware of, is that x86-64 
Slackware isn't multiarch by default.

The package is on slackbuilds.org [2]. The direct link to the 
build script is [3].
GDC looks pretty nice. I had only one problem: I got a linking 
error if I use core.stdc.stdarg; not sure if it is my failure or 
a bug. But I could build my library and run tests. Pretty nice.

I also would like to point to the "GCC tiny" tutorial [4]. The 
tutorial tells how to create a GCC frontend for a Pascal-like 
language, tiny. And it is a great thing to learn about GCC 
internals for someone who wants to help with GDC development, the 
best one I could find in the last months.


[1] http://www.slackware.com/
[2] https://slackbuilds.org/repository/14.2/development/gcc-d/
[3] 
https://slackbuilds.org/slackbuilds/14.2/development/gcc-d/gcc-d.SlackBuild
[4] http://thinkingeek.com/gcc-tiny/
Sep 23
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 September 2017 at 21:45, Eugene Wissner via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 Hi,

 lately I finally got some time to create GDC package for Slackware Linux
 [1].
 Slackware ships gcc 5.3.0, therefore GDC package is the latest version from
 "gcc5" branch. It has phobos and druntime 2.076.0-b1 and the frontend
 somewhere between 2.075 and 2.076.
 Since Slackware packages are built by plain shell scripts, I thought I make
 an announce, because it can be used as a reference by people, who whant to
 build the latest GDC from source. The only difference between Slackware and
 mainstream Linux distributions (Ubuntu, Debian) I'm aware of, is that x86-64
 Slackware isn't multiarch by default.

 The package is on slackbuilds.org [2]. The direct link to the build script
 is [3].
 GDC looks pretty nice. I had only one problem: I got a linking error if I
 use core.stdc.stdarg; not sure if it is my failure or a bug. But I could
 build my library and run tests. Pretty nice.
What's the linker error?
 I also would like to point to the "GCC tiny" tutorial [4]. The tutorial
 tells how to create a GCC frontend for a Pascal-like language, tiny. And it
 is a great thing to learn about GCC internals for someone who wants to help
 with GDC development, the best one I could find in the last months.

 [4] http://thinkingeek.com/gcc-tiny/
Looks good. A simpler GCC frontend would be https://github.com/giuseppe/gccbrainfuck Regards Iain.
Sep 23
parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 23 September 2017 at 20:34:51 UTC, Iain Buclaw wrote:
 On 23 September 2017 at 21:45, Eugene Wissner via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:
 GDC looks pretty nice. I had only one problem: I got a linking 
 error if I
 use core.stdc.stdarg; not sure if it is my failure or a bug. 
 But I could
 build my library and run tests. Pretty nice.
What's the linker error?
Here is the code, test.d: import core.stdc.stdarg; void format(char[] buf, ...) { va_list va; va_start(va, buf); va_end(va); } void main() { } $ gdc test.d /tmp/ccwm5f8o.o: In function `_D4test6formatFAaYv': test.d:(.text+0x114): undefined reference to `_D4core4stdc6stdarg6va_endFNbPS4core4stdc6stdarg13__va_list_tagZv' collect2: ld returned 1 exit status
 Looks good.  A simpler GCC frontend would be 
 https://github.com/giuseppe/gccbrainfuck
But without the great explanations :)
Sep 23
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 September 2017 at 22:55, Eugene Wissner via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On Saturday, 23 September 2017 at 20:34:51 UTC, Iain Buclaw wrote:
 On 23 September 2017 at 21:45, Eugene Wissner via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 GDC looks pretty nice. I had only one problem: I got a linking error if I
 use core.stdc.stdarg; not sure if it is my failure or a bug. But I could
 build my library and run tests. Pretty nice.
What's the linker error?
Here is the code, test.d: import core.stdc.stdarg; void format(char[] buf, ...) { va_list va; va_start(va, buf); va_end(va); } void main() { } $ gdc test.d /tmp/ccwm5f8o.o: In function `_D4test6formatFAaYv': test.d:(.text+0x114): undefined reference to `_D4core4stdc6stdarg6va_endFNbPS4core4stdc6stdarg13__va_list_tagZv' collect2: ld returned 1 exit status
That would almost certainly only happen if you were using a different druntime. Check where your import modules are coming from, they probably aren't gdc's.
 Looks good.  A simpler GCC frontend would be
 https://github.com/giuseppe/gccbrainfuck
But without the great explanations :)
True, it's more a skeleton front-end, which shows you only the most important files and hooks to be aware of in order to get started.
Sep 24
parent reply Eugene Wissner <belka caraus.de> writes:
On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote:
 That would almost certainly only happen if you were using a 
 different druntime.  Check where your import modules are coming 
 from, they probably aren't gdc's.
Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: import object (/usr/include/d/object.d) import core.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) import core.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) import core.stdc.config (/usr/include/d/core/stdc/config.d) import core.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import __entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place.
Oct 09
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote:
 That would almost certainly only happen if you were using a different
 druntime.  Check where your import modules are coming from, they probably
 aren't gdc's.
Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: import object (/usr/include/d/object.d) import core.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) import core.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) import core.stdc.config (/usr/include/d/core/stdc/config.d) import core.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import __entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place.
It might be a configure flag to change that. Though I think at least Archlinux just applies local patches to all compilers to point the system directory explicitly to different locations. I'd say it's a dmd package bug for putting dmd sources in /usr/include/d, when this should be reserved for more general D application libraries.
Oct 09
parent Eugene Wissner <belka caraus.de> writes:
On Monday, 9 October 2017 at 08:10:41 UTC, Iain Buclaw wrote:
 On 9 October 2017 at 10:03, Eugene Wissner via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:
 On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw 
 wrote:
 That would almost certainly only happen if you were using a 
 different druntime.  Check where your import modules are 
 coming from, they probably aren't gdc's.
Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: import object (/usr/include/d/object.d) import core.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) import core.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) import core.stdc.config (/usr/include/d/core/stdc/config.d) import core.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import __entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place.
It might be a configure flag to change that. Though I think at least Archlinux just applies local patches to all compilers to point the system directory explicitly to different locations. I'd say it's a dmd package bug for putting dmd sources in /usr/include/d, when this should be reserved for more general D application libraries.
I've chosen "/usr/include/d" for dmd since freebsd seems to use it and IIRC the debian-family aswell (I'm maintaining dmd package aswell). I compared installation directories for c/c++ and gcc include files are in "/usr/include/c++/5.3.0/", llvm: "/usr/include/llvm". So the appropriate way would be probably just to put dmd stuff in "/usr/include/dmd". Maybe I'll look into it later again. At least I have a quick solution for now to get both compilers work on one system.
Oct 09