I try to run stack setup on nixos and get the following error.
$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
Running /home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2.temp/ghc-8.0.2/configure --prefix=/home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2/ in directory /home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2.temp/ghc-8.0.2/ exited with ExitFailure 1
checking for path to top of build tree...
/home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2.temp/ghc-8.0.2/configure: utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: /bin/bash: bad interpreter: No such file or directory
configure: error: cannot determine current directory
Error: Error encountered while configuring GHC with
/home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2.temp/ghc-8.0.2/configure --prefix=/home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2/
run in /home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2.temp/ghc-8.0.2/
The following directories may now contain files, but won't be used by stack:
- /home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2.temp/
- /home/matthew/.stack/programs/x86_64-linux/ghc-8.0.2/
Configuring GHC ...
It seems that the error is due to the fact that nixos does not have the conventional /bin/bash location (bash is instead located at /run/current-system/sw/bin/bash for my nixos setup).
A similar error was raised here -- That issue was apparently resolved by updating stack, but I already have stack's most recent version so my issue must be different.
Should I run $ ln -s /run/current-system/sw/bin/bash /bin/bash, creating a symbolic link at the bash path stack seems to expect? Or is there perhaps some way of informing stack of my system's bash location?
In addition to finding a solution that can simply work, I am also wondering whether there a particular solution that is consistent with the nixos philosophy of immutability, reproducability, etc.
Related
I'm trying to install frama-c on my distro of manjaro 18.1.5, but no matter what I try, I always have an error.
First I tried to install via the AUR, and it seems to work, but when i try to open a file from the gui, it fails and says something like "invalid user input" even though I use files that works on a known good install.
Edit: here is the error output for this file:
[kernel] Parsing max.c (with preprocessing)
[kernel:annot-error] max.c:2: Warning:
unbound logic variable INT_MIN. Ignoring logic specification of function max
[kernel] User Error: warning annot-error treated as fatal error.
[kernel] User Error: stopping on file "max.c" that has errors. Add '-kernel-msg-key pp'
for preprocessing command.
Then I tried to install it using opam, so I first try to install dependencies with depext but it does not install anything then when I tried to install frama-c, it fails with the following error :
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ERROR] The compilation of frama-c failed at
"/home/benoit/.opam/opam-init/hooks/sandbox.sh build make -j7".
#=== ERROR while compiling frama-c.20.0 =======================================#
# context 2.0.5 | linux/x86_64 | ocaml-system.4.09.0 | https://opam.ocaml.org#2d21a0b6
# path ~/.opam/default/.opam-switch/build/frama-c.20.0
# command ~/.opam/opam-init/hooks/sandbox.sh build make -j7
# exit-code 2
# env-file ~/.opam/log/frama-c-4880-6d07ae.env
# output-file ~/.opam/log/frama-c-4880-6d07ae.out
### output ###
# [...]
# Ocamlopt src/plugins/value/legacy/eval_terms.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_transfer.cmx
# Ocamlopt src/plugins/value/legacy/eval_annots.cmx
# Ocamlopt src/plugins/value/engine/transfer_logic.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_domain.cmx
# /usr/bin/ld: cannot find -lgtksourceview-2.0
# collect2: error: ld returned 1 exit status
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_specification.cmx
# File "_none_", line 1:
# Error: Error while building custom runtime system
# make: *** [Makefile:1294: bin/viewer.byte] Error 2
# make: *** Waiting for unfinished jobs....
My final attempt was to build it from source, but the make fails with the following error :
Ocamlc src/plugins/server/jbuffer.cmo
File "src/plugins/server/jbuffer.ml", line 23, characters 12-26:
23 | type json = Yojson.Basic.t
^^^^^^^^^^^^^^
Error: Unbound type constructor Yojson.Basic.t
make: *** [share/Makefile.generic:78: src/plugins/server/jbuffer.cmo] Error 2
My only remaining solution is to use a VM with debian but it's really ideal for me...
Does anyone have an idea of what i could do?
Thank you!
There are multiple issues in your question, and I believe some of them are worthy of investigation as possible bugs or issues. I'd recommend trying one of the official Frama-C support channels:
Creating an issue in the Frama-C Gitlab public repository;
Or creating an issue in the Frama-C Github snapshot repository (currently being deprecated in favor of the Gitlab repository, which is updated daily);
Or trying some interactive opam-related support in the IRC #frama-c channel on freenode.net (interactive support is often more efficient for installation issues related to opam, especially since it's hard to know in advance which information might be useful).
Dealing with "Invalid user input" errors in the GUI
As a general rule, when trying to open a file in the GUI fails, I'd recommend running the command-line version of Frama-C with the filename. Its output is much more detailed and can indicate if there are parsing issues with the file (which could be due to missing dependencies, non-C99 syntax, or configuration problems).
Otherwise, the Console tab in the GUI should contain detailed error messages, which you could then add to this SO question, in case they are relevant to understand your issue.
Issues with graphical libraries in non-major Linux distributions
The second issue I can see in your question, is the error related to -lgtksourceview-2.0. This means that one of the library dependencies for the graphical interface is missing. Maybe there's a way to fix it, but at the very least it should be possible to identify the error before compilation, and report the incompatibility earlier. The fact that depext did not work is unusual; maybe it's not currently well-supported for Manjaro, but it's worth investigating. Unfortunately, opam can sometimes be complex to handle for first-time users, so I understand it's a bit frustrating and may take more time than you'd want. But if you intend to use Frama-C or other OCaml packages for some reasonable amount of time, it is worth understanding some of the common errors in opam, since it is very useful for handling dependencies.
Handling issues with OCaml dependencies when compiling manually
Finally, the issue with Yojson is probably due to the version of the package that is installed. In particular, versions before 1.6.0 do not have the type Yojson.Basic.t. Frama-C used to support 1.4.1, but the latest version requires at least 1.6.0. Again, it's not obvious to spot in advance all possible issues with different package versions, but reporting them allows us to include checks to prevent it in the future, or at least to give a more precise error message.
Normally opam handles that part, hence why it's recommended even for manual compilation of Frama-C, since it helps manage its dependencies.
Overall, it seems that some underlying issue with the dependencies in opam depext is preventing the whole chain from working properly. Your report does contain much useful information but not all the details, so I believe the interactive route should allow to quickly converge towards a working installation.
I am struggling with running go in the fish shell.
A) I followed the installation procedure and installed go as specified in the documentation
However, when I run go version, I am getting a fatal error:
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
When I initialize the git by git init, I receive another error:
error: pathspec 'version' did not match any file(s) known to git
I have the paths configured in my fish config as follows:
set -gx GOPATH /home/<user>/go
set -gx PATH $PATH /usr/local/bin/go $GOPATH/bin
where /usr/local/bin/go is an output of which go in both bash and fish
Running it like bash -c 'go version', however, works without any problems (even without the git directory).
B) Also tried gofish and dnf to install go, the same results
Any help is greatly appreciated!
Additional info:
Fish version: fish, version 3.0.2
Operating system: Linux t460s 5.0.13-300.fc30.x86_64 x86_64 GNU/Linux
Could this be some kind of alias that is used instead? The error message is an error from the git binary.
Take a look in your file ~/.config/fish/config.fish and see if you find an alias there. If you do not find anything there look at the files in ~/.config/fish/ and subfolders.
I followed the guidance under the Training LeNet on MNIST with Caffe but I've got a error when creating lmdb..
$ ./examples/mnist/create_mnist.sh
Creating lmdb...
F:/program files/caffe/build/examples/mnist/convert_mnist_data.exe:
error while loading shared libraries: boost_python-vc140-mt-1_61.dll: cannot open shared object file: No such file or directory
I'm using GIT Bash for run the shell script,
so what is wrong?
It appears that the linker/loader does not have access to that Python BOOST library. Did you run the scripts needed to set your environment variables? I suspect that there's a missing path in your LD_LIBRARY_PATH.
As a stop-gap, you can locate the missing file with
find / -name boost_python-vc140-mt-1_61.dll
... and then manually add that path to LD_LIBRARY_PATH. The problem is that you'll hit thesefiles/caffe/build/examples/mnist/convert_mnist_data.exe one at a time until you get them all.
You can also try
ldd files/caffe/build/examples/mnist/convert_mnist_data.exe
... and see what you might be missing.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
[OSX 10.10.5, XCode 7.0.1]
I'm getting an error during my build stating that Otool can't copy a file:
error: otool: can't open file: /usr/local/opt/llvm/lib/libclang.3.6.dylib: (No such file or directory)
The two lines before the error (and what I think is causing it, because there are no other error indications) are:
cp -p /usr/local/opt/llvm/lib/libclang.3.6.dylib /Users/me/Library/Developer/Xcode/DerivedData/MiCASE-asvgjysohljplretlamgcpgnxgiq/Build/Products/Debug/MiCASE.app/Contents/Frameworks
cp -p /usr/local/opt/llvm/lib/libclang.3.6.dylib: /Users/me/Library/Developer/Xcode/DerivedData/MiCASE-asvgjysohljplretlamgcpgnxgiq/Build/Products/Debug/MiCASE.app/Contents/Frameworks
When I manually perform the command in a terminal, it works fine. I've set the permissions of the dynamic library to me:admin 777, so the file definitely exists. Thus I don't understand why I am getting the error.
This leads me to believe there is something else that is failing but the build log isn't showing it.
I'm also getting this error at the end of the script, but I think it's due to the above:
Command /bin/sh emitted errors but did not return a nonzero exit code to indicate failure
Solution
#trojanfoe, thanks for the info.
The problem was that as part of the build, a script was being run. In the script otool was being used to extract dependencies, and filtering of its output was done incorrectly. Fixing the filtering resolved the issue.