Context:
I am currently coding the generate-ninja-build.scm script in git commit cb7530e3ff10 of my GPLv3+ project bismon (funded by H2020 research projects). This is contractually some Linux free software project supposed to run on Debian.
That script should become an improvement over the existing shell script bismon/generate-ninja-builder.sh which generates some build.ninja file for the ninja tool (some build automation one).
Question:
The current generate-ninja-build.scm has just (outside of copyright notice comment) :
(use-modules
;; see https://www.gnu.org/software/guile/manual/html_node/Modules.html
(ice-9 posix) ;;;; problematic line, but why ?
(ice-9 readline)
(ice-9 format)
(ice-9 pretty-print)
)
;;;;;;;;;;;;;;;; constants
(define bm-packages '("glib-2.0" "jansson" "gtk+-3.0"))
(define bm-gcc "gcc")
but when I run it as ./generate-ninja-build.scm on my Debian/Sid, whose guile --version gives
guile (GNU Guile) 2.2.4
Packaged by Debian (2.2.4-deb+1-3)
I am getting:
rimski.x86_64 ~/bismon 8:17 .0 % ./generate-ninja-build.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/basile/bismon/./generate-ninja-build.scm
;;; WARNING: compilation of /home/basile/bismon/generate-ninja-build.scm failed:
;;; no code for module (ice-9 posix)
Backtrace:
9 (primitive-load "/home/basile/bismon/./generate-ninja-b…")
In ice-9/eval.scm:
721:20 8 (primitive-eval (use-modules (ice-9 posix) (ice-9 #) # …))
In ice-9/psyntax.scm:
1235:36 7 (expand-top-sequence ((use-modules (ice-9 posix) (…) …)) …)
1182:24 6 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
285:10 5 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) …)
In ice-9/boot-9.scm:
3377:20 4 (process-use-modules _)
222:17 3 (map1 (((ice-9 posix)) ((ice-9 readline)) ((ice-9 #)) #))
3378:31 2 (_ ((ice-9 posix)))
2803:6 1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ …)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu…" …) …)
ERROR: In procedure scm-error:
no code for module (ice-9 posix)
however the output of locate ice-9/posix includes:
/usr/lib/x86_64-linux-gnu/guile/2.0/ccache/ice-9/posix.go
/usr/lib/x86_64-linux-gnu/guile/2.2/ccache/ice-9/posix.go
/usr/share/guile/2.0/ice-9/posix.scm
/usr/share/guile/2.2/ice-9/posix.scm
So I was expecting the (ice-9 posix) line to work. If I comment that line, everything works as I want.
My ~/.guile just has:
;; file ~/.guile
(use-modules
(ice-9 readline)
(ice-9 format)
(ice-9 pretty-print))
(activate-readline)
and my interactive guile works like a charm with the expected fancy GNU readline and autocompletion interface.
What am I doing wrong?
sudo apt install guile-2.2-dev guile-2.0-dev guile-1.8-dev
Consider use Guix instead Debian. All develop dependencies is install by default in replace of Python. http://guix.gnu.org/
I couldn't find any mention of a (ice-9 posix) module in the guile 2.2 documentation, and while the appropriate file exists in the source tree, the modules/ice-9 directory README says
The non-module files are:
boot-9.scm -- loaded on guile startup
...
posix.scm -- loaded by boot-9.scm
You can't load it because it's not a module file intended to be loaded by user code. Same thing applies at least as far back as guile 1.8, so if you found some documentation or tutorial somewhere including an attempt to load a module by that name, it's simply wrong.
Related
I want to build https://github.com/wallix/redemption - and for the first time ever, I see bjam as a tool. This project has a tools/bjam/user-config.jam file.
The problem is, I'm trying to build this with a "custom" (that is, not the system version of) g++, which I have here:
$ which arm-linux-gnueabihf-g++-10
/home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10
$ arm-linux-gnueabihf-g++-10 --version | head -n1
arm-linux-gnueabihf-g++-10 (pi-raspberry) 10.1.0
$ /home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10 --v
ersion | head -n1
arm-linux-gnueabihf-g++-10 (pi-raspberry) 10.1.0
I guess, this qualifies at least as the compiler existing, right?
Anyways - I tried first, without knowing any better:
$ bjam --version
Boost.Build 2015.07-git
$ bjam toolset=arm-linux-gnueabihf-gcc-10 linkflags=-static-libstdc++ exe libs
arm.jam: No such file or directory
/usr/share/boost-build/src/build/toolset.jam:43: in toolset.using
ERROR: rule "arm.init" unknown in module "toolset".
/usr/share/boost-build/src/build-system.jam:461: in process-explicit-toolset-requests
/usr/share/boost-build/src/build-system.jam:527: in load
/usr/share/boost-build/src/kernel/modules.jam:295: in import
/usr/share/boost-build/src/kernel/bootstrap.jam:139: in boost-build
/usr/share/boost-build/boost-build.jam:8: in module scope
Then I found Building boost with different gcc version which mentions:
I cross built Boost for an ARM toolchain using something like this:
echo "using gcc : arm-unknown-linux-gnueabi : /usr/local/arm/bin/g++ ; " >> tools/build/v2/user-config.jam
Ok, so by that logic, I try:
echo "using gcc : arm-unknown-linux-gnueabi : /home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10 ; " >> tools/bjam/user-config.jam
... and then:
$ bjam toolset=gcc-arm-unknown-linux-gnueabi linkflags=-static-libstdc++ exe libs
/usr/share/boost-build/src/tools/gcc.jam:123: in gcc.init from module gcc
error: toolset gcc initialization:
error: version 'arm-unknown-linux-gnueabi' requested but 'g++-arm-unknown-linux-gnueabi' not found and version '6.3.0' of default 'g++' does not match
error: initialized from
/usr/share/boost-build/src/build/toolset.jam:43: in toolset.using from module toolset
/usr/share/boost-build/src/build-system.jam:461: in process-explicit-toolset-requests from module build-system
/usr/share/boost-build/src/build-system.jam:527: in load from module build-system
/usr/share/boost-build/src/kernel/modules.jam:295: in import from module modules
/usr/share/boost-build/src/kernel/bootstrap.jam:139: in boost-build from module
/usr/share/boost-build/boost-build.jam:8: in module scope from module
Well, I agree that "version '6.3.0' of default 'g++' does not match" -> but how on earth is "'g++-arm-unknown-linux-gnueabi' not found"? What is that absolute path /home/pi/opt/gcc-10.1.0/bin/arm-linux-gnueabihf-g++-10 doing in that entry in user-config.jam otherwise?
So - can I get a more verbose printout of what actually bjam does in finding my compiler? Or even better, how can I format my "custom gcc" entry in user-config.jam, so I can get bjam to compile whatever it has to, and I can happily forget that bjam exists?
EDIT: even the official documentation for successor to bjam states:
When using gcc, you first need to specify your cross compiler in user-config.jam (see the section called “Configuration”), for example:
using gcc : arm : arm-none-linux-gnueabi-g++ ;
After that, if the host and target os are the same, for example Linux, you can just request that this compiler version to be used:
b2 toolset=gcc-arm
Isn't that exactly what I'm doing? Why doesn't it work then?
Well, I found a bit of documentation in /usr/share/boost-build/src/tools/gcc.jam:
# Initializes the gcc toolset for the given version. If necessary, command may
# be used to specify where the compiler is located. The parameter 'options' is a
# space-delimited list of options, each one specified as
# <option-name>option-value. Valid option names are: cxxflags, linkflags and
# linker-type. Accepted linker-type values are aix, darwin, gnu, hpux, osf or
# sun and the default value will be selected based on the current OS.
# Example:
# using gcc : 3.4 : : <cxxflags>foo <linkflags>bar <linker-type>sun ;
Ok, so here I have a string, delimited with colon, the seconf field says "3.4", the third field is empty - so WHERE does the "command may be used to specify where the compiler is located" go - in second or third field?
Well, I managed to get it running, quite hacky - I added these statements to /usr/share/boost-build/src/tools/gcc.jam:
...
rule init ( version ? : command * : options * )
{
#1): use user-provided command
local tool-command = ;
ECHO notice: 1) user-provided command '$(command)' version '$(version)' options '$(options)' ;
if $(version) = "arm"
{
command = arm-linux-gnueabihf-g++-10 ;
}
if $(command)
{
tool-command = [ common.get-invocation-command-nodefault gcc : g++ :
$(command) ] ;
ECHO notice: tool-command 1) user-provided '$(command)' '$(tool-command)' ;
...
The printouts were like:
notice: 1) user-provided command version 'arm' options
notice: tool-command 1) user-provided 'arm-linux-gnueabihf-g++-10' 'arm-linux-gnueabihf-g++-10'
...
... both 'command' and 'options' there are empty - as if the line I added to user-config.jam does not get parsed beyond the two first fields.
So, since the second field ("arm") does get parsed, I simply added a conditional on it, and forced the use of the command - and now that passes.
Well, I wish bjam just worked, and I did not have to go through this ...
I know this has been installed before becuase the proverbot9001 project has used it before. So how do I go about finding what exactly is the issue in my set up that doesn't let me install it? Any install is fine I suppose
(iit_synthesis) brando9~/proverbot9001 $ opam install -y coq-ext-lib
The following actions will be performed:
∗ install coq-ext-lib dev
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
⬇ retrieved coq-ext-lib.dev (git+https://github.com/coq-community/coq-ext-lib#master)
[ERROR] The compilation of coq-ext-lib.dev failed at "make -j127 theories".
#=== ERROR while compiling coq-ext-lib.dev ====================================#
# context 2.1.3 | linux/x86_64 | ocaml-base-compiler.4.07.1 | https://coq.inria.fr/opam/extra-dev#2022-12-06 09:40
# path ~/.opam/coq-8.10/.opam-switch/build/coq-ext-lib.dev
# command /usr/bin/make -j127 theories
# exit-code 2
# env-file ~/.opam/log/coq-ext-lib-1328047-92e9b2.env
# output-file ~/.opam/log/coq-ext-lib-1328047-92e9b2.out
### output ###
# [...]
# make[2]: *** [Makefile.coq:658: theories/Tactics/BoolTac.vo] Error 1
# make[2]: *** Waiting for unfinished jobs....
# File "./theories/Programming/With.v", line 59, characters 0-39:
# Warning: Declaring a scope implicitly is deprecated; use in advance an
# explicit "Declare Scope struct_scope.". [undeclared-scope,deprecated]
# File "./theories/Data/ListFirstnSkipn.v", line 51, characters 0-101:
# Error: This command does not support this attribute: global.
#
# make[2]: *** [Makefile.coq:658: theories/Data/ListFirstnSkipn.vo] Error 1
# make[1]: *** [Makefile.coq:321: all] Error 2
# make[1]: Leaving directory '/lfs/ampere4/0/brando9/.opam/coq-8.10/.opam-switch/build/coq-ext-lib.dev'
# make: *** [Makefile:7: theories] Error 2
<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
┌─ The following actions failed
│ λ build coq-ext-lib dev
└─
╶─ No changes have been performed
my set up:
(iit_synthesis) brando9~/proverbot9001 $ opam switch
# switch compiler description
→ coq-8.10 ocaml-base-compiler.4.07.1 coq-8.10
coq-8.12 ocaml-base-compiler.4.07.1 coq-8.12
coq-8.14 ocaml-base-compiler.4.07.1 coq-8.14
ocaml-variants.4.07.1+flambda_coq-serapi.8.11.0+0.11.1 ocaml-variants.4.07.1+flambda ocaml-variants.4.07.1+flambda_coq-serapi.8.11.0+0.11.1
[NOTE] Current switch is set locally through the OPAMSWITCH variable.
The current global system switch is coq-8.14.
(iit_synthesis) brando9~/proverbot9001 $ opam list
# Packages matching: installed
# Name # Installed # Synopsis
base v0.14.0 Full standard library replacement for OCaml
base-bigarray base
base-threads base
base-unix base
cmdliner 1.0.4 Declarative definition of command line interfaces for OCaml
conf-findutils 1 Virtual package relying on findutils
coq 8.10.2 pinned to version 8.10.2
coq-fcsl-pcm 1.2.0 Partial Commutative Monoids
coq-inf-seq-ext dev Coq library for reasoning inductively and coinductively on infinite sequences
coq-int-map 8.10.0 Maps indexed by binary integers : IntMap
coq-mathcomp-algebra 1.11.0 Mathematical Components Library on Algebra
coq-mathcomp-bigenough dev A small library to do epsilon - N reasonning
coq-mathcomp-fingroup 1.11.0 Mathematical Components Library on finite groups
coq-mathcomp-ssreflect 1.11.0 Small Scale Reflection
coq-pocklington dev Pocklington's criterion for primality in Coq
coq-serapi 8.10.0+0.7.2 Serialization library and protocol for machine interaction with the Coq proof assistant
coq-smpl 8.10.2 Smpl: An Extensible Tactic for Coq
coq-struct-tact dev Coq library of structural tactics and utility lemmas about lists and finite types
cppo 1.6.9 Code preprocessor like cpp for OCaml
csexp 1.5.1 Parsing and printing of S-expressions in Canonical form
dune 3.6.1 Fast, portable, and opinionated build system
dune-configurator 3.6.1 Helper library for gathering system configuration
num 1.4 The legacy Num library for arbitrary-precision integer and rational arithmetic
ocaml 4.07.1 The OCaml compiler (virtual package)
ocaml-base-compiler 4.07.1 Official release 4.07.1
ocaml-compiler-libs v0.12.4 OCaml compiler libraries repackaged
ocaml-config 1 OCaml Switch Configuration
ocaml-secondary-compiler 4.08.1-1 OCaml 4.08.1 Secondary Switch Compiler
ocamlfind 1.9.1 A library manager for OCaml
ocamlfind-secondary 1.9.1 Adds support for ocaml-secondary-compiler to ocamlfind
parsexp v0.14.2 S-expression parsing library
ppx_derivers 1.2.1 Shared [##deriving] plugin registry
ppx_deriving 5.2.1 Type-driven code generation for OCaml
ppx_deriving_yojson 3.6.1 JSON codec generator for OCaml
ppx_import 1.9.1 A syntax extension for importing declarations from interface files
ppx_sexp_conv v0.14.3 [##deriving] plugin to generate S-expression conversion functions
ppxlib 0.25.1 Standard library for ppx rewriters
result 1.5 Compatibility Result module
seq base Compatibility package for OCaml's standard iterator type starting from 4.07.
sexplib v0.14.0 Library for serializing OCaml values to and from S-expressions
sexplib0 v0.14.0 Library containing the definition of S-expressions and some base converters
stdlib-shims 0.3.0 Backport some of the new stdlib features to older compiler
yojson 2.0.2 Yojson is an optimized parsing and printing library for the JSON format
related:
https://github.com/coq-community/coq-ext-lib/issues/131
https://github.com/UCSD-PL/proverbot9001/issues/56
coq-ext-lib dev uses the current main branch on github as source for the code. If you go and look there, you will see that the opam file states explicitely that the version of coq for which the sources work go from 8.8 to any 8.9, and then to any version above 8.11. This means that the version 8.10 is explictely ruled out.
Either you have to choose to work with a version of coq that is not 8.10, or you have to choose to work with a numbered version of coq-ext-lib that is compatible with coq-8.10. I suggest coq-ext-lib.0.11.6 (looking at the opam file this is one is compatible) because the latest one coq-ext-lib.0.11.7 is not (again you can look at the opam file).
In running an example from the guile handbook I stumbled upon an error while running foreign-library-function. It fails and prints a backtrace stating dlopen failed, because of an invalid elf format of the library. But the library is both present and working in other contexts.
The details to reproduce the issue:
test.scm (taken straight from the manual at https://www.gnu.org/software/guile/manual/guile.html#Foreign-Functions)
(define-module (math bessel)
#:use-module (system foreign)
#:use-module (system foreign-library)
#:export (j0))
(define j0)
(foreign-library-function "libm" "j0"
#:return-type double
#:arg-types (list double))
If I execute guile -s test.scm I get the following output:
;;; note: source file /home/max/projects/guile-tests/test.scm
;;; newer than compiled /home/max/.cache/guile/ccache/3.0-LE-8-4.5/home/max/projects/guile-tests/test.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/max/projects/guile-tests/test.scm
;;; compiled /home/max/.cache/guile/ccache/3.0-LE-8-4.5/home/max/projects/guile-tests/test.scm.go
Backtrace:
In ice-9/boot-9.scm:
1752:10 8 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
7 (apply-smob/0 #<thunk 7f57b930ef60>)
In ice-9/boot-9.scm:
724:2 6 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
619:8 5 (_ #(#(#<directory (guile-user) 7f57b9307c80>)))
In ice-9/boot-9.scm:
2835:4 4 (save-module-excursion _)
4380:12 3 (_)
In system/foreign-library.scm:
240:6 2 (foreign-library-function "libm" "j0" #:return-type _ # …)
190:25 1 (load-foreign-library _ #:extensions _ # _ #:search-path …)
In unknown file:
0 (dlopen "/usr/lib64/libm.so" 1)
ERROR: In procedure dlopen:
In procedure dlopen: file "/usr/lib64/libm.so", message "/usr/lib64/libm.so: Ungültiger ELF-Header"
To ensure the file in question is actually there here's the output of ls -la /usr/lib64/libm.so:
-rw-r--r-- 1 root root 110 20. Jun 19:52 /usr/lib64/libm.so
The problem also occured for all other libraries I tried to adapt the snippet to.
My current system is running on
openSUSE Tumbleweed 20210723
with Linux kernel 5.22.3
I installed the guile-package using zypper in guile from the official repositories. (currently version 3.0.7)
I heavily suspect that openSUSEs compilation/linking settings could be at fault here, but can neither confirm nor invalidate that theory. - It would be ideal to both know why the issue occurs as well as knowing a workaround.
dlopen: file "/usr/lib64/libm.so"
I don't know anything about Guile, but the problem appears to be that it is trying to dlopen libm.so.
On Linux with GLIBC, libm.so is a linker script, not an ELF file. The real ELF library (and the library guile should be dlopening) is libm.so.6.
You can see that your libm.so (at 110 bytes) is way too small to be an ELF file. If you run file -L /usr/lib64/libm.so*, you should see something like this:
/usr/lib64/libm.so: ASCII text
/usr/lib64/libm.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=07ae52cfc7f4eda1d13383c04564e3236e059993, for GNU/Linux 3.2.0, stripped
Possibly you need to fix system/foreign-library.scm so it dlopens correct library.
The solution to the problem was that libm.so is a linker script, just like the other answer says.
The problem is resolved, if instead of "libm" one passes "libm.so.6" to the function.
The following is the corrected, working snippet.
(define-module (math bessel)
#:use-module (system foreign)
#:use-module (system foreign-library)
#:export (j0))
(define j0)
(foreign-library-function "libm.so.6" "j0"
#:return-type double
#:arg-types (list double))
I'm trying to build my project and I'm running into a really strange problem. I got my friend to install Haskell with Chocolatey and when he goes to compile my project with cabal build and cabal run project he runs into the following error that I just don't have:
Expr.hs:103:1: error:
Type applications in patterns are not yet supported
|
103 | evalVal env val #(HInteger _) = return $ val
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I assumed that the cabal file would take care of dependencies but obviously not. A cursory search as well proves fruitless because I can't even find another instance of someone having the same error.
I'm not sure if the problem is due to him being on ghc 9.0.1 and cabal 3.4 and I'm on ghc 8.8.3 and cabal 3.2 or if it's due to different operating systems, his being Windows and I OSX.
My worry is that if I upgrade my ghc and cabal versions then I will run into this error and I'll have to reinstall everything which was messy and difficult the first time
It turns out that was a change in GHC 9.0: Whitespace-sensitive !, ~, #, and $
it's the second point there:
f # x = y
Before: value binding that binds both f and x to y using an as-pattern
After: infix function named (#)
To restore the old behavior, remove the leading and trailing whitespace around #, like so:
f#x = x
So if you change it to
evalVal env val#(HInteger _) = return $ val
it should work for both compilers
Recently I decided to retry building a CLFS machine http://www.clfs.org and am at step 5.5 of 3.0.0 SYSTEMD. We are told to run make -C include and then make -C progs tic. I am failing at the last command. Am I missing any packages, or am I doing something wrong?
I am using ArchLinux as my CLFS host in VMWare which is running on Windows 10.
Here is the page I am looking at for the commands: http://clfs.org/files/BOOK/3.0.0/SYSTEMD/view/x86_64/cross-tools/ncurses.html
Here is the output from the console when I run that last command:
In file included from ../ncurses/curses.priv.h:283:0,
from ../ncurses/lib_gen.c:19:_33528.c:835:15: error: expected ')' before 'int'
../include/curses.h:1594:56: note: in definition of macro 'mouse_trafo'
#define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen)
^
The error message is pointing to the y symbol,
which could be (mis)defined in some header file on your system.
aside from stray #define's, the only interesting thing about the line is that the prototype for wmouse_trafo uses bool, which the configure script should have (given the compiler version used for CLFS) equated to a c99 _Bool (which should not be a problem).
You can see what the compiler sees by doing
make -C ncurses lib_gen.i
and looking for wmouse_trafo in ncurses/lib_gen.i.
For example, I see it mentioned twice:
extern _Bool wmouse_trafo (const WINDOW*, int*, int*, _Bool);
extern _Bool mouse_trafo (int*, int*, _Bool);
and
_Bool (mouse_trafo) (int * a1, int * a2, _Bool z)
{
; return wmouse_trafo(stdscr,a1,a2,z);
}
The stray semicolon is not a problem, but if there were some problem with the cross-compiler it might make the _Bool missing.
The instructions for CLFS 3.0 use gcc 4.8.3 (versions of all of the parts do matter). However, the error message cited here looks like a recent report due to gcc 5 — which is addressed in ncurses 6.0