Hopefully this will be a simple question to answer: I am trying to add a package to buildroot that requires the kernel BPF syscall feature to be enabled.
If the feature is enabled, everything works fine, if not, the build fails with a marginally unhelpful error. What i would like to do is perform a quick check in the .mk file to see if the feature is present and print out a slightly more user-friendly error if it is not.
I tried adding:
ifneq ($(CONFIG_BPF_SYSCALL),y)
$(error Kernel feature CONFIG_BPF_SYSCALL is required)
endif
But this always seems to trigger as i assume CONFIG_BPF_SYSCALL does not exist in the package build scope. Is there a simple way to access to the kernel config list from a package build env?
Many thanks
It works the other way around: it is the "linux" package in Buildroot that ensures it enables the right options when a given package is enabled and requires some specific kernel features. See linux/linux.mk, which contains things like that:
$(if $(BR2_PACKAGE_KTAP),
$(call KCONFIG_ENABLE_OPT,CONFIG_DEBUG_FS,$(#D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_ENABLE_DEFAULT_TRACERS,$(#D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS,$(#D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_FUNCTION_TRACER,$(#D)/.config))
This ensures that CONFIG_DEBUG_FS, CONFIG_ENABLE_DEFAULT_TRACERS, CONFIG_PERF_EVENTS and CONFIG_FUNCTION_TRACER are enabled in the kernel configuration when the ktap Buildroot is enabled.
Note that this mechanism may be changed in the near future in Buildroot, see the patch series at http://patchwork.ozlabs.org/project/buildroot/list/?series=168565.
Related
I've downloaded the binaries: or-tools_VisualStudio2022-64bit_v9.3.10497
I'm using vs2022 on win10. My shell has cygwin in the path if it's related.
I ran
%comspec% /k "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
cl.exe is in the path, and which.exe finds it.
I ran make test_cc, but it complained
the cl command was not found in your PATH
exit 127
make: *** [Makefile:271: test_cc] Error 127
The var CXX_BIN was empty even though which cl returned the correct path. I set it manually to cl.
Then, there was a complaint about echo and a newline, which I commented out. Then, it couldn't find md, so I created manually md objs.
A few of the examples were built, but then it stopped with another error. For now, I just got what I want:
make run SOURCE=examples/cpp/solve.cc
but probably there was an easier way to get it?
I tried to build it from the source using cmake. Doesn't work off-the-shelf as well:
Build abseil-cpp: OFF
...
CMake Error at C:/prj-external-libs/vcpkg/scripts/buildsystems/vcpkg.cmake:824 (_find_package):
By not providing "Findabsl.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "absl", but
CMake did not find one.
Could not find a package configuration file provided by "absl" with any of
the following names:
abslConfig.cmake
absl-config.cmake
Add the installation prefix of "absl" to CMAKE_PREFIX_PATH or set
"absl_DIR" to a directory containing one of the above files. If "absl"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
cmake/deps.cmake:33 (find_package)
CMakeLists.txt:304 (include)
If finds gurobi95.dll, but it can't find the function GRBtunemodeladv.
On failure, solve.exe crashes with (unknown) names in the stack trace. Need to add debug symbols and graceful error handling.
cmake looks more promising, and I was missing dependencies. Should give it a flag -DBUILD_DEPS:BOOL=ON.
OR-Tools depends on few external dependencies so CMake build will try to find them using the idiomatic find_package() => your distro/env(vcpkg ?) must provide them, just regular CMake stuff here.
ref: https://cmake.org/cmake/help/latest/command/find_package.html
note: we provide few findFoo.cmake here https://github.com/google/or-tools/tree/main/cmake
We also provide a meta option to build statically all our dependencies, simply pass -DBUILD_DEPS=ON cmake option at configure time.
You can also build only some of them, please take a look at
https://github.com/google/or-tools/tree/main/cmake#dependencies
Concerning Gurobi and GRBtunemodeladv symbol, this one has been removed by last version of Gurobi so we fix it in v9.4/main/stable branch...
see: https://github.com/google/or-tools/commit/d6e0feb8ae96368523deb99fe4318d32e80e8145
I understand what I believe is the essence of the official utilties doc https://coq.inria.fr/refman/practical-tools/utilities.html#building-a-coq-project:
one creates a _CoqProject with arguments to coqc and the file names to compile (hopefully in an order that takes into account dependencies)
then one make an automatic CoqMakefile with coq_makefile -f _CoqProject -o CoqMakefile
Then you use their recommended Makefile to run the automatically generated make file.
But then if we need other dependencies, it doesn't say how to install them (or uninstall) them. What is the standard way to do that?
My guess is that one likely adds a target to your Makefile at the end of it and do some sort of opam install?
e.g.
# KNOWNTARGETS will not be passed along to CoqMakefile
KNOWNTARGETS := CoqMakefile
# KNOWNFILES will not get implicit targets from the final rule, and so
# depending on them won't invoke the submake. TODO: Not sure what this means
# Warning: These files get declared as PHONY, so any targets depending
# on them always get rebuilt -- or better said, any rules which those names will have their cmds be re-ran (which is
# usually rebuilding functions since that is what make files are for)
KNOWNFILES := Makefile _CoqProject
# Runs invoke-coqmakefile rule if you do run make by itself. Sets the default goal to be used if no targets were specified on the command line.
.DEFAULT_GOAL := invoke-coqmakefile
# Depends on two files to run this, itself and our _CoqProject
CoqMakefile: Makefile _CoqProject
$(COQBIN)coq_makefile -f _CoqProject -o CoqMakefile
# Note make knows what is the make file in this case thanks to -f CoqMakefile
invoke-coqmakefile: CoqMakefile install_external_dependencies
$(MAKE) --no-print-directory -f CoqMakefile $(filter-out $(KNOWNTARGETS),$(MAKECMDGOALS))
#
.PHONY: invoke-coqmakefile $(KNOWNFILES)
####################################################################
## Your targets here ##
####################################################################
# This should be the last rule, to handle any targets not declared above
%: invoke-coqmakefile
#true
# I know this is not a good coq dependency example but just to make it concrete wrote some opam command
install_external_dependencies:
opam install coq-serapi
I think I wrote the install_external_dependencies in the right place but I'm not sure. Is that correct? Anyone has a real example?
For all the code see: https://github.com/brando90/ultimate-utils/tree/master/tutorials_for_myself/my_makefile_playground/beginner_coq_project_with_makefiles/debug_proj
related: question on official tutorial for building coq projects https://coq.discourse.group/t/official-place-to-learn-how-to-setup-coq-make-files-for-beginner/1682
Btw,
I don't understand the last like in the makefile yet.
# This should be the last rule, to handle any targets not declared above
%: invoke-coqmakefile
#true
i.e.
%true in the make file template coq gave us.
% in the name of the rule.
What does that line do?
Update
I'm seeking an end-to-end small demo of how to install all dependencies with whatever the recommended approach when using _CoqProject and coq_makefile as shown in the utilities doc https://coq.inria.fr/refman/practical-tools/utilities.html. The ideal answer would contain a single script to install and compile everything in one go -- say in a install_project_name.sh. Including opam switches etc.
Related:
How does one install a new version of Coq when it cannot find the repositories in a new Mac M1 machine?
Installing packages for Coq using OPAM
https://coq.discourse.group/t/official-place-to-learn-how-to-setup-coq-make-files-for-beginner/1682
The simplest setup is to install external dependencies manually with opam.
opam install packages-needed-by-my-project
Then they will be immediately available to build your own project.
The next level of organization is to package up your project. Refer to the following Coq community resources:
Coq community templates
Recommended Project Structure
The main thing immediately relevant to your question is to have a *.opam file at the root of your project which lists its dependencies (possibly with version requirements). Then you can install them using opam install . --deps-only.
The Makefile part of your question is about a bit of overengineering for passing options seamlessly to CoqMakefile. I'm not sure how it works off-hand, but it's not important anyway, especially because Dune is superseding make as the recommended build system for Coq project.
I would like to make a rpm which can install on RHEL5,6 and 7.
[p4474668#rhel7dev source]$ cpanspec webmin-ajax-0.00.tar.gz -d '' --force --filter-requires 'perl(:MODULE_COMPAT_5.16.3)' -b
(... lots of infos here ...)
[p4474668#rhel7dev source]$ rpm -qpR noarch/perl-webmin-ajax-0.00-1.noarch.rpm
perl(:MODULE_COMPAT_5.16.3)
perl(DST::System)
perl(WebminCore)
perl(lib)
perl(strict)
perl(warnings)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1useless
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
Since the dependancy is not removed, it cannot be installed on a RHEL5.
How to remove the perl(:MODULE_COMPAT_5.16.3) not required dependency?
This feature is under-documented, and doesn't (IMHO) do all of what its name implies.
What it does is:
along with the .spec file it creates a filter script file (some sed in a .sh script), this is referenced in the .spec file and is required during rpmbuild. The dependencies written to the .spec file are not affected by filtering.
that sed filter script is rewritten by sed during rpmbuild to invoke the correct perl.req.
the filter script is applied only to the output of perl.req (which is normally only invoked by find-requires)
(As far as I can tell, perl.req predates explicitly listed dependencies in Makefile.PL and/or the META files. What it does is look for likely use and require directives in perl code with some logic and regex's, the implementation of which is exactly as attractive as you'd expect).
To be honest I'm not entirely sure in what circumstances perl.req and find-requires are or are not invoked (cursory testing by setting AutoReq didn't have an effect for me), but cpanspec reads and processes META.yml directly if found in any case. The only other dependency-related functionality is (rudimentary) processing of Makefile.PL to extract modules references in PREREQ_PM and add those as BuildRequires
Normally you can patch up your .spec file to add something like
%filter_from_requires /XSLoader/d
%filter_setup
However, :MODULE_COMPAT_xxx is a special-case dependency in cpanspec, you can turn it off with the -o option to create "compatible" RPMs that work on older systems. This has other effects too, so it might be less problematic to build in discrete steps so that you can tweak the build:
cpanspec [...] yourmodule
sed -i'.bak' '/^Requires.*:MODULE_COMPAT.*/d' yourmodule.spec
rpmbuild -ba yourmodule.spec
(especially since cpanspec warns that -b is not guaranteed to work always).
Of course the final package may not work as expected, cpanspec is being cautious, but there might be a real API requirement for this constraint (in your case the "noarch" build may limit the scope for problems, I think). The rule of thumb is that API/ABI's try to be backward compatible, not forward compatible (a related problem occurs if you try to build binaries to work with a glibc older than the one you compile against).
You may have better luck building on a CentOS 5 system (or investigate Mock for a more complete solution).
First I have installed all the dependent packages including atk 2.18.
Then, I have added them to path.
# echo $LD_LIBRARY_PATH
/opt/gtk_+3.12-RHEL6/dependencies/at-spi2-atk/lib:/opt/gtk_+3.12-RHEL6/dependencies/gobject-introspection/lib:/opt/gtk_+3.12-RHEL6/dependencies/pango/lib:/opt/gtk_+3.12-RHEL6/dependencies/harfbuzz/lib:/opt/gtk_+3.12-RHEL6/dependencies/freetype/lib:/opt/gtk_+3.12-RHEL6/dependencies/icu4c/lib:/opt/gtk_+3.12-RHEL6/dependencies/cairo/lib:/opt/gtk_+3.12-RHEL6/dependencies/fontconfig/lib:/opt/gtk_+3.12-RHEL6/dependencies/libpng/lib:/opt/gtk_+3.12-RHEL6/dependencies/pixman/lib:/opt/gtk_+3.12-RHEL6/dependencies/atk/lib:/opt/gtk_+3.12-RHEL6/dependencies/gdk-pixbuf/lib:/opt/gtk_+3.12-RHEL6/dependencies/GLib/lib:
# echo $PATH
/opt/gtk_+3.12-RHEL6/dependencies/gobject-introspection/bin:/opt/gtk_+3.12-RHEL6/dependencies/pango/bin:/opt/gtk_+3.12-RHEL6/dependencies/harfbuzz/bin:/opt/gtk_+3.12-RHEL6/dependencies/freetype/bin:/opt/gtk_+3.12-RHEL6/dependencies/which/bin:/opt/gtk_+3.12-RHEL6/dependencies/icu4c/sbin:/opt/gtk_+3.12-RHEL6/dependencies/icu4c/bin:/opt/gtk_+3.12-RHEL6/dependencies/cairo/bin:/opt/gtk_+3.12-RHEL6/dependencies/fontconfig/bin:/opt/gtk_+3.12-RHEL6/dependencies/libpng/bin:/opt/gtk_+3.12-RHEL6/dependencies/gdk-pixbuf/bin:/opt/gtk_+3.12-RHEL6/dependencies/GLib/bin:/opt/python_2_7_11/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
# echo $PKG_CONFIG_PATH
/opt/gtk_+3.12-RHEL6/dependencies/at-spi2-atk/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/gobject-introspection/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/pango/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/harfbuzz/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/freetype/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/icu4c/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/cairo/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/fontconfig/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/libpng/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/pixman/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/atk/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/gdk-pixbuf/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies/GLib/lib/pkgconfig:/opt/gtk_+3.12-RHEL6/dependencies
But, when I try to run ./configure, I am getting the following error:
checking for ATK... no
configure: error: Package requirements (atk atk-bridge-2.0) were not met:
No package 'atk-bridge-2.0' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables ATK_CFLAGS
and ATK_LIBS to avoid the need to call pkg-config.
atk 2.18 is cleary added in the PKG_CONFIG_PATH and also LD_LIBRARY_PATH.
So, I though atk-bridge-2.0 is separate and found the packag: at-spi2-atk and at-spi2-core. But, no atk-bridge-2.0 is installed.
Please help.
The atk-bridge-2.0 API is provided by at-spi2-atk, not by ATK.
Your build environment is fairly broken, and it seems you're installing each component into its own prefix. You shouldn't. Create a temporary build root, and add that to $PATH, $PKG_CONFIG_PATH, $LD_LIBRARY_PATH, and $XDG_DATA_DIRS. Then, use the same prefix for every component.
You should look at how jhbuild works.
I have a Coq project with its libraries organised into subdirectories, something like:
…/MyProj/Auxiliary/Aux.v
…/MyProj/Main/Main.v (imports Auxiliary/Aux.v)
When I compile the files, I expect to do so from working directory MyProj (via a makefile). But I also want to work on the files using Proof General/Coqtop, in which case the working directory is by default the directory in which the file lives.
But this means that the LoadPath is different between the two contexts, and so the logical path needed for the library import is different. How do I set up the coqc invocation, the LoadPath, and the import declarations so that they work in both contexts?
Each approach I have tried, something goes wrong. For instance, if I compile Aux.v by invoking
coqc -R "." "MyProj" Auxiliary/Aux.v
and import it in Main.v as
Require Import MyProj.Auxiliary.Aux.
then this works when I compile Main.v with
coqc -R "." "MyProj" Main/Main.v
but fails in Coqtop, with Error: Cannot find library MyProj.Auxiliary.Aux in loadpath. On the other hand, if before the Require Import I add
Add LoadPath ".." as MyProj.
then this works in Coqtop, but fails under coqc -R "." "MyProj" Main/Main.v, with
Error: The file […]/MyProj/Auxiliary/Aux.vo contains library
MyProj.Auxiliary.Aux and not library MyProj.MyProj.Auxiliary.Aux
I’m looking for a solution that’s robust for a library that’s shared with collaborators (and hopefully eventually with users), so in particular it can’t use absolute file paths. The best I have found for now is to add emacs local variables to set the LoadPath up when Proof General invokes Coqtop:
((coq-mode . ((coq-prog-args . ("-R" ".." "MyProj" "-emacs")))))
but this (a) seems a little hacky, and (b) only works for Proof General, not in Coqide or plain Coqtop. Is there a better solution?
Allow me to side-step your question by suggesting an alternative process, hinted at by Tiago.
Assuming that your project's tree looks like this:
MyProj/Auxiliary/Aux.v
MyProj/Main/Main.v
In MyProj, write a _CoqProject file listing all your Coq files
-R . ProjectName
Auxiliary/Aux.v
Main/Main.v
When you open one of these Coq files, emacs will look for the _CoqProject and do-the-right-thing (tm).
As shown by Tiago, coq_makefile will also give you a Makefile for free.
I know you explicitly asked for something that works across different platforms, but there's already a Proof-General-specific solution that is less hacky than the one you have. Proof General has a special variable called coq-load-path that you can set with local variables, much like you did for coq-prog-args. The advantage is that you don't have to worry about any other arguments that need to be passed to coqtop (such as -emacs in your example). Thus, your .dir-locals.el file could have a line like this:
((coq-mode . ((coq-load-path . ((".." "MyProj"))))))
Unfortunately, I am not aware of anything that works across platforms, although I'm pretty sure that something specific for CoqIDE must exist. If this is the case, maybe you could set up a script to keep these configuration files updated across different platforms?
If you use coq_makefile you can install the library in your system.
Without OPAM
To initialize your project:
coq_makefile -f _CoqProject -o Makefile
Share your library with other projects:
make install
With OPAM
Assuming you have OPAM installed, you can use coq-shell to help you take care of dependencies.
To setup your project:
coq_shell_url="https://raw.githubusercontent.com/gares/opam-coq-shell/master/src/opam-coq"
curl -s "${coq_shell_url}" | bash /dev/stdin init 8.4 # Install Coq and its dependencies
eval `opam config env --switch=coq-shell-8.4` # Setup the environment
coq_makefile -f _CoqProject -o Makefile # Generates the makefile
opam pin add coq:YOURLIBRARY . # Add your library to OPAM
When you update your library you should do:
opam upgrade coq:YOURLIBRARY
Here is an example of a project that uses the OPAM method:
https://bitbucket.org/cogumbreiro/aniceto-coq/src