ArchLinux ARM needs someone to support a community package for gdc

[truedat101]

The package has been removed because support from a community member stopped. Someone needs to step back in.

[truedat101]

Related to #57. Sounds like the upstream packages for gdc are back and could be brought back into Arch Linux ARM. I guess I'm still not sure about the future of gdc ... I'd heard that gdc was getting rolled into the upstream gcc project, and so maybe this is not needed down the road. Need to investigate exactly what the state of gcc/gdc is.

[truedat101]

Per Kevin - this is done:

aarch64	community	gdc	8.2.1+2.068.2-2	Compiler for D programming language which uses gcc backend
armv6h	community	gdc	8.2.1+2.068.2-2	Compiler for D programming language which uses gcc backend
armv7h	community	gdc	8.2.1+2.068.2-2	Compiler for D programming language which uses gcc backend
arm	community	gdc	8.2.1+2.068.2-2	Compiler for D programming language which uses gcc backend

[truedat101]

Leaving this open until I can verify the package runs. Needs:

• mpfr
• fix the link to the missing library libmpfr.so.4

When running gdc, get a failure:

gdc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found

Will look into this and ping @kmihelich if I can't figure out this one. This is in the gdc package itself, so maybe it's missing? Or named differently.

[truedat101]

Here's a possible clue: https://bugs.archlinux.org/task/59968

@kmihelich I don't see a real root cause in the issue above.

[kmihelich]

I'm working on a toolchain update now, and I'll try a gdc rebuild after that.

[truedat101]

Ok, thanks. Apologies haven't done a deep dive on what ails the upstream GDC in awhile.

[kmihelich]

gdc has been rebuilt, and a Hello World example compiles and runs for me. Give it a shot.

[truedat101]

Ok, sorry, just saw this. I'll fire this up and see.

[truedat101]

Ok, installed:

[root@alarm ~]# pacman -S gdc
resolving dependencies...
looking for conflicting packages...

Packages (1) gdc-8.2.1+2.068.2-2.1

Total Download Size:    6.35 MiB
Total Installed Size:  20.88 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n] Y
:: Retrieving packages...
 gdc-8.2.1+2.068.2-2...     6.4 MiB  2.84M/s 00:02 [######################] 100%
(1/1) checking keys in keyring                     [######################] 100%
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) checking available disk space                [######################] 100%
:: Processing package changes...
(1/1) upgrading gdc                                [######################] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

[truedat101]

Still fails exactly same manner:

[root@alarm dlang-testbench.git]# gdc testall.d
gdc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

[truedat101]

Here's the reference I found to this issue regarding archlinux: https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D.gnu&artnum=7904

So, gdc/gcc version mismatch? Not really sure that's the solution, but certainly having built gdc lots of times, the versions have to match up.

[truedat101]

@kmihelich Anything I can do to help here? I was at one point, somewhat expert at building gdc. I think the first step is getting the recipe correct for the initial configure step done. I can probably dig up my notes and compare with the package you are using and see if we need to patch anything.

[kmihelich]

Any suggestions you have would be helpful, I'm at a loss at the moment.

[truedat101]

It's been awhile since I've done gdc builds. I think I've got the code on my build host to refresh this. I'll reference your work on this, I guess from here: https://archlinuxarm.org/packages/armv7h/gdc/log looks like last cut was back in January. I have my old build notes on this (trials and tribulations).

[truedat101]

So -enable-lto seems to be the culprit. I'm looking at some other posts on this topic not related to GDC, simply talking about adding it to the infrastructure for building packages, and how to actually change the tuning of the optimization, plus breakages: http://yuguangzhang.com/blog/enabling-gcc-graphite-and-lto-on-gentoo/

[truedat101]

@kmihelich to simply get past the "gdc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found", I'm suggesting change the configure flag: --enable-lto

to: -fno-lto -fno-use-linker-plugin

?

I'll separately continue investigating why liblto_plugin.so isn't generated or found (possibly it's there, but named differently...).

[kmihelich]

Give this build a shot. LTO should be removed in this. https://archlinuxarm.org/builder/testing/gdc/

[truedat101]

Will give this a try.

[truedat101]

Going to test tonight when I get back.

[truedat101]

Ok, so a few data points:

• No luck, same problem.
• Leads me to believe there's a configuration problem in the use of the compiler, maybe an LD_LIBRARY_PATH? Not sure.

I did a digging around the /usr/lib, and found:

./bfd-plugins/liblto_plugin.so
./gcc/aarch64-unknown-linux-gnu/7.2.1/liblto_plugin.so.0.0.0
./gcc/aarch64-unknown-linux-gnu/7.2.1/lto-wrapper
./gcc/aarch64-unknown-linux-gnu/7.2.1/liblto_plugin.so
./gcc/aarch64-unknown-linux-gnu/7.2.1/plugin/include/lto-section-names.h
./gcc/aarch64-unknown-linux-gnu/7.2.1/plugin/include/lto-streamer.h
./gcc/aarch64-unknown-linux-gnu/7.2.1/plugin/include/lto-compress.h
./gcc/aarch64-unknown-linux-gnu/7.2.1/lto1
./gcc/aarch64-unknown-linux-gnu/7.2.1/liblto_plugin.so.0
./modules/4.14.10-1-ARCH/kernel/drivers/hid/hid-waltop.ko.gz

Also, here's the details of the gdc build:

[root@alarm lib]# gdc -v
Using built-in specs.
COLLECT_GCC=gdc
Target: aarch64-unknown-linux-gnu
Configured with: /build/gdc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c++,d --enable-checking=release --enable-link-mutex --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-multilib --enable-shared --enable-static --enable-threads=posix --disable-libmpx --with-system-zlib --with-isl --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-default-pie --enable-default-ssp --with-bugurl=https://bugzilla.gdcproject.org/ --with-pkgversion='GDC 8.2.1 based on D v2.068.2 built with ISL 0.20 for Arch Linux' gdc_include_dir=/usr/include/dlang/gdc --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --with-arch=armv8-a
Thread model: posix
gcc version 8.2.1 20180831 (GDC 8.2.1 based on D v2.068.2 built with ISL 0.20 for Arch Linux)

[truedat101]

So an interesting thing, I think my configuration advice was totally wrong: -fno-use-linker-plugin is a compiler flag.

If I set gdc -fno-use-linker-plugin , this fails with a different error:

[root@alarm dlang-testbench.git]# gdc -fno-use-linker-plugin testall.d ld: cannot find crtbeginS.o: No such file or directory ld: cannot find -lgcc

[truedat101]

Sorry, this looks like a dark corner. I will have to investigate the build and the original issue related to lto.

[kmihelich]

Can you send me that testall.d file you're using?

[truedat101]

Actually it's just this: https://github.com/IoTone/dlang-testbench

The goal with that one is to weed out any platform issues by using every known package that I could think of (not sure where I got this original source from).

[truedat101]

The most simple D program is just a hello world, Save in hello.d:

import std.stdio;

void main()
{
    writeln("Hello, world!");
}

This should compile on any d compiler with a phobos library, but it might not catch all portability issues (different api spec, missing libraries).

[truedat101]

I think the reason I wrote the testbench was to deal with math issues I found on openwrt.

[truedat101]

Also, the gdc compile is sort of like gcc. Just run gdc and that will output a built executable or errors. Otherwise, use dub to build "packages", and that is simply: dub

and it will run the build in any directory with a package.json.

[kmihelich]

I'm not seeing any issue compiling or running on any of my AArch64 devices with the repo gdc packages, and with the systems up to date. gdc -o app app.d testallpkgs.d compiles fine, and it counts down the beer on the wall.

[truedat101]

Let me grab a fresh download of Arch ... maybe my kernel/packages are out of date?

[truedat101]

created a new image on a clean brand new espressobin. Added dub and gdc. And yes, got the build done with successful beer count:

2 bottles of beer on the wall,
2 bottles of beer.
Take one down, pass it around,
1 bottle of beer on the wall.

1 bottle of beer on the wall,
1 bottle of beer.
Take one down, pass it around,
0 bottles of beer on the wall.

OK, yeah

[truedat101]

I'll mark this as closed. Thanks! This one took a long time (for the Dlang core to get the AARCH64 story done for gdc ... maybe 2 years to get the bugs worked out).

One to ldc2. I'll ping you on that one once I know the status of ldc2 on aarch64.

[kmihelich]

ldc should be good. That's the compiler used for other D packages in the repo, and all of those are building.

[truedat101]

Interesting to note: gdc build is quite large vs ldc:

-rwxr-xr-x 2 root root 4621088 Mar 12 03:32 dlang-testbench -rwxr-xr-x 1 root root 549120 Mar 12 03:32 dlang-testbench-ldc

[truedat101]

gdc specs:

gdc -v Using built-in specs. COLLECT_GCC=gdc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-unknown-linux-gnu/8.2.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /build/gdc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/sha Thread model: posix gcc version 8.2.1 20180831 (GDC 8.2.1 based on D v2.068.2 built with ISL 0.20 for Arch Linux)