(Token t) is not callable using argument types (Token): GDC bug or not?
Hi! When compiling Dustmite on Debian with GDC, the build runs into the following error on i386: ``` splitter.d:875:15: error: function splitter.DSplitter.postProcessBlockStatements.consume (Token t) is not callable using argument types (Token) if (consume(tokenLookup["if"]) || consume(tokenLookup["static if"])) ^ debian/rules:9: recipe for target 'override_dh_auto_build' failed ``` This only happens on i386 and other 32bit architectures, amd64 and even x32 are fine. Looking at the source code at https://github.com/CyberShadow/DustMite/blob/master/splitter.d#L875 , I can't find any obvious programming issue, so I currently assume that this is a GDC bug. Or am I missing something? In the former case, I'd file a bug against GDC. Cheers, Matthias
Re: (Token t) is not callable using argument types (Token): GDC bug or not?
Btw, the full build matrix with logs for all architectures can be viewed at https://buildd.debian.org/status/package.php?p=dustmite
Re: (Token t) is not callable using argument types (Token): GDC bug or not?
On Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote: On 29 January 2017 at 19:12, Iain Buclaw wrote: On 29 January 2017 at 17:59, Matthias Klumpp via D.gnu wrote: Hi! When compiling Dustmite on Debian with GDC, the build runs into the following error on i386: ``` splitter.d:875:15: error: function splitter.DSplitter.postProcessBlockStatements.consume (Token t) is not callable using argument types (Token) if (consume(tokenLookup["if"]) || consume(tokenLookup["static if"])) ^ debian/rules:9: recipe for target 'override_dh_auto_build' failed ``` This only happens on i386 and other 32bit architectures, amd64 and even x32 are fine. Looking at the source code at https://github.com/CyberShadow/DustMite/blob/master/splitter.d#L875 , I can't find any obvious programming issue, so I currently assume that this is a GDC bug. Or am I missing something? In the former case, I'd file a bug against GDC. Cheers, Matthias Whatever it is, it would be frontend-related (the error is semantic related, not codegen). I don't have any 32bit boxes to try out, unless I am able to reproduce this in a container or debootstrap-chroot. And I can't reproduce using -m32 with current git head either, nor the gdc-5 package that I have readily available on my laptop. Crazy... It's definitely not a frontend issue, since this compiles fine with DMD apparently I need to attempt a build of the package in a local 32bit chroot and see if that reproduces the issue. Alternatively I could also compile with LDC, but I deliberately picked GDC here to have Dustmite available on more architectures. Btw, while Debian has GDC on a lot of architectures, it seems to only be working on very few.
Re: Hello world in AAarch64 Debian Buster
On Thursday, 8 August 2019 at 01:17:53 UTC, Cecil Ward wrote: On Wednesday, 7 August 2019 at 05:48:49 UTC, Iain Buclaw wrote: You could raise a Debian bug report, saying that aarch64 is in the libphobos supported list. Thanks Iain, I went through the prompts in the Debian bug report program and I hope that that has emailed a report to them which makes some kind of sense. Probably not, you need to send an email to submit abug and if you didn't have a fully configured MTA installed or reportbug configured to use some other means to send the mail, it wouldn't have been sent. See https://www.debian.org/Bugs/Reporting on how to create such a mail. In any case, GCC in Buster won't be changed, while in Bullseye (current Testing) it is already adjusted for GDC 9. So, you could potentially fetch gdc-9 from bullseye for buster, or actually just switch to using the Debian Bullseye development version. Depending on what you want to achieve, using Bullseye may be the easiest way to achieve your goal.
Re: GDC bug? duplicates symbols when using mixin and interface
On Tuesday, 29 October 2019 at 13:23:33 UTC, Daniel Kozak wrote: On Thursday, 24 October 2019 at 11:05:21 UTC, Daniel Kozak wrote: ld: c.o: in function `_DT16_D1b1B8__mixin24getSMFZPv': c.d:(.text+0x27): multiple definition of `_DT16_D1b1B8__mixin24getSMFZPv'; b.o:b.d:(.text+0x38): first defined here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216 Thank you for reporting this! This error is also a major pain for us at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944380
Re: gdc broken by ldc-phobos-devel on Fedora
On Wednesday, 20 November 2019 at 21:51:58 UTC, mipri wrote: Howdy, This was the case in Fedora 30, and is now the case in Fedora 31. RPMs are available for gdc and for ldc2, but when both are installed gdc can't compile anything as it tries to load a version of phobos installed by ldc2 which has features gdc doesn't yet support. For someone who's decided to just use gdc for a project, they have the easy fix of just uninstalling ldc2, but I'd expect that someone evaluating D as a language will be interested in comparing the different compilers, so all the compilers will be installed--and then only dmd and ldc will be functional. That's why we explicitly set the LDC include path in Debian: https://salsa.debian.org/d-team/ldc/blob/master/debian/rules#L15 This is a bug in Fedora, you could file an issue with the package at Fedora and ask them to do the same as Debian for include paths. (we do set the path explicitly as linked, and also apply this patch: https://salsa.debian.org/d-team/ldc/blob/master/debian/patches/02_ldc_include_path.diff Cheers, Matthias
