On 09/22/2016 01:24 AM, Adonay Felipe Nogueira wrote:
$ guix build --fallback "cryptopp"
# Begin of output
starting phase `build'
make: *** No rule to make target 'dynamic'. Stop.
phase `build' failed after 0.2 seconds
with exit code 1
build-failed /gnu/store/k863vf0ab6hkdhbm7zgmbfs1c3wdqpqs-cryptopp-5.6.4.drv - 1
builder for `/gnu/store/k863vf0ab6hkdhbm7zgmbfs1c3wdqpqs-cryptopp-5.6.4.drv'
failed with exit code 1
guix build: error: build failed: build of
# End of output
The problem is that you've been tarbombed, as it were - the zip file
contains the source code files in its base directory, and then after
unzipping in the builder a test directory is entered. You can see this
by inspecting the 'environment-variables' file in the build directory.
Our usual fix for this is to use 'url-fetch/tarbomb' rather than
'url-fetch', but it seems that 'url-fetch/tarbomb' does not correctly
handle zip files.
We should fix 'url-fetch/tarbomb', but in the meantime I suggest
replacing the unpack phase like so:
(lambda* (#:key source #:allow-other-keys)
(and (zero? (system* "unzip" source "-d" "source"))
(begin (chdir "source") #t))))
## Additional subject: Absence of `ldconfig`
Seeing the GNUmakefile, it seems to expect some commands to be available
in the environment, so I tried finding those and seeing if the
environment sees them from the profile.
This indicates that `ldconfig` is absent. Someone in #guix told me that
it was supposed to be provided by
It seems that this line hard-codes the path to ldconfig, so it will need
to be modified.
LDCONF ?= /sbin/ldconfig -n
Additionally, `which` was included in the output (comes from the
"debianutils" package on .deb-based distributions) and is also absent,
and the GNUmakefile seems to expect `which` at some point (although I'm
not sure if the build process reached that), so the absence of `which`
might be good to discuss on other bug report.
'which' is provided by the 'which' package.