Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
September 23, 2017 GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
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/ |
September 23, 2017 Re: GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eugene Wissner | 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. |
September 23, 2017 Re: GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 :) |
September 24, 2017 Re: GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eugene Wissner | 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. |
October 09, 2017 Re: GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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. |
October 09, 2017 Re: GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eugene Wissner | 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. |
October 09, 2017 Re: GDC in Slackware and a bit about GDC development | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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.
|
Copyright © 1999-2021 by the D Language Foundation