Thread overview
Hello world in AAarch64 Debian Buster
Aug 06, 2019
Cecil Ward
Aug 06, 2019
Johannes Pfau
Aug 06, 2019
Cecil Ward
Aug 07, 2019
Iain Buclaw
Aug 08, 2019
Cecil Ward
Aug 28, 2019
Cecil Ward
Aug 31, 2019
Matthias Klumpp
August 06, 2019
I have a raspberry pi 3B+ running raspbian stretch 32-bit with a containerised guest o/s inside it using systemd-nspawn, the guest o/s being AAarch64 Debian Buster.

Inside AAarch64 Debian Buster, I run the following from the shell and get an error from the gdc compiler:

root@debian-buster-64:~#  gdc -O3 -frelease -S test.d
cc1d: error: cannot find source code for runtime library file 'object.d'
cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for installation instructions.

(null):0: confused by earlier errors, bailing out
root@debian-buster-64:~#

Any clues as to where I should head from here?

August 06, 2019
Am Tue, 06 Aug 2019 05:13:11 +0000 schrieb Cecil Ward:

> I have a raspberry pi 3B+ running raspbian stretch 32-bit with a containerised guest o/s inside it using systemd-nspawn, the guest o/s being AAarch64 Debian Buster.
> 
> Inside AAarch64 Debian Buster, I run the following from the shell and get an error from the gdc compiler:
> 
> root@debian-buster-64:~#  gdc -O3 -frelease -S test.d cc1d: error:
> cannot find source code for runtime library file 'object.d'
> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for
> installation instructions.
> 
> (null):0: confused by earlier errors, bailing out
> root@debian-buster-64:~#
> 
> Any clues as to where I should head from here?

You're probably missing libgphobos-dev. However, I think on debian buster there is no arm64 port of libgphobos-dev yet.

Testing seems to have libgphobos-9-dev with arm64 support. If you want to use buster though, you probably have to build gcc by yourself. Just get the gcc 9 sources and use ./configure --enable-languages=d when configuring gcc.


-- 
Johannes
August 06, 2019
On Tuesday, 6 August 2019 at 16:35:21 UTC, Johannes Pfau wrote:
> Am Tue, 06 Aug 2019 05:13:11 +0000 schrieb Cecil Ward:
>
>> I have a raspberry pi 3B+ running raspbian stretch 32-bit with a containerised guest o/s inside it using systemd-nspawn, the guest o/s being AAarch64 Debian Buster.
>> 
>> Inside AAarch64 Debian Buster, I run the following from the shell and get an error from the gdc compiler:
>> 
>> root@debian-buster-64:~#  gdc -O3 -frelease -S test.d cc1d: error:
>> cannot find source code for runtime library file 'object.d'
>> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for
>> installation instructions.
>> 
>> (null):0: confused by earlier errors, bailing out
>> root@debian-buster-64:~#
>> 
>> Any clues as to where I should head from here?
>
> You're probably missing libgphobos-dev. However, I think on debian buster there is no arm64 port of libgphobos-dev yet.
>
> Testing seems to have libgphobos-9-dev with arm64 support. If you want to use buster though, you probably have to build gcc by yourself. Just get the gcc 9 sources and use ./configure --enable-languages=d when configuring gcc.

Thank you very much Johannes. I have never done this before but I thought here goes, so I started out trying to build the whole of GCC including the D language from the sources.

I made a bit of a mess of this, because having written a bash script to set things going, I ran it from the wrong shell, the shell in the host o/s not the one in the guest o/s. So this started off building the wrong architecture variant. I then realised I don’t know how to get my few files into the guest o/s Debian buster’s filesystem (inside its chroot++++ jail) so that’s more fun to work out. But worse than that, the make came up with an error, saying there are a few of dependencies that re not part of the download GMP for example. So I’m going to have to build all of those from the sources as well, and find out how to download them. I could easily get into a circular dependency thing here.

I am so far out of my depth here. Some person who has done this before will have had binaries / object files / targets for those dependencies. Unless the files are just in the wrong place and I need to tell it where they are - which is one suggestion from the error msg.

To recap: I was trying to simply get hold of gdc for aarch64- I didn’t really want to build anything from sources. I suspect this will create additional problems faster than it solves the original ones.

Perhaps I should look around for gdc AArch64 Debian prebuilt binaries or ask someone who knows what on earth they are doing to kindly bootstrap this problem for me.
August 07, 2019
On Wed, 7 Aug 2019 at 00:15, Cecil Ward via D.gnu <d.gnu@puremagic.com> wrote:
>
> On Tuesday, 6 August 2019 at 16:35:21 UTC, Johannes Pfau wrote:
> > Am Tue, 06 Aug 2019 05:13:11 +0000 schrieb Cecil Ward:
> >
> >> I have a raspberry pi 3B+ running raspbian stretch 32-bit with a containerised guest o/s inside it using systemd-nspawn, the guest o/s being AAarch64 Debian Buster.
> >>
> >> Inside AAarch64 Debian Buster, I run the following from the shell and get an error from the gdc compiler:
> >>
> >> root@debian-buster-64:~#  gdc -O3 -frelease -S test.d cc1d:
> >> error:
> >> cannot find source code for runtime library file 'object.d'
> >> cc1d: note: dmd might not be correctly installed. Run 'dmd
> >> -man' for
> >> installation instructions.
> >>
> >> (null):0: confused by earlier errors, bailing out
> >> root@debian-buster-64:~#
> >>
> >> Any clues as to where I should head from here?
> >
> > You're probably missing libgphobos-dev. However, I think on debian buster there is no arm64 port of libgphobos-dev yet.
> >
> > Testing seems to have libgphobos-9-dev with arm64 support. If you want to use buster though, you probably have to build gcc by yourself. Just get the gcc 9 sources and use ./configure --enable-languages=d when configuring gcc.
>
> Thank you very much Johannes. I have never done this before but I thought here goes, so I started out trying to build the whole of GCC including the D language from the sources.
>
> I made a bit of a mess of this, because having written a bash
> script to set things going, I ran it from the wrong shell, the
> shell in the host o/s not the one in the guest o/s. So this
> started off building the wrong architecture variant. I then
> realised I don’t know how to get my few files into the guest o/s
> Debian buster’s filesystem (inside its chroot++++ jail) so that’s
> more fun to work out. But worse than that, the make came up with
> an error, saying there are a few of dependencies that re not part
> of the download GMP for example. So I’m going to have to build
> all of those from the sources as well, and find out how to
> download them. I could easily get into a circular dependency
> thing here.
>
> I am so far out of my depth here. Some person who has done this before will have had binaries / object files / targets for those dependencies. Unless the files are just in the wrong place and I need to tell it where they are - which is one suggestion from the error msg.
>
> To recap: I was trying to simply get hold of gdc for aarch64- I
> didn’t really want to build anything from sources. I suspect this
> will create additional problems faster than it solves the
> original ones.
>
> Perhaps I should look around for gdc AArch64 Debian prebuilt binaries or ask someone who knows what on earth they are doing to kindly bootstrap this problem for me.

You could raise a Debian bug report, saying that aarch64 is in the libphobos supported list.

-- 
Iain

August 08, 2019
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.

I’m assuming that someone somewhere just needs to rerun the make properly, or whatever. Is it a lack of error checking in the makefile or associated tools, which does not ring a bell when things go seriously wrong and allows a bad object file to be created even though the build went wrong internally and became a twisted manky thing before birth.

Building it all myself from sources is certainly a nightmare, so much missing and things left unautomated wrt provision of (non-source) files associated with dependencies.
August 28, 2019
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.
>
> I’m assuming that someone somewhere just needs to rerun the make properly, or whatever. Is it a lack of error checking in the makefile or associated tools, which does not ring a bell when things go seriously wrong and allows a bad object file to be created even though the build went wrong internally and became a twisted manky thing before birth.
>
> Building it all myself from sources is certainly a nightmare, so much missing and things left unautomated wrt provision of (non-source) files associated with dependencies.

Any suggestions as to where I should go from here for a bit (actually a lot) if hand-holding as I An totally out of my death. Just trying to find a human who could build gdc arm64 here for me
August 31, 2019
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.