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.
Related
I have some older utilities that are only sometimes needed and it came time to use a particular one and I found it didn't work. I know that some of the other utilities in the same package were working, but rather than worry about why this one was unique, I figured it just needed a recompile on the most recent Fedora and so I ran make.
I then learned that it couldn't find cc1. So the first thing I did was: dnf update gcc
This upgraded some 11 packages but didn't cure the cc1 problem, so I did which gcc to find where that is, then made a soft link to the cc1 program in the same directory. The compile then proceeded until a / the final linking, which should be:
gcc -o run${BINTYPE} run.o hashc.o
'run' here is the utility name. But the compile returns:
gcc: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found
compilation terminated.
I then did a web search and found a few stack-overflow entries, such as this one, (and a handful of non-stack-overflow pages, too) but none matched or provided a working solution.
I then found where liblto_plugin.so actually is:
/usr/lib64/bfd-plugins/liblto_plugin.so
...and checked LD_LIBRARY_PATH - the location wasn't in there, so I added it as the first entry (/usr/lib64/bfd-plugins/). That didn't work - same error.
And, I also tried going to where this distribution of Fedora seems to want to find it - which is /usr/libexec/gcc/x86_64-redhat-linux/ - and then making a soft link there, too, but that didn't work either.
OK, this should be simple, but I'm stumped!
It might be worth noting that from what I understand, this plugin is about optimizing dynamic linking at runtime, and that's simply not involved for this utility. All this program does is validate an environment before running to ensure it doesn't even try to launch unless certain conditions are met, so static linking should work fine. So maybe a workaround is to simply provide a flag that says skip the plug-ins? I'd rather "fix it correctly," but I'll settle for it doing what I need to do right now.
UPDATE
As suggested by Knud Larsen in comments, I did a re-installation of gcc and nothing changed. And, it appears the ‘-fuse-linker-plugin’ isn't even rquired these days, Great! But, there's no flag calling for its use, so it seems to be automatic; how do I turn this thing off?!
I also meet this question when install something with cargo.
note: cc: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
compilation terminated.
Finally, I found the reason. I created the hard link cc of gcc by mistake. It should have been a soft link. It will be fine after changing it.
I'm cross-compiling ecasound, which goes well up to the point that all binaries get compiled, but fails during (at the end of?) the installation phase.
The thing is, I don't see any error message or anything, so I'm left guessing here:
ecasound: installs files in /home/buildroot/buildroot-2018.02-rc2/output/target//home/buildroot/buildroot-2018.02-rc2/output
make[1]: *** [/home/buildroot/buildroot-2018.02-rc2/output/build/ecasound-2.9.1/.stamp_target_installed] Error 1
make: *** [_all] Error 2
Full output: https://pastebin.com/ca6FJebB (hope this contains enough details)
Presumably the ecasound 'make install' returns (silently?) with an error. We don't have an ecasound package in upstream Buildroot, so it is hard to know what you are doing, but the install location (../output/target/home/buildroot/..) certainly looks wrong.
It did work after first doing a complete build, followed by ecasound seperately, indicating it was missing dependencies. Turned out the missing piece here was: BR2_PACKAGE_PYTHON_CURSES.
In case anyone wants to build ecasound for buildroot, a working package is available in my github account.. Not sure if it's clean code/by the book, but it works..
The problem is your install path somehow duplicated itself
/home/buildroot/.../target//home/buildroot/...
I have seen this several times too, and havent really found a way to fix it except to make clean & make again
I am trying to build a library with a different build system, but files in the library require a config.h header file that is generated after running the configure scripts generated by autoconf.
This is the sequence of steps I am following to try and generate the config.h file that is needed
autoreconf -ivf
./configure --disable-dependency-tracking
The build system guarantees that the library gflags will be linked and the headers will be available at preprocessing time. But the configure script exits with the following error
configure: error: Please install google-gflags library
Is there some way I can get the list of required libraries (such as gflags) and then pass arguments to the configure script that tells it to assume that this library exists on the system? I went through the help output for both autoreconf and ./configure and wasn't able to figure this out.
Sorry for the long explanation and problem. I am very new to autoconf, etc.
The answer to your question is: no, it is not possible to get a list of dependencies from autotools.
Why?
Well, autotools doesn't track dependencies at all.
Instead, it checks whether specific features are present on the system (e.g. a given header-file; or a given library file).
Now a specific header file can come from a variety of sources, e.g. depending on your distribution the foo.h header can be installed via
libfoo-dev (Debian and derivatives)
foo-devel (Fedora)
foo (upstream)
...
In your specific case, the maintainers of your project output a nice error message telling you to install a given package by name.
The maintainers of your project also chose to abort with a fatal error if a given dependency is not available.
The reason might well be, that the project simply won't work without that dependency, and that is impossible to compile the program without it.
Example
Your project might be written in C++ and thus require a C++-compiler.
Obviously there is little use in passing some flags to ./configure so it assumes that there is a C++-compiler available if in reality there is none.
There is hope
However, not all is bad.
Your configure script might will have the ability to disable certain features (that appear to be hard requirements by default).
Just check ./configure --help and look for flags like
--enable-FOO
--disable-FOO
--with-BAR
--without-BAR
automation?
One thing to know about autotools, is that configure really is a program (the source-code being configure.ac) written in some arcane programming language (involving bash and m4),
This means that it can practically have any behavior, and there is no single standard way to achieve "dependecy tracking".
What you're trying to do will not work as umläute already said. On the other hand, depending on the package you're trying to build, you may be able to tell ./configure that a given library is there even if it isn't.
For instance if the script uses pkg-config to check for the presence of a library, you can use FOO_CFLAGS and FOO_LIBS to override the presence checking and telling it "yes those packages are there, you just don't know how to find them", but these are very package-specific so you may have to provide more information if that's what you're looking for.
I am a beginning programmer trying to install the Python Protocol Buffers from this package: http://code.google.com/p/protobuf/downloads/detail?name=protobuf-2.4.1.zip
The readme states:
1) Make sure you have Python 2.4 or newer. If in doubt, run:
$ python -V
2) If you do not have setuptools installed, note that it will be
downloaded and installed automatically as soon as you run setup.py.
If you would rather install it manually, you may do so by following
the instructions on this page:
http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions
3) Build the C++ code, or install a binary distribution of protoc. If
you install a binary distribution, make sure that it is the same
version as this package. If in doubt, run:
$ protoc --version
4) Run the tests:
$ python setup.py test
If some tests fail, this library may not work correctly on your
system. Continue at your own risk.
Please note that there is a known problem with some versions of
Python on Cygwin which causes the tests to fail after printing the
error: "sem_init: Resource temporarily unavailable". This appears
to be a bug either in Cygwin or in Python:
http://www.cygwin.com/ml/cygwin/2005-07/msg01378.html
We do not know if or when it might me fixed. We also do not know
how likely it is that this bug will affect users in practice.
5) Install:
$ python setup.py install
This step may require superuser privileges.
NOTE: To use C++ implementation, you need to install C++ protobuf runtime
library of the same version and export the environment variable before this
step. See the "C++ Implementation" section below for more details.
I have added both python and version 2.4.1 of protoc.exe into my PATH. However, when I try to run the test, I get an error message that says there's invalid syntax on line 38:
print "Can't find required file " + source
Okay, so it's missing parenthesis. I add them, and it encounters two more print statement syntax error messages. I fix those, and it encounters a syntax error message on an 'except' statement. What am I doing wrong?
Thanks.
Perhaps you are using Python 3?
The code you refer to will only work in Python 2.X
I have followed same steps , but I didn't get any errors.
Please make sure that you are getting correct Python and protoc version.
Export the environment LD_LIBRARY_PATH variable.
I have some trouble getting this particular kernel patch to compile correctly with my Ubuntu Linux kernel.
The patch in question comes from a piece of software called SCST it a iSCSI target for Linux. The patch loads fine when I run patch -p1 < put_page_callback-2.6.32.patch but when I got to compile I get about an hour in or so and then make fails and returns these errors.
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:63: error: redefinition of '__kcrctab_net_get_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:14: note: previous definition of '__kcrctab_net_get_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:63: error: redefinition of '__kstrtab_net_get_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:14: note: previous definition of '__kstrtab_net_get_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:63: error: redefinition of '__ksymtab_net_get_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:14: note: previous definition of '__ksymtab_net_get_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:66: error: redefinition of '__kcrctab_net_put_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:17: note: previous definition of '__kcrctab_net_put_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:66: error: redefinition of '__kstrtab_net_put_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:17: note: previous definition of '__kstrtab_net_put_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:66: error: redefinition of '__ksymtab_net_put_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:17: note: previous definition of '__ksymtab_net_put_page_callback' was here
and I have absolutley no idea what is going on. I am not a kernel dev by any means, I am just trying to get this patch and another one which works fine scst_exec_req_fifo-2.6.32.patch. So I can make this iSCSI target run at full speed.
Any idea what I can do?
** UPDATE **
I am following the insructions from https://help.ubuntu.com/community/Kernel/Compile. More specificly a link on that page that goes to http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/.
I have already done a few compiles using these instructions, my problems were either I forgot to apply the patches or the patch did not take, but up until now they always completed. Something with this new patch messed something up.
As far as why the iSCSI target is messing with the network parts, it apperantly has something to do with the network performance. When I compile the target software without the patch it whines about the performance wont be good. The website for the target is http://scst.sourceforge.net/index.html
You should follow the standard kernel compilation method after getting yourself an appropriate kernel version from kernel.org
Here are the steps in order
Extract kernel to a folder
Apply patch
sudo make menuconfig, save default .config file
sudo make
sudo make modules_install
sudo make install
cd /boot
sudo mkinitramfs -o initrd.img-(your version here) (your version again)
sudo update-grub
You should now see the new kernel in your boot options and it should (hopefully) boot.