Re: GDC in Slackware and a bit about GDC development

2017-10-09 Thread Eugene Wissner via Digitalmars-d-announce

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


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

2017-10-09 Thread Iain Buclaw via Digitalmars-d-announce
On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce
 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:
>
> 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

2017-10-09 Thread Eugene Wissner via Digitalmars-d-announce

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

2017-09-24 Thread Iain Buclaw via Digitalmars-d-announce
On 23 September 2017 at 22:55, Eugene Wissner via
Digitalmars-d-announce  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
>>  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

2017-09-23 Thread Eugene Wissner via Digitalmars-d-announce

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


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

2017-09-23 Thread Iain Buclaw via Digitalmars-d-announce
On 23 September 2017 at 21:45, Eugene Wissner via
Digitalmars-d-announce  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.