Closed WebDrake closed 7 years ago
As a secondary question: what platform architectures are currently supported by LDC (in terms of actually running on those platforms)? I imagine amd64 and x86, but any others ... ?
This will require authorizing some GitHub hooks via my account and on behalf of the ldc-developers group. @klickverbot @JohanEngelen is it OK to move forwards with this?
Ping on this? I'm asking simply because I don't feel comfortable asking a 3rd-party webapp to hook into the ldc-developers group without an OK from others.
Sure, let's go ahead with this – just didn't notice this earlier.
Hmmm, well, this ran into a brick wall quickly :-P They only detect/handle repos under my own handle, despite giving them access to the ldc-developers group. I'll follow up and see what can be done ...
In the short term, one option would be to use Launchpad to build and push the packages. Would it be OK to set up an ldc-developers team there? (I'd rather not just set up a project via my own launchpad account, although that's easy to do if need be.)
I can't see any potential issues with that either.
OK. There's now a new ldc-developers group on Launchpad: https://launchpad.net/~ldc-developers
... which owns a new ldc2 snap package project: https://launchpad.net/ldc2.snap
... which has a git clone of the present GitHub repo: https://code.launchpad.net/~ldc-developers/ldc2.snap/+git/ldc2.snap
... which is set up to automatically build a new snap package every time the master branch is updated (it pulls every 5 hours from the github repo): https://code.launchpad.net/~ldc-developers/+snap/ldc2
Currently it looks like i386 builds are failing, but I think that's a known issue that should be fixed shortly (https://bugs.launchpad.net/snapcraft/+bug/1665165). The amd64 build is proceeding fine so far.
Are there any other processors it would be worth building for? Those available (besides amd64 and i386) are arm64, armhf, powerpc, powerpc64el and s390x.
There's now a new ldc-developers group on Launchpad
BTW if anyone else from the LDC team wants to sign up on Launchpad (or is already), I can add them to the members of this group, and invite them as collaborators on the snap package. Just in case an elephant falls on me at DConf, or something like that.
My account name there is the same as here. (For whatever reason, I seem to have ended up with two accounts after the whole Ubuntu One login thing.)
OK, you should be in the team now. An amd64 build of the updated package is now in progress now that the git/https URL issue is fixed.
I've run into a couple of slightly unpleasant issues with the Launchpad build service which are getting in the way of building the package successfully.
the build service only supports https://
URLs when cloning git repos (see: https://bugs.launchpad.net/launchpad-buildd/+bug/1663920), and LDC's .gitmodules
file uses git://
instead. I can send a patch to address this, but presumably that would require a further patch release for me to be able to use it.
I could use the source tarballs that can be downloaded directly from GitHub (cf. https://github.com/ldc-developers/ldc2.snap/pull/23), but this runs into a rather subtle issue: because the snap package itself is git-hosted, the CMakeLists
rules to check the git describe
output clash with the stated LDC_VERSION
, and I wind up with the hash ID of the latest snap package commit (!) being included in the version number of the bootstrap compiler. Are there any ready ways to prevent the git describe
output being taken into account?
Any thoughts on what would be the best way forward (with least inconvenience to LDC developers)?
N.B. there is a 3rd option, which is to wait for the Launchpad devs to fix https://bugs.launchpad.net/launchpad-buildd/+bug/1663920.
Latest ltsmaster and release-1.2.x branches now work with the Launchpad build system; I have successfully built amd64 and i386 patches from the devel
branch. I will start publishing these builds via the edge
channel once 0.17.4 and 1.2.0-beta2 are tagged.
OK, so, both ARM builds failed (not entirely a surprise), but for different reasons.
armhf
failed because the custom C flags used are not supported:
[ 69%] Building C object runtime/CMakeFiles/druntime-ldc.dir/druntime/src/core/stdc/errno.c.o
cd /build/ldc2/parts/ldc/build/runtime && /usr/bin/cc -DLDC_WITH_PGO -I/build/ldc2/parts/ldc/src/. -I/build/ldc2/parts/ldc/src/ddmd -I/build/ldc2/parts/ldc/src/ddmd/root -I/build/ldc2/parts/ldc/build/ddmd -I/build/ldc2/parts/ldc/src -isystem /build/ldc2/parts/llvm/install/include -O3 -DNDEBUG -Wa,-mrelax-relocations=no -fPIC -o CMakeFiles/druntime-ldc.dir/druntime/src/core/stdc/errno.c.o -c /build/ldc2/parts/ldc/src/runtime/druntime/src/core/stdc/errno.c
Assembler messages:
Error: unrecognized option -mrelax-relocations=no
runtime/CMakeFiles/druntime-ldc.dir/build.make:2765: recipe for target 'runtime/CMakeFiles/druntime-ldc.dir/druntime/src/core/stdc/errno.c.o' failed
make[2]: *** [runtime/CMakeFiles/druntime-ldc.dir/druntime/src/core/stdc/errno.c.o] Error 1
make[2]: Leaving directory '/build/ldc2/parts/ldc/build'
... while arm64
failed because of a static assert in std.math
:
[ 59%] Building C object runtime/CMakeFiles/druntime-ldc-debug.dir/druntime/src/ldc/arm_unwind.c.o
/build/ldc2/parts/ldc-bootstrap/src/runtime/phobos/std/math.d(1705): Error: static assert "Not implemented for this architecture"
runtime/CMakeFiles/phobos2-ldc-debug.dir/build.make:249: recipe for target 'runtime/std/math-debug.o' failed
make[2]: *** [runtime/std/math-debug.o] Error 1
CMakeFiles/Makefile2:429: recipe for target 'runtime/CMakeFiles/phobos2-ldc-debug.dir/all' failed
make[1]: *** [runtime/CMakeFiles/phobos2-ldc-debug.dir/all] Error 2
I'll have to look into whether it's possible to set different C flags for different architectures, but in any case, I think support for ARM is a slight long shot right now. Curious about what the std.math
static assert is, though (one to check out in the next days...).
I've now had a bunch of successful automated builds and uploads via Launchpad, for both i386 and amd64, so I think this issue can reasonably be considered closed.
Where other architectures are concerned I think this can be addressed via separate PRs and issues. ARM builds probably need specific input/advice anyway.
Ubuntu is now offering an automated build service for snaps, which will automatically build and push out a new revision of the snap package whenever the master branch is updated: https://build.snapcraft.io/
This will require authorizing some GitHub hooks via my account and on behalf of the ldc-developers group. @klickverbot @JohanEngelen is it OK to move forwards with this?