On 4 July 2017 at 23:05, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> Am Tue, 4 Jul 2017 20:42:52 +0200
> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
>> > BTW: Do you know if there's any way to cluster builds by branch on
>> > the buildbot main page? I haven't gotten that far in the docs
>> > yet ;-)
>>
>> Doesn't look like it.
>>
>> https://github.com/buildbot/buildbot/blob/0d44f0344ff82b707d02c75871df23c5f6b9cb8f/www/base/src/app/home/home.tpl.jade#L18-L24
>
> OK, then this is something to look into (a lot) later. I guess buildbot should allow setting up custom sub pages so there's likely some way to implement a per-branch overview.
>

I've turned on gridview, and it looks like something close to what you are asking I think.

https://buildbot.dgnu.org/#/grid?branch=master

Iain

Am Thu, 6 Jul 2017 10:06:45 +0200
schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:

> 
> I've turned on gridview, and it looks like something close to what you are asking I think.
> 
> https://buildbot.dgnu.org/#/grid?branch=master
> 

Looks great!

BTW: Any idea why buildbot built only 7 builds this time? The armhf failure looks also interesting, I'm just checking whether I can reproduce this locally.

-- Johannes

Am Fri, 7 Jul 2017 00:52:20 +0200
schrieb Johannes Pfau <nospam@example.com>:

> Am Thu, 6 Jul 2017 10:06:45 +0200
> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> 
> > 
> > I've turned on gridview, and it looks like something close to what you are asking I think.
> > 
> > https://buildbot.dgnu.org/#/grid?branch=master
> > 
> 
> Looks great!
> 
> BTW: Any idea why buildbot built only 7 builds this time? The armhf failure looks also interesting, I'm just checking whether I can reproduce this locally.
> 

OK, can reproduce. I think it's this in the configure log:

configure:7064:  /buildbot/GDC/build/./gcc/xgcc
-B/buildbot/GDC/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/
-B/usr/arm-linux-gnueabihf/lib/
-isystem /usr/arm-linux-gnueabihf/include
-isystem /usr/arm-linux-gnueabihf/sys-include    -o conftest -g -O2
conftest.c conftstm.o >&5 /usr/arm-linux-gnueabihf/bin/ld: error:
conftest uses VFP register
arguments, /buildbot/GDC/build/./gcc/crtbegin.o does
not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
data of
file /buildbot/GDC/build/./gcc/crtbegin.o /usr/arm-linux-gnueabihf/bin/ld:
error: conftest uses VFP register arguments, /tmp/cczQi3ST.o does
not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
data of file /tmp/cczQi3ST.o /usr/arm-linux-gnueabihf/bin/ld: error:
conftest uses VFP register arguments, conftstm.o does
not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
data of file conftstm.o /usr/arm-linux-gnueabihf/bin/ld: error:
conftest uses VFP register
arguments, /buildbot/GDC/build/./gcc/crtend.o does
not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
data of file /buildbot/GDC/build/./gcc/crtend.o collect2: error: ld
returned 1 exit status


Looks like the GCC configuration does not match the ubuntu arm-linux-gnueabihf-gcc specification exactly.

-- Johannes

On 7 July 2017 at 00:57, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> Am Fri, 7 Jul 2017 00:52:20 +0200
> schrieb Johannes Pfau <nospam@example.com>:
>
>> Am Thu, 6 Jul 2017 10:06:45 +0200
>> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
>>
>> >
>> > I've turned on gridview, and it looks like something close to what you are asking I think.
>> >
>> > https://buildbot.dgnu.org/#/grid?branch=master
>> >
>>
>> Looks great!
>>
>> BTW: Any idea why buildbot built only 7 builds this time? The armhf failure looks also interesting, I'm just checking whether I can reproduce this locally.
>>
>
> OK, can reproduce. I think it's this in the configure log:
>
> configure:7064:  /buildbot/GDC/build/./gcc/xgcc
> -B/buildbot/GDC/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/
> -B/usr/arm-linux-gnueabihf/lib/
> -isystem /usr/arm-linux-gnueabihf/include
> -isystem /usr/arm-linux-gnueabihf/sys-include    -o conftest -g -O2
> conftest.c conftstm.o >&5 /usr/arm-linux-gnueabihf/bin/ld: error:
> conftest uses VFP register
> arguments, /buildbot/GDC/build/./gcc/crtbegin.o does
> not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> data of
> file /buildbot/GDC/build/./gcc/crtbegin.o /usr/arm-linux-gnueabihf/bin/ld:
> error: conftest uses VFP register arguments, /tmp/cczQi3ST.o does
> not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> data of file /tmp/cczQi3ST.o /usr/arm-linux-gnueabihf/bin/ld: error:
> conftest uses VFP register arguments, conftstm.o does
> not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> data of file conftstm.o /usr/arm-linux-gnueabihf/bin/ld: error:
> conftest uses VFP register
> arguments, /buildbot/GDC/build/./gcc/crtend.o does
> not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> data of file /buildbot/GDC/build/./gcc/crtend.o collect2: error: ld
> returned 1 exit status
>
>
> Looks like the GCC configuration does not match the ubuntu arm-linux-gnueabihf-gcc specification exactly.
>
>

Could it be missing --with-float= or --with-fpu configure flag perhaps?  I'm just finishing up a few changes to the build scripts that turn off building phobos.  Can add another check for extra configure flags to be set per-target.

Iain.

Am Fri, 7 Jul 2017 01:12:03 +0200
schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:

> On 7 July 2017 at 00:57, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> > Am Fri, 7 Jul 2017 00:52:20 +0200
> > schrieb Johannes Pfau <nospam@example.com>:
> > 
> >> Am Thu, 6 Jul 2017 10:06:45 +0200
> >> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> >> 
> >> >
> >> > I've turned on gridview, and it looks like something close to what you are asking I think.
> >> >
> >> > https://buildbot.dgnu.org/#/grid?branch=master
> >> > 
> >>
> >> Looks great!
> >>
> >> BTW: Any idea why buildbot built only 7 builds this time? The armhf
> >> failure looks also interesting, I'm just checking whether I can
> >> reproduce this locally.
> >> 
> >
> > OK, can reproduce. I think it's this in the configure log:
> >
> > configure:7064:  /buildbot/GDC/build/./gcc/xgcc
> > -B/buildbot/GDC/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/
> > -B/usr/arm-linux-gnueabihf/lib/
> > -isystem /usr/arm-linux-gnueabihf/include
> > -isystem /usr/arm-linux-gnueabihf/sys-include    -o conftest -g -O2
> > conftest.c conftstm.o >&5 /usr/arm-linux-gnueabihf/bin/ld: error:
> > conftest uses VFP register
> > arguments, /buildbot/GDC/build/./gcc/crtbegin.o does
> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> > data of
> > file /buildbot/GDC/build/./gcc/crtbegin.o /usr/arm-linux-gnueabihf/bin/ld:
> > error: conftest uses VFP register arguments, /tmp/cczQi3ST.o does
> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> > data of file /tmp/cczQi3ST.o /usr/arm-linux-gnueabihf/bin/ld: error:
> > conftest uses VFP register arguments, conftstm.o does
> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> > data of file conftstm.o /usr/arm-linux-gnueabihf/bin/ld: error:
> > conftest uses VFP register
> > arguments, /buildbot/GDC/build/./gcc/crtend.o does
> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
> > data of file /buildbot/GDC/build/./gcc/crtend.o collect2: error: ld
> > returned 1 exit status
> >
> >
> > Looks like the GCC configuration does not match the ubuntu arm-linux-gnueabihf-gcc specification exactly.
> >
> > 
> 
> Could it be missing --with-float= or --with-fpu configure flag perhaps?  I'm just finishing up a few changes to the build scripts that turn off building phobos.  Can add another check for extra configure flags to be set per-target.
> 
> Iain.

Yes, it's likely one of these. I can't test this right now, but the simplest way is running the ubuntu arm-linux-gnueabihf-gcc -v and copy the configuration. We should generally use exactly the same configuration as ubuntu to get reliable results (Otherwise the binutils/libc we use from the distribution might be not compatible with the compiler/libgcc/libstdc++,... libraries we build).

I guess explore.dgnu.org uses the same configuration and it uses:

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 6.3.0-16ubuntu6' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include


-- Johannes

On 7 July 2017 at 01:37, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> Am Fri, 7 Jul 2017 01:12:03 +0200
> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
>
>> On 7 July 2017 at 00:57, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
>> > Am Fri, 7 Jul 2017 00:52:20 +0200
>> > schrieb Johannes Pfau <nospam@example.com>:
>> >
>> >> Am Thu, 6 Jul 2017 10:06:45 +0200
>> >> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
>> >>
>> >> >
>> >> > I've turned on gridview, and it looks like something close to what you are asking I think.
>> >> >
>> >> > https://buildbot.dgnu.org/#/grid?branch=master
>> >> >
>> >>
>> >> Looks great!
>> >>
>> >> BTW: Any idea why buildbot built only 7 builds this time? The armhf failure looks also interesting, I'm just checking whether I can reproduce this locally.
>> >>
>> >
>> > OK, can reproduce. I think it's this in the configure log:
>> >
>> > configure:7064:  /buildbot/GDC/build/./gcc/xgcc
>> > -B/buildbot/GDC/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/
>> > -B/usr/arm-linux-gnueabihf/lib/
>> > -isystem /usr/arm-linux-gnueabihf/include
>> > -isystem /usr/arm-linux-gnueabihf/sys-include    -o conftest -g -O2
>> > conftest.c conftstm.o >&5 /usr/arm-linux-gnueabihf/bin/ld: error:
>> > conftest uses VFP register
>> > arguments, /buildbot/GDC/build/./gcc/crtbegin.o does
>> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
>> > data of
>> > file /buildbot/GDC/build/./gcc/crtbegin.o /usr/arm-linux-gnueabihf/bin/ld:
>> > error: conftest uses VFP register arguments, /tmp/cczQi3ST.o does
>> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
>> > data of file /tmp/cczQi3ST.o /usr/arm-linux-gnueabihf/bin/ld: error:
>> > conftest uses VFP register arguments, conftstm.o does
>> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
>> > data of file conftstm.o /usr/arm-linux-gnueabihf/bin/ld: error:
>> > conftest uses VFP register
>> > arguments, /buildbot/GDC/build/./gcc/crtend.o does
>> > not /usr/arm-linux-gnueabihf/bin/ld: failed to merge target specific
>> > data of file /buildbot/GDC/build/./gcc/crtend.o collect2: error: ld
>> > returned 1 exit status
>> >
>> >
>> > Looks like the GCC configuration does not match the ubuntu arm-linux-gnueabihf-gcc specification exactly.
>> >
>> >
>>
>> Could it be missing --with-float= or --with-fpu configure flag perhaps?  I'm just finishing up a few changes to the build scripts that turn off building phobos.  Can add another check for extra configure flags to be set per-target.
>>
>> Iain.
>
> Yes, it's likely one of these. I can't test this right now, but the simplest way is running the ubuntu arm-linux-gnueabihf-gcc -v and copy the configuration. We should generally use exactly the same configuration as ubuntu to get reliable results (Otherwise the binutils/libc we use from the distribution might be not compatible with the compiler/libgcc/libstdc++,... libraries we build).
>
> I guess explore.dgnu.org uses the same configuration and it uses:
>
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 6.3.0-16ubuntu6' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
>
>

Yeah, however 90% of that is unused by us.  I've added a BUILD_CONFIGURE_FLAGS var to the buildci.sh script.

https://github.com/D-Programming-GDC/buildbot-gdc/commit/47f8c7267682f19b3e1ce2afa49034217413451a#diff-711e8a244e68a7a465f29a18e33a22c3R34

Can add a case for armhf and set --with-fpu= later and see if that gets us further.

Iain.

On Friday, 7 July 2017 at 00:05:16 UTC, Iain Buclaw wrote:
> On 7 July 2017 at 01:37, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
>> Am Fri, 7 Jul 2017 01:12:03 +0200
>> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
>>
>>> On 7 July 2017 at 00:57, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
>>> >[...]
>>>
>>> Could it be missing --with-float= or --with-fpu configure flag perhaps?  I'm just finishing up a few changes to the build scripts that turn off building phobos.  Can add another check for extra configure flags to be set per-target.
>>>
>>> Iain.
>>
>> Yes, it's likely one of these. I can't test this right now, but the simplest way is running the ubuntu arm-linux-gnueabihf-gcc -v and copy the configuration. We should generally use exactly the same configuration as ubuntu to get reliable results (Otherwise the binutils/libc we use from the distribution might be not compatible with the compiler/libgcc/libstdc++,... libraries we build).
>>
>> I guess explore.dgnu.org uses the same configuration and it uses:
>>
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 6.3.0-16ubuntu6' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
>>
>>
>
> Yeah, however 90% of that is unused by us.  I've added a BUILD_CONFIGURE_FLAGS var to the buildci.sh script.
>
> https://github.com/D-Programming-GDC/buildbot-gdc/commit/47f8c7267682f19b3e1ce2afa49034217413451a#diff-711e8a244e68a7a465f29a18e33a22c3R34
>
> Can add a case for armhf and set --with-fpu= later and see if that gets us further.
>
> Iain.

Folks, I am eagerly following the work on GDC related to AARCH64/linux.  I am attempting to duplicate results I see here:
https://buildbot.dgnu.org/#/builders/2/builds/51

build 51 looks as if it succeeds.  In following the configure logs for build 51, I see a buildci.sh script gets run.  I would love to know what gcc configure command gets run.  Are the build artifacts available for download?  In particular, the config.log would be helpful. In my own previous attempts to build on AARCH64, I hit "not implemented" build error in math.d on the ieeeFlags, and would also probably hit "unsupported platform".  It seems that my platform doesn't resolve that it is "arm".  And so I understand how the gdc development process works, will platform support fixes get back ported into older branches of GDC?  Your build is on master, but my question is, are AARCH64 support patches backported into the gdc-7 or gdc-6?  It seems like yes, but I haven't gone through the branches in detail yet.  Thank you for the ARM support!

Am Thu, 07 Dec 2017 21:30:04 +0000
schrieb David J Kordsmeier <dkords@gmail.com>:

> On Friday, 7 July 2017 at 00:05:16 UTC, Iain Buclaw wrote:
> > On 7 July 2017 at 01:37, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> >> Am Fri, 7 Jul 2017 01:12:03 +0200
> >> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> >> 
> >>> On 7 July 2017 at 00:57, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> >>> >[...]
> >>>
> >>> Could it be missing --with-float= or --with-fpu configure flag perhaps?  I'm just finishing up a few changes to the build scripts that turn off building phobos.  Can add another check for extra configure flags to be set per-target.
> >>>
> >>> Iain.
> >>
> >> Yes, it's likely one of these. I can't test this right now, but the simplest way is running the ubuntu arm-linux-gnueabihf-gcc -v and copy the configuration. We should generally use exactly the same configuration as ubuntu to get reliable results (Otherwise the binutils/libc we use from the distribution might be not compatible with the compiler/libgcc/libstdc++,... libraries we build).
> >>
> >> I guess explore.dgnu.org uses the same configuration and it uses:
> >>
> >> Configured with: ../src/configure -v
> >> --with-pkgversion='Ubuntu/Linaro 6.3.0-16ubuntu6'
> >> --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
> >> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
> >> --prefix=/usr --program-suffix=-6 --enable-shared
> >> --enable-linker-build-id --libexecdir=/usr/lib
> >> --without-included-gettext --enable-threads=posix
> >> --libdir=/usr/lib --enable-nls --with-sysroot=/
> >> --enable-clocale=gnu --enable-libstdcxx-debug
> >> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
> >> --enable-gnu-unique-object --disable-libitm
> >> --disable-libquadmath --enable-plugin --with-system-zlib
> >> --disable-browser-plugin --enable-java-awt=gtk
> >> --enable-gtk-cairo
> >> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross/jre
> >> --enable-java-home
> >> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross
> >> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-cross
> >> --with-arch-directory=arm
> >> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj
> >> --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
> >> --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a
> >> --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
> >> --disable-werror --enable-multilib --enable-checking=release
> >> --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> >> --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf-
> >> --includedir=/usr/arm-linux-gnueabihf/include
> >>
> >> 
> >
> > Yeah, however 90% of that is unused by us.  I've added a BUILD_CONFIGURE_FLAGS var to the buildci.sh script.
> >
> > https://github.com/D-Programming-GDC/buildbot-gdc/commit/47f8c7267682f19b3e1ce2afa49034217413451a#diff-711e8a244e68a7a465f29a18e33a22c3R34
> >
> > Can add a case for armhf and set --with-fpu= later and see if that gets us further.
> >
> > Iain.
> 
> Folks, I am eagerly following the work on GDC related to AARCH64/linux.  I am attempting to duplicate results I see here: https://buildbot.dgnu.org/#/builders/2/builds/51
> 
> build 51 looks as if it succeeds.  In following the configure logs for build 51, I see a buildci.sh script gets run.  I would love to know what gcc configure command gets run.  Are the build artifacts available for download?  In particular, the config.log would be helpful. In my own previous attempts to build on AARCH64, I hit "not implemented" build error in math.d on the ieeeFlags, and would also probably hit "unsupported platform". It seems that my platform doesn't resolve that it is "arm".  And so I understand how the gdc development process works, will platform support fixes get back ported into older branches of GDC?  Your build is on master, but my question is, are AARCH64 support patches backported into the gdc-7 or gdc-6?  It seems like yes, but I haven't gone through the branches in detail yet. Thank you for the ARM support!

Sorry to disappoint you, but I think buildbot does not build phobos on AARCH64 yet. Also if you look at the testsuite reports, although buildbots says the testsuite passes, there are still 2417 unresolved testcases and 60 unsupported tests. Most of these are likely missing AARCH64 assembler code.

Maybe I can work on AARCH support for one or two days in the christmas holidays. There's probably not much missing.

And yes, currently we backport all fixes from master, including phobos changes.

-- Johannes

On Friday, 8 December 2017 at 07:56:04 UTC, Johannes Pfau wrote:
> Am Thu, 07 Dec 2017 21:30:04 +0000
> schrieb David J Kordsmeier <dkords@gmail.com>:
>
>> On Friday, 7 July 2017 at 00:05:16 UTC, Iain Buclaw wrote:
>> > On 7 July 2017 at 01:37, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
>> >> [...]
>> >
>> > Yeah, however 90% of that is unused by us.  I've added a BUILD_CONFIGURE_FLAGS var to the buildci.sh script.
>> >
>> > https://github.com/D-Programming-GDC/buildbot-gdc/commit/47f8c7267682f19b3e1ce2afa49034217413451a#diff-711e8a244e68a7a465f29a18e33a22c3R34
>> >
>> > Can add a case for armhf and set --with-fpu= later and see if that gets us further.
>> >
>> > Iain.
>> 
>> Folks, I am eagerly following the work on GDC related to AARCH64/linux.  I am attempting to duplicate results I see here: https://buildbot.dgnu.org/#/builders/2/builds/51
>> 
>> build 51 looks as if it succeeds.  In following the configure logs for build 51, I see a buildci.sh script gets run.  I would love to know what gcc configure command gets run.  Are the build artifacts available for download?  In particular, the config.log would be helpful. In my own previous attempts to build on AARCH64, I hit "not implemented" build error in math.d on the ieeeFlags, and would also probably hit "unsupported platform". It seems that my platform doesn't resolve that it is "arm".  And so I understand how the gdc development process works, will platform support fixes get back ported into older branches of GDC?  Your build is on master, but my question is, are AARCH64 support patches backported into the gdc-7 or gdc-6?  It seems like yes, but I haven't gone through the branches in detail yet. Thank you for the ARM support!
>
> Sorry to disappoint you, but I think buildbot does not build phobos on AARCH64 yet. Also if you look at the testsuite reports, although buildbots says the testsuite passes, there are still 2417 unresolved testcases and 60 unsupported tests. Most of these are likely missing AARCH64 assembler code.
>
> Maybe I can work on AARCH support for one or two days in the christmas holidays. There's probably not much missing.
>
> And yes, currently we backport all fixes from master, including phobos changes.
>
> -- Johannes

Well that explains everything.  Yes, it was clear this is a cross compiler.  I am trying to understand what is left here.  Disappointment is relative, after all, this is 2017.  Nothing can be more disappointing than 2017.  AARCH64 is not a major platform and probably isn't worth exploring further until it is proven this platform is here to stay.  Maybe when iPhones start using AARCH64...Most people only use PC desktop computers.

Seriously man, where do I need to send funds to make sure this gets done?  It's been a solid year that this hasn't been resolved for GDC, and we've had AARCH64 platforms in volume since 2016.  Rust and Go have resolved their AARCH64 issues with on target compilers as well as runtime support in this past year.  I recognize the switch to AARCH64 has been difficult for literally every open source project.  If financial incentives can help GDC let me know.  I would like to make this a very Merry Christmas for all of us in AARCH64-landia.