El 01/09/16 a las 18:06, Joseph Rushton Wakeling escribió:
On 31.08.2016 21:35, Joseph Rushton Wakeling wrote:
First things first, run `snapcraft stage`. Then edit the auto-generated
stage/etc/ldc2.conf and replace it with this:
https://gist.github.com/WebDrake/229645efeca14fa54b0b1c82bcbb6477
... which as you can see includes a compiler flag: `-gcc=ldc2.gcc`.
This should
ensure that ldc2.gcc is called when LDC wants to call GCC.
OK, I think I have tied down why this is failing.
Under the hood, LDC does a lookup of the full path to the executable
whose name is passed via the -gcc flag, using
llvm::sys::findProgramByName to do so. If it doesn't get a result, it
first tries to look up CC, and if that fails, it reverts to looking up
the path for gcc.
This would suggest that, running within the snap, LDC is not able to
find the path to ldc2.gcc.
I've also tried passing it
-gcc=%%ldcbinarypath%%/../command-gcc.wrapper and also
-gcc=/snap/ldc2/x1/command-gcc.wrapper and in both cases it still
fails. The weird thing is that the latter works when it's passed
manually:
ldc2.ldmd2 -gcc=/snap/ldc2/x1/command-gcc.wrapper hello.d
Please don't use the wrapper :-)
... but not when it's included in the etc/ldc2.conf file.
This would suggest that something about the snap container is
preventing LDC from resolving the path correctly. Can anyone more
experienced with snappy containment advise what could be going on here?
Any reason why you don't just set it to gcc? If gcc is inside the snap,
it should be in the PATH. To experiment simply run:
snap run --shell ldc2ldmd2
If run from a directory not available while in confinement do a change
dir to $SNAP (or $SNAP_DATA, $SNAP_USER_DATA, ...):
cd $SNAP
Verify the environment:
which gcc
# anything else
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
