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/

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.

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 :)

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.

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.

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.

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.