> Wiadomość napisana przez Joseph Rushton Wakeling > <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
