Snapping LDC (LLVM-based D compiler)

[Zygmunt Krynicki]

> Wiadomość napisana przez Joseph Rushton Wakeling <joseph.wakeling at webdrake.net> w dniu 27.08.2016, o godz. 22:45:
> 
> Hello all,
> 
> I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the D programming language.  I recognize that snapping a compiler might be jumping ahead of the current intended use-case(s), but it's fun to see what could be possible -- and besides, D's compilers are updated fairly often, so it would be great to be able to package them easily in a truly cross-distro form.
> 
> It's been very exciting to see how straightforward most things are to get set up, but I ran into a few issues that are blockers to finalizing the snap, so I thought I'd ask here for advice on how to address them.
> 
> First things first: LDC is built using cmake, and getting the essentials of the `snapcraft.yaml` file set up was super-simple:
> 
> -----------------------------------------
> name: ldc
> version: "1.0.0"
> summary: D compiler with LLVM backend
> description: LDC is a compiler for the D programming Language.
>             It is based on the latest DMD frontend and uses LLVM as backend.
> confinement: devmode
> 
> apps:
>  ldc2:
>    command: ldc2
>    plugs: [home]
>  ldmd2:
>    command: ldmd2
>    plugs: [home]
> 
> parts:
>  ldc:
>    plugin: cmake
>    source: git://github.com/ldc-developers/ldc.git
>    source-tag: v1.0.0
>    build-packages:
>    - ldc
>    - llvm-dev
>    - libconfig++-dev
>    - libcurl4-gnutls-dev
>    - libedit-dev
>    - zlib1g-dev
> -----------------------------------------
> 
> This happily builds and generates a snap, and so far as I can tell from the install, all the usual required files are there.  (By the way, I really do mean to have ldc in the `build-packages`; LDC now requires a D compiler to build it, so it's necessary to have the older ubuntu-packaged ldc 0.17.1 to build with.)
> 
> The problems with the snap are threefold:
> 
>  * LDC creates two different executables, ldc2 and ldmd2 (the latter is a
>    wrapper that implements compiler flags to match D's reference compiler,
>    "Digital Mars D" or dmd).  However, the names given to the snap executables
>    are ldc.ldc2 and ldc.ldmd2.  While I understand the wish to namespace, is
>    there any way to drop the `ldc.` prefix ... ?
> 
>  * LDC creates a config file, `/etc/ldc2.conf`, using libconfig.  This defines
>    some default compiler flags, including the default 'include' location of
>    header files for the runtime and standard library.  However, perhaps because
>    of how the snap is built, the include paths are specified as if the snap's
>    install dir was the root:
> 
>        switches = [
>            "-I/include/d/ldc",
>            "-I/include/d",
>            "-L-L/lib",
>            "-defaultlib=phobos2-ldc,druntime-ldc",
>            "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
>        ];
> 
>    This means that when one tries to compile anything, the compiler emits
>    error messages that it is unable to locate the headers for runtime or
>    standard-library modules.  If one manually specifies the full-path
>    include locations:
> 
>        -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d
> 
>    ... then the compiler can build an object file, but runs into the third
>    of the problems ...
> 
>  * LDC uses the default C compiler for linking, but the snap-installed
>    compiler fails to find it, exiting with a message:
> 
>        Error: failed to locate gcc


You can try to „see” gcc via /var/lib/snapd/hostfs/usr/bin/gcc but I bet it won’t „just work” because we are now in a chroot [1]. You could try to put gcc inside your own snap (I would actually do this to stay fully self-contained) but that might require different work to snap.

Given enough permissions you could get out of the chroot and run host’s gcc with appropriate arguments but you might run into issues with passing files around by path (see the referenced link for details). If you only use -pipe then things should work.

We also have snapd-xdg-open and I was wondering if it would be okay to extend it to do things like „run this command on the host with the permission of the current user” if the command can be white-listed to belong to an interface (e.g. you we could say that LDC has permissions to run „gcc” with any arguments).

[1] http://www.zygoon.pl/2016/08/snap-execution-environment.html <http://www.zygoon.pl/2016/08/snap-execution-environment.html>

> 
> Can anyone advise on how best to address any of these problems?  I would assume the last in particular is down to the lack of an interface for access to things like a linker or other aspects of a build system?
> 
> I'm really delighted with how blissfully simple it was to get the essentials of packaging in place, and it would be really great if there were straightforward solutions to the remaining issues.
> 
> Thanks in advance for any advice, and best wishes,
> 
>    -- Joe
> 
> -- 
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160829/6b23263b/attachment.html>