caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sven Luther <luther@lambda.u-strasbg.fr>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: xavier.leroy@inria.fr, caml-list@inria.fr
Subject: Re: [Caml-list] OCaml packaging problems
Date: Wed, 15 May 2002 14:10:48 +0200	[thread overview]
Message-ID: <20020515121048.GB23062@lambda.u-strasbg.fr> (raw)
In-Reply-To: <20020514203954L.garrigue@kurims.kyoto-u.ac.jp>

On Tue, May 14, 2002 at 08:39:54PM +0900, Jacques Garrigue wrote:
> From: Xavier Leroy <xavier.leroy@inria.fr>
> Date: Tue, 14 May 2002 10:54:52 +0200
> 
> > Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> > (a tool that adds/removes lines from this file) and with Vitaly
> > Lugovsky's suggestion (multiple configuration files in a directory).
> 
> I was always wondering about the need for removing any directory from
> ld.conf: it the directory is not there, there will be no problem
> anyway...

So, you prefer to clutter the /usr/lib/ocaml/ld.conf file rather than
have a convenient tool for removing a line there when you remove the
package they belong to ? Remember, clutter is an open way to insecure
behavior ...

> > The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> > by the Unix dynamic loader.  It is intended to list a small number of
> > standard directories that contain shared libraries, typically one
> > directory for the "system" libraries (i.e. those provided by the OCaml
> > core distribution), one for local extensions (e.g. /usr/local/lib),
> > and perhaps one or two for especially large packages with many libraries
> > (e.g. /usr/X11R6/lib).  
> > 
> > When you install a package that provides a C shared library, you don't
> > install it in a package-dependent directory and add a line to
> > /etc/ld.so.conf with this directory; you install in /usr/lib or
> > /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> > the same scheme for OCaml shared libraries.
> 
> It's not because Unix does something wrong that you have to follow it.
> In the past I was installing libraries somewhere else (using --prefix
> in most packages) and using -rpath. The trouble is that -rpath is
> broken on some Unices, so I've reverted to making symbolic links to
> /usr/local/lib for the soname. Otherwise it's a pain to manage.

Mmm, there is a long discution on some of the debian lists (well a
flamewar would be a more correct name) with one side claiming that rpath
are evil, and can lead to problems if the files are moved around later
one (example cited was the moving of the /usr/X11R6 directory, probably
because you want to install a new X server while keeping the old one).

> Now I don't think that the current scheme in caml is perfect, but to
> me it works ok. When I delete a library I just delete its directory,
> and I'm sure it's clean.
> 
> > (And, yes, I haven't followed this recommendation in some of the
> > standard OCaml libraries (labltk) or some of my own extensions,
> > but I've realized my error and intend to fix this in release 3.05.)
> 
> I'm the culprit. And well, I have no definite opinion about libraries in
> the standard distribution, just that they set an example.
> Note that moving dlls around _is_ dangerous, because you may
> end-up with dlls with the same name in different place when
> overwriting an existing installation.

unless you have a package manager handling things :)))

> By the way, if you're so fond of the C way, using versioning on dlls
> would be very useful about this kind of problems (with the version in
> the .cma, rather than using symbolic links!)

:)))

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2002-05-15 20:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22 13:07 [Caml-list] Project Proposals Diego Olivier Fernandez Pons
2002-04-30  9:16 ` Xavier Leroy
2002-04-30 13:28   ` [Caml-list] OCaml packaging problems Vitaly Lugovsky
2002-04-30 15:08     ` Remi VANICAT
2002-04-30 18:04     ` Sven
2002-05-14  8:54       ` Xavier Leroy
2002-05-14 10:45         ` Stefano Zacchiroli
2002-05-14 15:46           ` Xavier Leroy
2002-05-14 11:39         ` Jacques Garrigue
2002-05-14 13:54           ` Michal Moskal
2002-05-14 23:28             ` Jacques Garrigue
2002-05-15 12:10           ` Sven Luther [this message]
2002-05-14 13:49         ` Michal Moskal
2002-05-14 22:52         ` Gerd Stolpmann
2002-05-15  1:18           ` Jacques Garrigue
2002-05-15 12:05         ` Sven Luther
2002-05-15 17:39           ` Vitaly Lugovsky
2002-05-16  7:11             ` Sven Luther
2002-05-16 10:24               ` Vitaly Lugovsky
2002-05-16 18:52                 ` Stefano Zacchiroli
2002-05-17 16:05                 ` Sven Luther
2002-05-17 19:31                   ` Vitaly Lugovsky
2002-05-18 10:39                     ` Michal Moskal
2002-05-21 19:54                     ` Sven Luther
2002-06-13 15:50         ` Sven Luther
2002-06-18 12:57           ` Xavier Leroy
2002-06-18 13:32             ` Sven Luther
2002-06-18 20:04               ` Gerd Stolpmann
2002-06-19  6:33                 ` Sven Luther
2002-06-19 11:09                   ` Markus Mottl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020515121048.GB23062@lambda.u-strasbg.fr \
    --to=luther@lambda.u-strasbg.fr \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    --cc=xavier.leroy@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).