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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017