I've got this program called threadtest.ml:
Thread.join (Thread.create (fun _ -> print_string "Hello, World!\n") ())
I'm compiling it like so:
$ ocamlc -thread unix.cma threads.cma -o threadtest threadtest.ml
File "threadtest.ml", line 1:
Error: Error on dynamically loaded library: /usr/lib/ocaml/stublibs/dllunix.so: flexdll error: cannot relocate RELOC_REL32, target is too far: 0xfffffffc020c7112 0x20c7112
This is what version of ocamlc I have.
$ ocamlc -v
The OCaml compiler, version 4.02.3
Standard library directory: /usr/lib/ocaml
What am I doing wrong? I've not found any explanation of this error.
UPDATE:
I've also tried rebasing my system by following the instructions here: https://stackoverflow.com/a/37616907/714167
But nothing seems to be working.
You should compile it with ocamlc -thread unix.cma threads.cma threadtest.ml
[EDIT] As camlspotter said in the comments, it can be a Cygwin32 problem, here's a copy/paste for those, like me, that never read the comments (waiting for OP to know if it works) :
camlspotter : My Cygwin OCaml has no problem of linking of your code. If I were you, I would clean up cygwin (and flexdll if exists) and start over. If you are using Cygwin32, probably migrating to Cygwin64 might fix your problem: I had too many rebase related problems with Cygwin32 and abandoned it.
Related
I'm trying to get rust working on android. However, when I try to cross-compile to android I get the following linking error:
$ cargo build --target=arm-linux-androideabi
Compiling <project> v0.1.0 (<project>)
error: linking with `/opt/android-sdk/ndk/23.0.7599858/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi31-clang` failed: exit status: 1
(very long toolchain command from cargo)
ld: error: unable to find library -lgcc
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
I have installed the ndk and changed the linker in .cargo/config to the android clang linker. I also tried the standalone toolchains with the same result. The guide I used was the following: https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html
Cross-compilation does work when using crate-type = ["rlib"] instead of crate-type = ["cdylib"], but I need an .so file not an .rlib file.
In case it's relevant, i'm using Manjaro Linux.
UPDATE:
I found the following pull request: https://github.com/rust-lang/rust/pull/85806 After switching to ndk22 it worked. I havn't tried if the pull request fixes the issue (probably does).
Without switching to an older NDK version, I found using the workaround provided by ssrlive to work for me. Here's their comment:
Fixing build error for NDK 23 and above
find out all the 4 folders containing file libunwind.a, in my PC,
it's
C:\Users\Administrator\AppData\Local\Android\Sdk\ndk\23.1.7779620\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\12.0.8\lib\linux\x86_64\
and more. create 4 text files named libgcc.a in the same folders
with this contents
INPUT(-lunwind)
reference
link
In macOS, the paths are
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/i386/libunwind.a
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/arm/libunwind.a
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/aarch64/libunwind.a
~/Library/Android/sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/darwin-x86_64/lib64/clang/14.0.1/lib/linux/x86_64/libunwind.a
In Linux, the paths are
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/i386/libunwind.a
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/aarch64/libunwind.a
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/x86_64/libunwind.a
~/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/arm/libunwind.a
In Windows, the paths are
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/aarch64/libunwind.a
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/arm/libunwind.a
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/i386/libunwind.a
~/AppData/Local/Android/Sdk/ndk/24.0.8215888/toolchains/llvm/prebuilt/windows-x86_64/lib64/clang/14.0.1/lib/linux/x86_64/libunwind.a
create file command in Linux/macOS
cat << EOF > libgcc.a
INPUT(-lunwind)
EOF
This is of course extremely brittle and not the "right" solution, but the workaround works fine as of 2022-10-12 with ndk version 25.1.8937393.
I'm a haskell beginner, I use the advent of code as learning examples.
When setting up for this year I reinstalled stack (on a new machine, however copied most dotfiles over) and was starting from my last years notes and was not able to get hdevtools working again.
I have set up a new project with stack new advent2019. In case it matters stack build on the "empty" project seems to take several minutes - seems much longer than last year. I install hdevtools with stack build hdevtools.
When I run stack exec hdevtools -- check src/Lib.hs I get following error:
Cabal error: hdevtools: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible
with Cabal. Use the flag --package-db to specify a package database (it can be
used multiple times).
So far I tried:
I checked my shell and did an rg --no-ignore over my home directory to confirm GHC_PACKAGE_PATH is not set by me. Also over the project directory.
I was not able to figure out how to use the mentioned --package-db flag - putting it after hdevtools I get an unknown flag error, putting it to stack I get an invalid option.
stack exec --no-ghc-package-path hdevtools -- check src/Lib.hs - mentioned here
I deleted all possible related files: ~/.local/bin/hdevtools, everything from ~/.stack, all ~/.ghc*.
None helped with the error.
I suppose I overlooked something obvious - however can you help point it out?
For completeness:
on OS X, 10.15.1
stack --version: Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
stack ghc -- --version: The Glorious Glasgow Haskell Compilation System, version 8.6.5
stack path:
stack-root: /Users/me/.stack
project-root: /Users/me/Code/advent2019
config-location: /Users/me/Code/advent2019/stack.yaml
bin-path: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/bin:/Users/me/.stack/compiler-tools/x86_64-osx/ghc-8.6.5/bin:/Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/bin:/usr/local/texlive/2018basic/bin/x86_64-darwin:/Users/me/.local/bin/:/Users/me/.gem/bin:/Users/me/.yarn/bin:/Users/me/Library/Python/3.7/bin/:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Library/TeX/texbin:.:/Applications/Wireshark.app/Contents/MacOS
programs: /Users/me/.stack/programs/x86_64-osx
compiler-exe: /Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/bin/ghc
compiler-bin: /Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/bin
compiler-tools-bin: /Users/me/.stack/compiler-tools/x86_64-osx/ghc-8.6.5/bin
local-bin: /Users/me/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/pkgdb
local-pkg-db: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/pkgdb
global-pkg-db: /Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d
ghc-package-path: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/pkgdb:/Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/pkgdb:/Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d
snapshot-install-root: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5
local-install-root: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5
snapshot-doc-root: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/doc
local-doc-root: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/doc
dist-dir: .stack-work/dist/x86_64-osx/Cabal-2.4.0.1
/Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/hpc
local-bin-path: /Users/me/.local/bin
ghc-paths: /Users/me/.stack/programs/x86_64-osx
The --no-ghc-package-path solution should have worked. However, you can just run hdevtools outside of Stack. On a Linux machine, if I run the following set of commands exactly:
$ stack new advent2019
$ cd advent2019
$ stack build
$ stack install hdevtools
$ hdevtools check src/Lib.hs
then hdevtools starts without error and runs in the background.
If your shell can't find hdevtools, it may be that ~/.local/bin is not in your path, so add it or try this instead:
$ ~/.local/bin/hdevtools check src/Lib.hs
Turns out I overlooked the .cabal directory in my purge. Though still had to also wipe .stack before installing hdevtools. Also had to build test separately so I would get dependency errors.
I don't think this is a solution for someone who uses haskell productively. Reminds me of my Windows 95 days where support told you to format and reinstall for every issue.
I am attempting to set up a new Stack project on NixOS with GHCJS as the compiler following the instructions at http://docs.haskellstack.org/en/stable/ghcjs.html
I have included in my stack.yaml file the following lines of code (all on one line because tab spaces seem to give issues):
# Compiler specifying the GHCJS compiler for this project (using improved base).
compiler: ghcjs-0.2.0.20151230.3_ghc-7.10.2
compiler-check: match-exact
setup-info:
ghcjs: source:
ghcjs-0.2.0.20151230.3_ghc7.10.2:
url: "https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz"
and I have retrieved the following error message when I ran stack setup
Could not parse '/home/lorkaan/pandocJS/stack.yaml':
InvalidYaml (Just (YamlParseException {yamlProblem = "mapping values are not allowed in this context", yamlContext = "", yamlProblemMark = YamlMark {yamlIndex = 487, yamlLine = 12, yamlColumn = 17}}))
See https://github.com/commercialhaskell/stack/blob/release/doc/yaml_configuration.md.
Additionally, I tried removing the setup-info field because Stack was complaining about it, leaving my stack.yaml file like:
# Compiler specifying the GHCJS compiler for this project (using improved base).
compiler: ghcjs-0.2.0.20151230.3_ghc-7.10.2
compiler-check: match-exact
which produces this output with the stack setup command:
Warning: /home/lorkaan/pandocJS/stack.yaml: Unrecognized field in ProjectAndConfigMonoid: compiler
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
The following executables are missing and must be installed: make
Does anybody have any idea why this would be happening?
the first error is because of a basic syntax error in your YAML configuration. The correct version would be:
setup-info:
ghcjs:
source:
ghcjs-0.2.0.20151230.3_ghc7.10.2:
url: "https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz"
The second error is because of exactly what it says: you are lacking the make utility. You need to use your Linux distribution's package management system to install make. Since I don't know which distribution you are on, I can only recommend simply executing the $ make command and seeing if the environment is smart enough to point out which package it can be found in. Ubuntu typically does that. Then it's only a matter of apt-get install-ing the package, or possibly yum install-ing on e.g. CentOS and Fedora, etc.
P.S. questions like yours normally get a downvote for not having shown sufficient effort in diagnosing the problem (or for putting 2 totally separate problems under a single question) but I'm giving you the benefit of the doubt and just hoping you'll be tidier next time.
I finally made it to install Haskell SDL bindings on Windows. Using this:
> $env:Path += ";C:\SDL;C:\SDL\bin;C:\SDL\include;C:\SDL\lib"
> cabal install SDL --extra-include-dirs="C:\SDL\include" --extra-lib-dirs="C:\SDL\lib"
This works, as long as Cygwin is installed for the configure script. However, I wrote a tiny test script:
import Graphics.UI.SDL as SDL
import Control.Monad (void)
import Control.Exception (bracket_)
main = bracket_ (SDL.init [InitEverything]) quit $ do
screen <- setVideoMode 800 600 0 []
SDL.flip screen
void $ waitEvent
Trying this now gives me this error message:
*Main> :main
Loading package SDL-0.6.4 ... <interactive>: mingw32: Cannot find specified module.
can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL)
Now I was looking for that mingw32.dll but I couldn't find it on my computer, though I have MinGW32 installed. Does anyone have had any experience here?
Using SDL-0.6.4, GHC 7.4.2 from Haskell Platform 2012.4.0.0. Windows 7 64-Bit.
ADDITION: I have now also tried it in the way A Haskell Adventure In Windows recommends, and that has the very same result.
It may be a 64 vs. 32 bit issue. Try copying that .dll to:
64-bit version of Windows: copy to c:\windows\syswow64
32-bit version of Windows: copy to c:\windows\system32
That helped me with FTGL - see here
I used MSYS/MinGW to build, and I was having the exact same problem. After fiddling around I found that the flag -lmingw32 (in the file sdl-config) is being used, and this seems to imply mingw32.dll. I simple remove this flagged, and everything worked.
I am trying to compile the source code of MEGAM Ocaml library on an Ubuntu 64 machine.
I have OCaml installed (v 3.12.1), using sudo apt-get install ocaml.
I am having an issue when running the "make" command in the terminal on the unzipped source code, with OCaml returning the error:
/user/bin/ld: cannot find -lstr
collect2: error: ld returned 1 exit status
The makefile is producing the following two commands:
ocamldep *.ml > .depend
No error when run
ocamlc -g -custom -o megam str.cma -cclib -lstr bigarray.cma -cclib -lbigarray unix.cma -cclib -lunix -I /usr/lib/ocaml/caml fastdot_c.c fastdot.cmo intHashtbl.cmo arry.cmo util.cmo data.cmo bitvec.cmo cg.cmo wsemlm.cmo bfgs.cmo pa.cmo perceptron.cmo radapt.cmo kernelmap.cmo abffs.cmo main.cmo
Throws the error above when run.
I've tried removing the -lstr from the compile command, it stopped throwing that particular error but started throwing another error (Reference to undefined global 'Bigarray'), which is making me thing it might all be something I missed during the OCaml installation, some kind of PATH or reference I needed to set.
Any help is really appreciated, even if its just a shot in the dark, as am really struggling to come up with anything!
The instructions given here allow me to compile with no error. It boils down to:
locate libcamlstr
which tells me that libcamlstr can be found in /usr/lib/ocaml (YMMV), so I do:
cd /usr/lib/ocaml
sudo ln -s libcamlstr.a libstr.a
Then I'm able to compile the project:
cd /usr/local/src/cil
make clean && ./configure && make
You could just change the makefile from
-lstr
to
-lcamlstr
See the last comment in this bug in the OCaml bug tracker:
Bug 5247