www.digitalmars.com         C & C++   DMDScript  

D.gnu - Hello world in AAarch64 Debian Buster

reply Cecil Ward <d cecilward.com> writes:
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:


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


Any clues as to where I should head from here?
Aug 05 2019
parent reply Johannes Pfau <nospam example.com> writes:
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:
 

 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

 
 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
Aug 06 2019
parent reply Cecil Ward <d cecilward.com> writes:
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:
 

 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

 
 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.
Aug 06 2019
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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:


 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


 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
Aug 06 2019
parent reply Cecil Ward <d cecilward.com> writes:
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.
Aug 07 2019
next sibling parent Cecil Ward <d cecilward.com> writes:
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
Aug 27 2019
prev sibling parent Matthias Klumpp <mak debian.org> writes:
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.
Aug 31 2019