As I understand, graphics.cmax isn't exist.
But how to compile ocaml program with using Graphics module by ocamlopt?
Is it possible? Maybe some alternative graphics libraries?
Well, graphics.cmax indeed doesn't exist, why it should? But graphics.cmxa does. So of course it is possible compile programs that use graphics library to a machine code. You can use ocamlfind to find a proper library depending on your compilation mode. For example on mine machine:
$ ocamlfind query -predicates native -a-format graphics
/home/ivg/.opam/fresh/lib/ocaml/graphics.cmxa
In a simple case, like this, with the graphics library that is distributed with the OCaml system itself, you can just add graphics.cmxa to the compilation string. On more complex cases, just use ocamlfind ocamlopt instead of ocamlopt, and specify -package option to refer to a library name, in your case it would be:
$ ocamlfind ocamlopt -package graphics ...
Or you can use ocamlbuld:
$ ocamlbuild -package graphics my_cool_application.native
where your cool application has an entry point in the my_cool_application.ml file.
Related
I have installed OCaml on my xfce and now I want to do some graphics program.
The problem is that I don't know how I can install graphics.cma ( I think it's this file that I need but i'm not sure ).
I have research on Google and in This forum but I can't find it..
After little search, I see that i have graphics.cma and graphics.cmxa .
I found this with ls $(ocamlc -where) | egrep cmx?a
I don't know why but yet, my graphics function work at all.
Sorry for inconvenience.
Thanks for helping me guys.
Have a nice day
I would suggest installing and using ocamlfind in order to not have to worry about library location:
ocamlfind ocamlc -package graphics -linkpkg test.ml
will compile your file with the right files loaded.
You can also load the package in the toplevel using
#use "topfind";;
#require "graphics";;
You have already installed the graphics module.
On Debian based systems the ocaml package is split into ocaml-base-nox and ocaml-base. The later contains the graphics module while the former is trimmed down.
The ocaml package is a meta package that depends on both of those and the description says (at the end):
This package contains everything needed to develop OCaml applications,
including the graphics libraries.
So you are all set to play with graphics. Juliens answere of installing ocamlfind is a good idea though as it makes using graphics and other modules easier.
I followed this tutorial on OCaml FFI and installed Ctypes through OPAM:
opam install ctypes
However, OCaml does not find the module:
open Ctypes
(* ... *)
I receive the error:
Unbound module Ctypes
It looks like I need to let OCaml know where my Ctypes installation is? Do I need to update some path variable to let OCaml look for my libraries installed through OPAM?
This is Ubuntu 15.04, OCaml 4.01.0, OPAM 1.2.0.
Installing something on your system doesn't make it automatically visible for the compiler, this is true not only for OCaml, but for most conventional systems, like C or C++ to name a few.
That means that you need to pass some flags to the compiler, or to write Makefiles, or to use some project management systems.
In OCaml we have quite a mature infrastructure that plays very well with opam in particular. I do not want to go very deeply in explanations, just a fast overview.
ocamlfind tool is used to find libraries on your system. It is somewhat close to pkg-config in idea, but quite different in design. It wraps compiler tools in order to pass options to them.
ocamlbuild is a fancy swiss-knife that is a must have in the arsenal of every OCamler. It is a tool that knows all other tools, and how to glue them together. I would say that it is the preferred way to compile your projects, especially small one.
oasis is close to autotools in the spirit, but not that generic and is written in the premise, that it should be very easy to use. And indeed it is very easy, but still quite flexible and powerful.
With this overview in mind, we can go directly to your problem. So you've installed ctypes. Now let's take a look on how ctypes package is visible in your system from the ocamlfind perspective. The easiest way would be to list all packages, visible to ocamlfind and find ctypes there:
$ ocamlfind list | grep ctypes
ctypes (version: 0.4.1)
ctypes.foreign (version: 0.4.1)
ctypes.stubs (version: 0.4.1)
ctypes.top (version: 0.4.1)
So, it looks like, that under the ctypes umbrella there're 4 libraries. One basic library, and some extra libraries, that provides some functionality, that is not needed by default.
No let's try to use them with ocamlbuild
ocamlbuild -package ctypes yourprogram.native
Or, without ocamlbuild directly with ocamlfind:
ocamlfind ocamlopt -package ctypes yourprogram.ml -o yourprogram.native
As you may see, there is a package option, to which you can pass a name of the package as found by ocamlfind, and it will be automagically made visible to the compiler.
Can I compile files (e.g. C or C++ source code) using for my android device using the arm-linux-gnueabi-* toolchain?
My question might seem a bit silly, but will I get the same result as compiling with the arm-linux-androideabi-* toolchain?
A compilation might mean more than just converting source code to binary. A compiler like GCC also provides certain libraries, in this case libgcc for handling what hardware can't handle. When a compiler becomes a toolchain, it also provides runtime libraries standardised by the programming language similar to ones provided in target system. In arm-linux-gnueabi-'s case that might be libc and for arm-linux-androideabi- that's bionic.
You can produce compatible object files to be used by different compilers, that's what elf is for.
You can produce static executable which can be mighty in size and they should work on any matching hardware/kernel, because in that case toolchains aim for that.
But if you produce dynamic executables, those ones can only run on systems that's supporting their dependencies. Because of that a simple "hello world" application that's not static build by arm-linux-gnueabi- won't work on an Android system since it provides bionic, not libc.
Is there any way to produce stand alone haskell executable to run on different linux machines assuming the architecture is similar?
Sorry I should have been clearer. The other machines might not have ghc installed on them - a bit like pyinstaller for python is what I was looking for?
You can use the flags -static -optl-pthread -optl-static to avoid dynamically linked dependencies when compiling a Haskell project. This should help you run the compiled executable on two linux machines that do not have the exact same library versions.
Yes it is possible. Just like with gcc-produced binaries, you can copy them between systems assuming the dynamic libraries and platforms match.
In practice, that's a slightly higher bar than GCC binaries because GHC will dynamically link more libraries by default (ex: libgmp, unless you build GHC using integer-simple).
I am trying to compile a piece of software written in Fortran 77. I should point out that I don't know much at all about Fortran, and would really rather not start modifying the code for this software - particularly as I'm not sure what the licensing of the software is, and I don't know if I would be able to redistribute my modified version.
The code compiles fine on OS X and Windows using the g77 compiler that is (fairly easily) available for these systems. However, I cannot get it to work on my Ubuntu distribution, as I can't seem to get hold of g77 for Ubuntu anymore, and if I try and install an old version of it, it seems to muck up my entire GCC installation. I have tried compiling the code with both gfortran and g95, but it doesn't work with either as:
The code uses real variables as loop indices (yes, I know, bad idea). g95 supports this with the -freal-loops option, but gfortran doesn't.
The code uses real variables to index into arrays, which gfortran will support (with a warning), but g95 won't support.
Can anyone suggest a way to compile this code with those two 'dodgy' features using a modern and easily-available compiler such as g95 or gfortran?
Pass the argument -std=legacy to gfortran. Features removed in F95, like real loop and array indices, should compile (perhaps with a warning) in legacy mode.