I have other problem, I have tried change Makefile for include Core.Std, I would like to use it, for the module List.
This is my MakeFile.
FRAMAC_SHARE :=$(shell frama-c-config -print-share-path)
FRAMAC_LIBDIR :=$(shell frama-c-config -print-libpath)
PLUGIN_ENABLE:=$(ENABLE_DTN_ANNOTATION)
PLUGIN_NAME:=Dtn
PLUGIN_DIR:=./
PLUGIN_CMO:= deps_neo
PLUGIN_REQUIRES = core
include $(FRAMAC_SHARE)/Makefile.dynamic
When I use "make" this is error:
ocamlfind: Error from package `threads': Missing -thread or -vmthread switch
In Real Open World Ocaml, it used:
ocamlfind ocamlc -linkpkg -thread -package core
How can I simulate it in frama-c?
Related
I need to compilet a go library via C to a DLL that can be used through PInvoke on ARM/ARM64 Windows. I find many open issues, topics and discussions about this and it sounds like it might partially work. But if I try it like this:
export CC="arm-none-eabi-gcc"
export CXX="arm-none-eabi-g++"
export GOOS="windows"
export GOARCH="arm"
export GOARM=7
export CGO_ENABLED="1"
go build -ldflags="-s -w" -o my_library.dll -buildmode c-shared
I get the result buildmode c-shares is not supported on windows/arm. So it seems to still be not supported.
Another problem is that I need to set CGO_ENABLED and route the compiling through a C/C++-Toolchain as I have to add a C-file generated by SWIG. I tried the above on Ubunu 20.04 with the toolchain of the package gcc-arm-none-eabi.
I'm no C/C++/Go-pro - but the same works for nearly all other platforms like Windows, Linux, Android, Mac and iOS. The latter also is based on ARM64, so I do not really understand why this is not possible - though I value the difficulties with all this.
So, if someone with more in-depth-knowledge can help me here that would be great.
Just to clarifiy: I do not want/need to compile Go itself for ARM/ARM64. I need to compile a Go-program for that platform (to use my library from .Net on e.g. the Surface or a Hololens).
Update from 04.08.2021:
Go 1.17rc2 should include windows arm64 now. And I got the hint to use Zig for cross-compiling. So I've changed my build pipeline to something like this (I'm using Azure Devops in a Ubuntu VM):
go get -v golang.org/dl/go1.17rc2
/home/vsts/go/bin/go1.17rc2 download
/home/vsts/go/bin/go1.17rc2 version
sudo snap install zig --classic --beta
zig version
export CC="zig cc -target aarch64-windows-gnu"
export CXX="zig c++ -target aarch64-windows-gnu"
export GOOS="windows"
export GOARCH="arm64"
export GOARM=7
export CGO_ENABLED="1"
/home/vsts/go/bin/go1.17rc2 build -ldflags="-s -w" -o storj_uplink.dll -buildmode c-shared -tags extended
I then get this error:
2021-08-03T19:24:52.0641737Z # runtime/cgo
2021-08-03T19:24:52.0642803Z info: Usage: zig [command] [options]
2021-08-03T19:24:52.0643335Z
2021-08-03T19:24:52.0643827Z Commands:
2021-08-03T19:24:52.0643940Z
2021-08-03T19:24:52.0644276Z build Build project from build.zig
2021-08-03T19:24:52.0645203Z init-exe Initialize a `zig build` application in the cwd
2021-08-03T19:24:52.0645768Z init-lib Initialize a `zig build` library in the cwd
2021-08-03T19:24:52.0645950Z
2021-08-03T19:24:52.0646407Z ast-check Look for simple compile errors in any set of files
2021-08-03T19:24:52.0646936Z build-exe Create executable from source or object files
2021-08-03T19:24:52.0647468Z build-lib Create library from source or object files
2021-08-03T19:24:52.0647994Z build-obj Create object from source or object files
2021-08-03T19:24:52.0648390Z fmt Reformat Zig source into canonical form
2021-08-03T19:24:52.0648753Z run Create executable and run immediately
2021-08-03T19:24:52.0649088Z test Create and run a test build
2021-08-03T19:24:52.0649551Z translate-c Convert C code to Zig code
2021-08-03T19:24:52.0649707Z
2021-08-03T19:24:52.0650109Z ar Use Zig as a drop-in archiver
2021-08-03T19:24:52.0650576Z cc Use Zig as a drop-in C compiler
2021-08-03T19:24:52.0651070Z c++ Use Zig as a drop-in C++ compiler
2021-08-03T19:24:52.0651549Z dlltool Use Zig as a drop-in dlltool.exe
2021-08-03T19:24:52.0652033Z lib Use Zig as a drop-in lib.exe
2021-08-03T19:24:52.0652495Z ranlib Use Zig as a drop-in ranlib
2021-08-03T19:24:52.0652670Z
2021-08-03T19:24:52.0652962Z env Print lib path, std path, cache directory, and version
2021-08-03T19:24:52.0653531Z help Print this help and exit
2021-08-03T19:24:52.0653879Z libc Display native libc paths file or validate one
2021-08-03T19:24:52.0654250Z targets List available compilation targets
2021-08-03T19:24:52.0654579Z version Print version number and exit
2021-08-03T19:24:52.0655062Z zen Print Zen of Zig and exit
2021-08-03T19:24:52.0655220Z
2021-08-03T19:24:52.0655445Z General Options:
2021-08-03T19:24:52.0655565Z
2021-08-03T19:24:52.0655982Z -h, --help Print command-specific usage
2021-08-03T19:24:52.0656154Z
2021-08-03T19:24:52.0656502Z error: unknown command: -E
2021-08-03T19:25:03.2047129Z # golang.org/x/sys/windows
2021-08-03T19:25:03.2048568Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/types_windows.go:1620:24: undefined: JOBOBJECT_BASIC_LIMIT_INFORMATION
2021-08-03T19:25:03.2049594Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/zsyscall_windows.go:3020:38: undefined: WSAData
2021-08-03T19:25:03.2050606Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/zsyscall_windows.go:3096:51: undefined: Servent
2021-08-03T19:25:03.2051572Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/zsyscall_windows.go:3110:50: undefined: Servent
2021-08-03T19:25:04.7947309Z ##[error]Bash exited with code '1'.
Basically "unknown command: -E" which is described here. But from my understanding this should work already. And furthermore this blog post does it directly with zig, too.
Second update from 04.08.2021
Go is now calling zig! The workaround using a bash-script is working. Now I get the following error:
2021-08-04T11:54:47.2530981Z # golang.org/x/sys/windows
2021-08-04T11:54:47.2532284Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/types_windows.go:1620:24: undefined: JOBOBJECT_BASIC_LIMIT_INFORMATION
2021-08-04T11:54:47.2533180Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/zsyscall_windows.go:3020:38: undefined: WSAData
2021-08-04T11:54:47.2534002Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/zsyscall_windows.go:3096:51: undefined: Servent
2021-08-04T11:54:47.2534797Z /home/vsts/go/pkg/mod/golang.org/x/sys#v0.0.0-20210112091331-59c308dcf3cc/windows/zsyscall_windows.go:3110:50: undefined: Servent
2021-08-04T11:54:57.4223210Z # runtime/cgo
2021-08-04T11:54:57.4224911Z /snap/zig/3678/lib/libc/mingw/secapi/vsprintf_s.c:39:10: warning: implicit declaration of function '__ms_vsnprintf' is invalid in C99 [-Wimplicit-function-declaration]
2021-08-04T11:54:57.4225714Z return __ms_vsnprintf (_DstBuf, _Size, _Format, _ArgList);
2021-08-04T11:54:57.4226223Z ^
2021-08-04T11:54:57.4226624Z 1 warning generated.
2021-08-04T11:54:57.4227534Z /snap/zig/3678/lib/libc/mingw/math/arm/s_trunc.c/snap/zig/3678/lib/libc/mingw/math/arm/s_truncf.c:24:10: fatal error: '../bsd_private_base.h' file not found
2021-08-04T11:54:57.4228188Z #include "../bsd_private_base.h"
2021-08-04T11:54:57.4228651Z ^~~~~~~~~~~~~~~~~~~~~~~
2021-08-04T11:54:57.4229332Z :26:10: fatal error: '../bsd_private_base.h' file not found
2021-08-04T11:54:57.4229850Z #include "../bsd_private_base.h"
2021-08-04T11:54:57.4230310Z ^~~~~~~~~~~~~~~~~~~~~~~
2021-08-04T11:54:57.4230966Z 1 error generated.
2021-08-04T11:54:57.4231397Z 1 error generated.
2021-08-04T11:54:57.4522549Z ##[error]Bash exited with code '1'.
Update from 05.08.2021:
I finally found a toolchain that at least does not throw an error. But now it quits silently without generating a DLL. Not sure what happens now, though. This is my call:
go get -v golang.org/dl/go1.17rc2
/home/vsts/go/bin/go1.17rc2 download
/home/vsts/go/bin/go1.17rc2 version
wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf.tar.xz
tar -xf gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf.tar.xz
cd gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf
cd bin
export PATH=$PATH:$(pwd)
cd ..
cd ..
cd uplink-c
export CC="arm-none-linux-gnueabihf-gcc -v"
export CXX="arm-none-linux-gnueabihf-g++ -v"
export GOOS="windows"
export GOARCH="arm64"
export GOARM=7
export CGO_ENABLED="1"
home/vsts/go/bin/go1.17rc2 build -ldflags="-s -w" -o storj_uplink.dll -buildmode c-shared -tags extended -v
I do not want/need to compile Go itself for ARM/ARM64. I need to compile a Go-program for that platform
That should work, using Go 1.17 beta
Its documentation do mention:
Windows
Go 1.17 adds support of 64-bit ARM architecture on Windows (the windows/arm64 port).
This port supports cgo.
The OP topperdel refers in the comments to CL 326310:
cmd/internal/sys: mark windows/arm64 as c-shared-capable
The platform supports c-shared now, so flip this on.
I've given this a small smoke test using WireGuard Tunnel Library, and it was able to pass packets and generally function well.
Since the WireGuard Tunnel Library uses quite a bit of Go functionality under the hood, I think it's a decent test that a lot of things that should be working are working. So this commit enables it.
In order to get all tests passing, we make a few small changes, such as
passing -Wno-dll-attribute-on-redeclaration to clang and avoiding
loading shared libraries into Powershell on arm.
As illustrated by those issues, this is this is still a work in progress:
issue 46502 ("runtime: several tests are failing on windows-arm64-aws builder due to redeclaration warnings (upgraded to errors in testing)"),
issue 46701 ("Powershell on arm64/arm cannot load arm64/arm binaries because it is an intel process")
The test part is now (June 13th, 2021) closed with golang/go commit 1ed0d12:
runtime: testprogcgo: don't call exported Go functions directly from Go
Instead route through a C function, to avoid declaration conflicts
between the declaration needed in the cgo comment and the declaration
generated by cgo in _cgo_export.h.
This is not something user code will ever do, so no need to make it
work in cgo.
I mentioned in the comments
From ziglang/zig issue 7342, zig should be supported now.
Example, with Go 1.17 : "Zig Makes Go Cross Compilation Just Work" from Loris Cro (VP of community #ziglang):
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 \
CC="zig cc -target x86_64-linux" \
CXX="zig c++ -target x86_64-linux" \
go build --tags extended
You would need to adapt the arch targets to your need
Note: a bash shell session is needed. So git bash on Windows, for instance.
I am trying to use the Z3 Solver on OSX using the OCaml binding.
When attempting to build and run my solution using
ocamlfind ocamlc -o testsat.byte -package Z3 -linkpkg testsat.ml I am getting an ocamlfind: Package Z3 not found.
I have also tried using ocamlbuild without the -package tag, however then I'm getting an Unbound Module Z3 error.
I am also having problems installing the z3Overlay library - https://github.com/termite-analyser/z3overlay when trying to install the z3 dev portion.
Does anyone know of any fixes, or a stable version that can be used on OSX? My assumptions are that I'm encountering these errors since the build is failing (as can be seen from the official documentation: https://github.com/Z3Prover/z3).
I am new to this, any help is greatly appreciated.
Library and package names are case sensitive, and the package name of the z3 bindings is z3 not Z3. You can always query for available packages using ocamlfind list.
ocamlfind list | grep -i Z3
z3 (version: 4.6.0.0)
So the following command will work as expected
ocamlfind ocamlc -o testsat.byte -package z3 -linkpkg testsat.ml
There is a small caveat, that Martin mentions in the comments, so you should get another error, that should look like this:
libz3.so: cannot open shared object file: No such file or directory
Indeed, the package installs libz3.soin a location that is not searched, thus you should tell the system linker where to search for the z3 shared object. In Mac OS X, this can be achieved by setting the DYLD_LIBRARY_PATH variable, e.g.,
export DYLD_LIBRARY_PATH=`opam config var z3:lib`
on GNU/Linux systems the same can be done via the LD_LIBRARY_PATH environment variable:
export LD_LIBRARY_PATH=`opam config var z3:lib`
I am learning more complex compilations in OCaml.
first I haven't been a C programmer and I really don't know what is make, etc. I am using Mac OS X terminal and i am also a Java programmer.
I find that in OCaml, there some things like ocamlc, ocamlbuild, ocamlfind, oasis, etc. I got very confused by them.
Question 1
Can anyone tell me which one I should use among ocamlc, ocamlbuild, ocamlfind, oasis?
Question 2
I tried this tutorial http://nicolaspouillard.fr/ocamlbuild/ocamlbuild-user-guide.html, it is good for ocamlbuild.
But if I want to use external libraries such as ocaml-batteries or camomile, how can I link those libraries using ocamlbuild?
Question 3
This is a more practical question about all the external libraries.
So for many ocaml libraries, I use opam install to install them.
why need to install a library? I mean, in Java, normally we just copy a lib to somewhere and then include the path of the lib into -classpath or -cp. then why we need to install a OCaml library?
after opam install a lib, such as camomile (for utf8), what happened and what will happen? Is this kind of install just download sourcefiles of a lib and copy it to somewhere?
how can find the library then? for example, if I opam install camomile, then how can I link or use them in my own code?
normally how to use a ocaml library? for example, for camomile (http://camomile.sourceforge.net/dochtml/index.html) they have three modules: CamomileLibrary, etc. So I should open the module in my code, right?
Tools:
ocamlc: OCaml to bytecode compiler
ocamlopt: OCaml to native code compiler
ocamlfind: wrapper around ocamlc and ocamlopt to compile/link with various OCaml packages, i.e. you use "ocamlfind ocamlopt -package camomile -c yourfile.ml' to compile with yourfile.ml,
and you use 'ocamlfind ocamlopt -package camomile yourfile.cmx -linkpkg -o yourfile' to create an executable
oasis: a build system generator like autoconf&automake for C/C++ but much simpler
With a recent ocamlbuild you can use 'ocamlbuild -use-ocamlfind -pkg -pkg ... ' as quick way of building your project with ocamlfind packages package1, package2.
A next step would be to use 'ocamlbuild -use-ocamlfind ' and put package() directives in a _tags file.
However I would recommend trying oasis, it simplifies creating a build system for your project.
If you want to see what happens "under-the-hood" when using oasis or ocamlbuild see the _build/_log file. It contains all the ocamlfind/ocamlc/ocamldep/ocamlopt invocations.
The opam question probably belongs into a separate question.
I have the following package Makefile:
include ${GOROOT}/src/Make.inc
TARG=gorilla.googlecode.com/hg/gorilla/mux
GOFILES=\
doc.go\
mux.go\
DEPS=\
gorilla.googlecode.com/hg/gorilla/context
include ${GOROOT}/src/Make.pkg
I changed TARG and DEPS today to point to the Google code repository as shown above, following this advice.
The problem is: I can goinstall the package and it will install the dependency, but I cannot use gotest or gomake anymore; I get the following error (using Go r59):
moraes#yukon:~/dev/repos/gorilla/gorilla/mux$ gotest
rm -f _test/gorilla.googlecode.com/hg/gorilla/mux.a
make -C gorilla.googlecode.com/hg/gorilla/context install
make: *** gorilla.googlecode.com/hg/gorilla/context: No such file or directory. Stop.
make: *** [gorilla.googlecode.com/hg/gorilla/context.make] Error 2
gotest: "/home/moraes/dev/repos/go/go.r59/bin/gomake testpackage GOTESTFILES=mux_test.go" failed: exit status 2
I tried goinstalling the dependency first (goinstall gorilla.googlecode.com/hg/gorilla/context), and it installs correctly in $GOROOT/pkg but the same error occurs with gotest/gomake.
I think I'm missing something pretty basic. How should I proceed to use gomake/gotest with the Makefile above? Is this supposed to work at all, or should I use a different one for development?
goinstall doesn't use the Makefile at all. Instead, it will parse dependencies directly from your .go files.
To specify dependencies, annotate your import lines with a "normalised" reference to the dependency. eg.
import (
gorilla_context "gorilla.googlecode.com/hg/gorilla/context"
...
gomake doesn't automatically resolve dependencies though, so you'll have to manually install them.
Similarly, for installing cgo source with goinstall, you can specify CFLAGS and LDFLAGS in comment directives. eg.
/*
#cgo CFLAGS: -I/usr/local/include
#cgo LDFLAGS: -L/usr/local/lib -lzmq
#include <zmq.h>
*/
import "C"
I think the Makefile is trying to find the file gorilla.googlecode.com/hg/gorilla/context in the current directory. Also, why would you want to specify it in a make file as opposed to importing it from within the Source?
I've installed Haskell via the pre built installer v6.8.2.
When trying to compile this sample file with GHC
module Main where
import Text.ParserCombinators.Parsec
import System.Environment
main :: IO ()
main = do args <- getArgs
putStrLn ("Hello")
I get the following error:
D:\src\Haskell>ghc -o read read.hs
ghc -o read read.hs
read.o(.text+0x1b5):fake: undefined reference to `__stginit_parseczm2zi1zi0zi0_TextziParserCombinatorsziParsec_'
collect2: ld returned 1 exit status
I have installed Parsec via cabal.
Does anyone have any idea's as to what is wrong?
Try ghc --make -o read read.hs. GHC will take care of linker dependencies.
I'll put out one other way to make this work
ghc -package parsec -o read read.hs
From the ghc documentation
-package P
This option causes the installed package P to be exposed. The package P can be
specified in full with its version number (e.g. network-1.0) or the version number
can be omitted if there is only one version of the package installed. If there are
multiple versions of P installed, then all other versions will become hidden.
The -package P option also causes package P to be linked into the resulting
executable or shared object. Whether a packages' library is linked statically or
dynamically is controlled by the flag pair -static/-dynamic.
see http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
According to the Parsec docs (section 1.2.1 Compiling with GHC), you should do this:
When your linking the files together,
you need to tell GHC where it can find
libraries (-L) and to link with the
Parsec library too (-l):
ghc -o myprogram myfile1.o myfile2.o -Lc:\parsec -lparsec
This documentation on the Haskell compiler may help.