On Tue, May 14, 2002 at 10:54:52AM +0200, Xavier Leroy wrote: > 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). Would you care to argument a bit more about this, apart from the 'it is not the unix way' argument you give below that is. and BTW, ocaml-ldconf does not really add/remove lines from the /usr/lib/ocaml/ld.conf file, it uses two separate files (/etc/ocaml/ld.conf and /var/lib/ocaml/ld.conf) which are modified and used to generate the /usr/lib/ocaml/ld.conf. It is a nice concept (even if it is me saying it) that clearly separate the system administrator stuff (/etc/ocaml/ld.conf) from the dpkg/rpm/whatever handled stuff (/var/lib/ocaml/ld.conf), with the former taking precedence over the later. In no way does it modify the way ocaml handles this, and is thus a purely external tool doing its jjob correctly. > 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). So, what is the way we want to handle this ? Do we put all stuff related to libraries in a sub directory, like we were doing up to now, or do we revert to the name space poluting 'all in the same dir' concept ? If you do it the later way, this is a 180 degree turn from your previous position, and the one followed by most current libraries. Also, notice that in the above, you don't take into account the libraries provided by the OS distributor, which upto now did put their library stuff under a subdir of OCAMLLIBDIR. > 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. Well, if i remember well, the true C shared library is not really stored in /etc/ld.conf, but rather in some other space, and it is only the ldconfig tool which (from the manbpage) ldconfig creates the necessary links and cache (for use by the run-time linker, ld.so) to the most recent shared libraries found in the directories specified on the com­ mand line, in the file /etc/ld.so.conf, and in the trusted directories (/usr/lib and /lib). ldconfig checks the header and file names of the libraries it encounters when determining which versions should have their links updated. ldconfig ignores symbolic links when scanning for libraries. So if you trully want to do comparaisons, such a tool would be nice (and one that handles different versions even better :))) And about the symlink issue ? Why resort to it, if you can do it in a more clean way ? And if you are afraid of lot of incompatible changes, remember the ocaml-ldconf tool from the debian distribution handles our problem well and without interference on how ocaml does handle it. > (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.) There is nbo clear policy on that, and everyone does it their own way, or maybe the way they feel is the correct one, gathering it from how the inria people do with the libraries they release. It is mostly a guesswork thing, and would very much benefit from a 'standardisation' of such practives. Also, before you 'fix' things things in 3.05, maybe more based of a spur of the moment decision you are taking (which may not be the case, but seems so from your revirement from previous practices), i would very much like to have a true and open discution on this important subject, before any such decision is taken, but then, in the end it is you who decide on this (and i can always do the patching for the debian package :))) > So, to summarize, I strongly suggest the following approach for RPMs > or Debian packages: > - The main Caml package can add one or two lines to ld.conf, > e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages) > and /usr/local/lib/ocaml/shlibs (for local stuff) Ok, but why not put them in subdir like it is done all over the place right now ? (and what precedence will you use for the local over standard packages ? Or coiuld you choose a finer granularity for such choice ?) > - Packages for additional Caml libraries install their shared libraries > in /var/lib/ocaml/shlibs, either directly or via a symlink. Ok, i could live with that, _if_ you convince me that it is a better solution than the one available right now. Also a quick note about name space pollution, mayube it is not an issue, since you cannot anyway have two shared stub library of the same name, even in two different directories, isn't it ? So there is nothing gained by putting things in different dirs. > This is simple, consistent with C shared libraries, and supports > deinstallation of additional Caml libraries without any hassle. Just two things to conclude, first notice that on most system, C libraries are also put in subdirectories of /usr/lib, and this works ok, which is not currently the case in ocaml, and second I would _much_ have preferred you take such a stance 6 month ago, before we took the pain to discuss a viable solution for the debian ocaml related packages, and i lost times working on this back then. Friendly, Sven Luther > > - Xavier Leroy ------------------- 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