Re: GDC in Slackware and a bit about GDC development
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-announcewrote: 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: importobject(/usr/include/d/object.d) importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) importcore.stdc.config (/usr/include/d/core/stdc/config.d) importcore.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.
Re: GDC in Slackware and a bit about GDC development
On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announcewrote: > 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: > > importobject(/usr/include/d/object.d) > importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) > importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) > importcore.stdc.config (/usr/include/d/core/stdc/config.d) > importcore.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.
Re: GDC in Slackware and a bit about GDC development
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: importobject(/usr/include/d/object.d) importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) importcore.stdc.config (/usr/include/d/core/stdc/config.d) importcore.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.
Re: GDC in Slackware and a bit about GDC development
On 23 September 2017 at 22:55, Eugene Wissner via Digitalmars-d-announcewrote: > 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 >> 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.
Re: GDC in Slackware and a bit about GDC development
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-announcewrote: 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 :)
Re: GDC in Slackware and a bit about GDC development
On 23 September 2017 at 21:45, Eugene Wissner via Digitalmars-d-announcewrote: > 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.