Docs GODI Archive
Projects Blog Link DB

Look up function:

(e.g. "List.find" or "keysym")
More options
Frequently Answered Questions on GODI

Note: This is the beginnning of a FAQ page, in order to make
information more accessible. It is based on real questions.

Why are POSIX threads disabled for FreeBSD?

Because they don't work well enough, i.e. there is a problem in 
the threading implementation of FreeBSD.

For a description of the problem, see tickets 1820, 1821 of the O'Caml
bug database:;page=47;user=guest;page=48;user=guest

GODI does not work on Gentoo. What is going on?

> Thank you for your answer.You were right, I had
> the environment variables PKGDIR and DISTDIR
> set, and this was messing up with the installation of Godi.
> This is quite puzzling, and those variables are often
> set when using a Gentoo Linux distribution ... Perhaps
> it would be a good idea to unset them in Godi scripts.

It is a bug that these variables are taken from the environment.

Scanning the packages takes so long. Why?

> I like Godi a lot, it seems quite powerful. But if think
> it's strange that with only 34 packages, the scanning
> takes several seconds ... 

Because it invokes "make" 34 times. I am already working on a solution,
a Makefile parser. The problem is that "make" does 34 times almost the
same (parsing some large files), and with an integrated parser I can
arrange that the expensive, repeated actions are done only once.

How do I make a GODI package?

(Removed - this is now explained in the "GODI User's Manual".)

For some libraries there are three packages: base-foo, conf-foo,
godi-foo. Why?

Background information: The base-foo package contains the C library,
and is optional (it is also possible to use an already installed
version of the C library). The conf-foo package contains compiler
and linker options for this library. The godi-foo package is the
rest, i.e. the O'Caml bindings, and the higher layers.

> What is the rationale behind the three packages approach? Wouldn't it be
> possible to have a single package that takes care of installing the C
> library if necessary (maybe by creating dynamically a virtual local
> package)? I doesn't know much about the BSD package system, so this may
> simply be stupid.

There is no such thing like a virtual package: Every source package
produces exactly one binary package. So the base package must be an
extra package (which, btw, has also the advantage that we can copy it
from NetBSD). There are several justifications for the conf package:

- Library sharing: It is possible that several O'Caml packages implement
  bindings for the same C library (e.g. libX11 is already used by a lot
  of packages). The code for determining the compiler options must
  only be written once, and it is ensured that all users of a library
  use the same instance

- Easier configuration: The conf package quickly determines whether
  the compiler options do work or do not work. If this kind of 
  configuration were integrated into the configuration step of the
  godi-xxx package, it would take longer, and the relevant messages
  would be only a fraction of the whole output. (However, this
  may be different in the concrete case.)

- Documentation: The "binary" conf package contains the
  file that documents which library instance was really used when
  the package was built. This can be quite important information
  when you want to maintain systems over a longer period of time.

Note that there are some packages that do NOT follow the three-package
approach, e.g. godi-lablgl. They still use the old style, and need
to be updated. Please do NOT put the file godi.pkg.defaults.pat
into your build directory; this feature will be removed.

So, how do conf packages work? For instance, conf-pcre is a good
example. When you build conf-pcre, you can pass a number of options
to it:

- GODI_BASEPKG_PCRE (whether to link against the library in base-pcre)
- GODI_PCRE_INCDIR  (directory where to find include files)
- GODI_PCRE_LIBDIR  (directory where to find the library file)

This is purely optional. If these options are missing, it will be tried
to guess them (like autoconf would do it). The build will fail if the
options cannot be figured out. It is even tried to compile test programs
linking with libpcre to be absolutely sure that the options work.

The result of the build stage of conf-pcre is a single file:
lib/godi/ It contains four variables which are now
ensured to contain working settings:

- CONF_PCRE_INCDIR      (directory where to find include files)
- CONF_PCRE_LIBDIR      (directory where to find the library file)
- CONF_PCRE_NEED_RPATH  (whether to pass -rpath to the linker)
- CONF_PCRE_DEPENDS     (additional package dependencies to get pcre)

A package that wishes to link against libpcre can now include this
file into its own Makefile, and can directly use these variables.
Because conf-pcre has generated them, it is guaranteed that they work.
See godi-pcre for an example.

When CONF_PCRE_DEPENDS is non-empty, it contains the dependeny on
base-pcre, i.e. one can simply add this variable to DEPENDS.

Note that the CONF_* variables must not be set in godi.conf. They are not
intended to be configurable by the user. The corresponding GODI_*
variables should be set by the user.

Note that there is the global variable SEARCH_LIBS that contains
directories where the configure script should search libraries.
By default, a number of frequent locations are tried, like
/usr, /usr/local, /usr/pkg. One can set SEARCH_LIBS in godi.conf
to add more directories.

The C library provides a "foo-config" script printing compiler
and linker options. Should I use this script for my package?

[Answer updated on 2004-02-27.]

> I was concerned about the lack of support for curl-config (a shell script
> that can provide relevant compiler flags for the library). Instead of
> having GODI_CURL_INCDIR and GODI_CURL_LIBDIR, it would be possible to have
> a single GODI_CURL_CONFIG pointing to the curl-config shell. Actually, the
> same applies to pcre. Any opinion about these xxx-config?

These scripts follow a quite simple philosophy, and work very well if
you have only one (system) instance of the library. If there is more
than one instance, the PATH variable will control which of the instances
is actually used. You can get into difficult situations when there are
several libraries, and for some of them the system version should be
preferred, and for some of them another version. Which PATH is the right

I think there should be the option of detailed control where the library
is expected to reside. This means it should be at least possible to
specify the exact path of the foo-config script.

We have already packages that rely on pkg-config, among them is
lablgtk2. It currently does not allow to detail from which script it
extracts its configuration.  This is something to improve, and should
not be copied for other packages. Of course, only using the system
instance makes sense here (in other words: supporting alternative
library instances would mean a lot of work with questionable value).

A very good example how to take advantage from foo-config scripts are
the packages conf-sdl and godi-ocamlsdl. The library SDL always installs
an sdl-config script. The package conf-sdl searches this script in
PATH, but it is also possible to specify the exact location.
Furthermore, it is tested whether the configuration works, and it is
also tested whether RPATH options must be added. It is, however, not
possible to specify the compiler and linker options for SDL manually.
In godi-ocamlsdl it must be ensured that the tested sdl-config script
is actually used for configuration. Fortunately, this location of this
script can be passed to the "configure" script of ocamlsdl (as
environment variable). 

The advantages of this solution:

- It is still possible to have SDL installed in unusual locations,
  it is not even necessary to have sdl-config in PATH.

- After the package conf-sdl is installed, the configuration is
  fixed, and is no longer depends on environment variables like PATH.
  This means the configuration is reproducible.

- The package conf-sdl does not blindly trust the script sdl-config.
  It is tested whether the configuration works before it is accepted
  for the inclusion into the GODI installation.

It is possible to have more than one instance of GODI?

Of course, but you must bootstrap GODI several times into distinct
target directories.

> 6) It appears that gobi only supports one instance of ocaml.  Can
>    it support more than one and be like a general RPM database
>    that supports multiple versions?
>    I can see this being hard to do and not worth the effort.
>    However, I may want multiple Ocaml installs to support
>    products and people with older Ocaml's.  In this case,
>    even if I couldn't share godi, it would be useful to have
>    a common build directory.  Is this possible?

You can have several independent godi installations. I think this is the
only sensible way to handle this problem. Maybe there should be better
support for transferring package lists from one instance to the other,
so one can create easily a new godi installation with the same packages
(but different versions) and configuration as an already existing

Supporting multiple versions with one installation is almost impossible.
In my first trial I had a tricky directory layout such that there would
be several ocaml versions, and one could switch between them. I dropped
that because it was not worth the effort, too error-prone, and there is
also the problem that godi itself depends on one version of ocaml, and
the question is on which version.

Sharing build directories: No good idea. You can share the "distfiles"
directory, but I think all other directories could be problematic,
especially "packages" (because the requirements of a package are not
encoded in the filename). "mk" is an essential part of godi. The other
directories are only temporarily used, so sharing them is not very

Why does GODI use the RPATH feature to look up shared libraries?

Background information: GODI patches the ocamlmklib script such that
stub libraries always look into the lib directory of GODI,
where additional shared libraries can be installed. The real question
here is whether it is possible to get rid of this patch.

> What about LD_LIBRARY_PATH? I believe that in general it overrides the
> search path of the binary, and people often set it to /usr/local/lib
> on solaris...

I know a lot of people who consider LD_LIBRARY_PATH as an unprofessional
solution, at least for a permanent installation. The point is that the
caller of a program must ensure that libraries are found, and not the
program itself. A lot of things can go wrong. setuid programs do not
work. It is sometimes difficult to set LD_LIBRARY_PATH, e.g. for
programs called from daemons. Administrators don't like it because it is
another global thing they have to manage.

Btw, Solaris has now something like of Linux, but it is
called differently, and adding a directory here is a good idea if it
should be considered as equal with /usr/lib.

However, this is no solution for GODI's lib directory. This is not a
global directory, it should be possible to have several GODI
installations on the same system. is no option.
LD_LIBRARY_PATH has disadvantages and acceptance problems. I think the
only remaining possibility is to set the RPATH section in the
executables (which is supported by all ELF systems, and maybe others). I
have done this by patching ocamlmklib (but it could also be a wrapper
around ocamlmklib to get rid of the patch).

This web site is published by Informatikb√ľro Gerd Stolpmann
Powered by Caml