I want to use the Graphics modules that I installed on my machine with opam but it didn't recognized it, i have the output :
1 | let open Graphics in
^^^^^^^^
Error: Unbound module Graphics
when i run ocaml main.ml, even if my file starts with :
#use "topfind"
I'have tried reinstalling it multiple times, and i checked, it's correctly install in /home/me/.opam/default/lib/graphics.
I'm using Debian with ocaml 4.14
An opam package contains one (or sometimes more) libraries which themselves contain many modules (or sometimes only one module).
In the case of graphics, the opam package only contains the graphics library. To access the module of the library, you need to tell the REPL(toplevel) that you intend to use the graphics library with
#require "graphics";
then you will be able to use the Graphics module from the graphics library.
Note that outside of scripts, the information of which libraries to use should be part of the description of your project. If you are using dune (aka the recommended build system for OCaml), this means adding
(libraries graphics)
to your dune file.
Related
We are trying to cross compile the wxGTK (2.8.12) to our ARMv5 embedded device.
Since RAM space is limited to 64MB, we thought of not using X11.
So, we have built DirectFB and GTK+ (with gdktarget as directfb and without x).
Now, we are trying to build wxGTK with GTK+. But it seems like, it need X11 header files. Got following compiler errors:
./src/unix/utilsx11.cpp:31:22: warning: X11/Xlib.h: No such file or directory
./src/unix/utilsx11.cpp:33:23: warning: X11/Xutil.h: No such file or directory
./src/unix/utilsx11.cpp:40:22: warning: gdk/gdkx.h: No such file or directory
./src/unix/utilsx11.cpp:44: error: ‘Atom’ does not name a typeenter code here
....
Is it possible to build wxGTK with GTK+ (directfb) but without X?
Thanks,
Hari
wxGTK requires GTK+ and, while GTK+ can use different backends, notably Wayland, it's unlikely to be available on your device.
You could try building wxDirectFB instead, but wxDFB is a very alpha-quality port which hasn't been in use since quite some time, so you should be ready to do some work on it yourself in order to implement the missing parts (there will definitely be at least some).
There is a minimalist GNOME implementation based on the GTK+. It is based on the X11 and GTK+. It can be build using OpenEmbedded or probably downloaded as prebuilt WM.
Now looking at it I think you can try GNOME Embedded with wxGTK.
I am creating a Mapnik plugin (https://github.com/rbuch703/coords-mapnik-plugin), and am currently working on packaging it for Debian/Ubuntu. The binary package consists of only a single shared library that is built from C++ code. But being a Mapnik plugin, this library follows conventions quite different from the usual POSIX library conventions:
the file name has to be <name>.input instead of lib<name>.so
the file is installed in the Mapnik plugin directory (usually /usr/lib/mapnik/input)
the file is not supposed to be found by ldconfig, but rather Mapnik tries to find the plugin by itself at runtime
Now the plugin's build system is cmake, which makes most parts of Debian packaging straight-forward: the debian/rules file contains only the basic lines:
#!/usr/bin/make -f
%:
dh $#
However, I am running into problems with the substitution variable {shlibs:Depends}: it is simply not set (in particular, there is no corresponding line in the debian/<package name>.substvars file), and Lintian rightly complains about that fact (Lintian's actual complaint is missing-dependency-on-libc. But when I manually add a libc dependency, Lintian explains package-depends-on-hardcoded-libc, which means "The given package declares a dependency on libc directly instead of using ${shlibs:Depends} in its debian/control stanza."). I would like to satisfy Lintian in than respect, but are unable to do so.
Now I found that I could add the line
dpkg-shlibdeps debian/<packagename>/usr/lib/mapnik/input/coords.input
to my rules file. That will create the correct ${shlibs:Depends} line, but it will create it in the wrong file (debian/substvars instead of debian/<package name>.substvars), where the build system simply ignores it and Lintian keeps complaining about missing dependencies.
I am guessing that the root of my problem is that my Mapnik plugin does not conform to the POSIX library naming conventions (and as a Mapnik plugin cannot do so), and thus the packaging system does not handle it correctly. But I am at a loss as to how to fix this problem.
Additional notes:
the packages are built using debuild. Apart from the Lintian error messages, the build process work fine and correctly creates the .deb package.
my practical goal is for the package to build cleanly on Launchpad, so that I can add it to my Ubuntu PPA.
you can provide an output file for dpkg-shlibdeps with the -T flag.
something like:
override_dh_shlibdeps:
dh_shlibdeps
dpkg-shlibdeps \
-Tdebian/<packagename>.substvars \
debian/<packagename>/usr/lib/mapnik/input/coords.input
if there are multiple *.input files, you could also do something like:
override_dh_shlibdeps:
dh_shlibdeps
find debian/<packagename>/ -name "*.input" -exec \
dpkg-shlibdeps -Tdebian/<packagename>.substvars {} +
# open Std;;
Characters 0-8:
open Std;;
^^^^^^^^
Error: Unbound module Std
Run in the ocaml interpreter. I had previously installed ocaml-extlib-devel and ocaml-extlib. What else do I need to do to get the module installed?
(I'm working on RedHat Linux, FC-18).
What you need to do is:
#use "topfind";;
#require "extlib";;
You need to type those #, in additional to the prompt, because those are toplevel directives. They use the library findlib which also provides the ocamlfind tool and is probably installed in your OCaml environment (otherwise you should get it installed). It knows where to find ocaml packages in your filesystem.
I am working on a project that is using Leopardboard DM368 interfacing with LI-M024DUAL camera board for stereo vision. The camera uses Aptina's MT09M024 as its image sensor.
After spending a lot of time on the web searching for appropriate drivers I asked the OEM to provide me some support. They provided me with the driver source files. The problem is I am not able to include them to the kernel.
I also looked up for the method to build modules and am fairly comfortable with it. But with the current driver I have a bunch of *.c files that use non-existent header files (I am not able to find these linux header files in the /linux directory).
Now my question is if I have the source code for an image sensor driver and want to build it, what is the general procedure followed for the same.
Any help in this regard would be welcome.
-Kartik
There are two ways to build you module:
1. Statically linking to kernel image (inbuilt)
2. Creating dynamically loadable Modules
Statically linking to kernel image (inbuilt)
For this you must find a appropriate place in kernel folder (somewhere in drivers/) to copy your .c files. copy them there. Edit Kconfig and Makefiles refering to other kernel drivers. and enable the support using menuconfig. Compile.
Creating dynamically loadable Modules
You can built without copying them to Kernel source. Just create a Makefile and place rules in Makefile to compile your module. Here you must link your module to your kernel by providing the kernel source path.
For more google should help.
I have a file Tools.ml which contains some common utility functions I write myself. Under .../Code/ I have several folders which each contains a project. My question is where I should place this Tools.ml such that all the folders and files under .../Code/ could share this module by Open Tools.
Hope my question is clear... Does anyone have a good solution?
Edit1: Following #gasche's answer, I have written tools.ml as follows:
module Tools =
struct
let a_function = ...
...
end
Then I compiled it, and done ocamlfind install tools META tools.cmo tools.cmx tools.ml as suggested, which looks going well. Then I have written test.ml as follows:
open Tools
let f = Tools.a_function
then I compiled it with ocamlc test.ml -o test, then I got an error:
File "test.ml", line 1, characters 0-1:
Error: Error while linking test.cmo:
Reference to undefined global `Tools'
Could anyone tell me what happened?
You could package it as an independent library, install it with other OCaml libraries, and access to it, from your project, as a library.
A very simple way to do this is to write a META file for ocamlfind. Create a directory somewhere you're comfortable to hold you "personal library" project. Suppose you have tools.ml and tools.mli, and your code depends on some findlib package (eg. unix and bigarray). You META would look like this:
name="tools"
description="personal collection of utilities"
version="0.1"
requires="unix,bigarray"
archive(byte)="tools.cmo"
archive(native)="tools.cmx"
Once you have written this META file, it is easy to ask ocamlfind to "install" the library (and remove it if you want to), and use it in your other projects. To install, the syntax is ocamlfind install <name> <meta-file> <file1> <file2> ... where <file1>, <file2>.. are the file you wish to see included in the installation directory. You must at least have tools.cmi tools.cmo (and tools.o and tools.cmx for native compilation), but it is good practice to also have tools.mli for example (and, if you want to provide the code, tools.ml).
ocamlfind install tools META tools.cmi tools.cmo tools.o tools.cmx tools.mli
(Of course tools.cmo etc. have to exist, that is you must install after you have compiled your package. If you have used ocamlbuild, they are likely to be in a _build subdirectory, so ocamlfind install ... _build/tools.cmo ....)
From your numerous projects, you can use your library easily, either using the ocamlfind toold directly if this is what you already do to compile your programs
ocamlfind ocamlc -package tools ....
or through the facilities provided by ocamlbuild for example, adding package(tools) to your tags.
To reinstall your library if you made a change to it and want it accessible from your projects
ocamlfind remove tools
ocamlfind install tools META ...
You could also handle all this through oasis, which is a layer on top of ocamlfind/ocamlbuild to automate this process. I'm not familiar enough with oasis to give such examples off the top of my head, but it should be equally simple for such a restricted case (one-file library), and scale better if you wish later to extend your library (eg. it can also handle documentation generation, pre-compilation configuration...).