From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id 3CC075D5 for ; Sun, 13 Feb 2022 16:56:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.88,365,1635199200"; d="scan'208,217";a="21106174" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 13 Feb 2022 17:56:08 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id EDD8BE0137; Sun, 13 Feb 2022 17:56:07 +0100 (CET) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 10237E008D for ; Sun, 13 Feb 2022 17:56:03 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=xavier.leroy@college-de-france.fr; spf=Pass smtp.mailfrom=xavier.leroy@college-de-france.fr; spf=None smtp.helo=postmaster@smtpout01-ext2.partage.renater.fr IronPort-SDR: 9K0f2d7MzPbLkcA1yMJNDtgLyULD+Mibh0IwYn52+ggKCVHwof7COoM3xzcQVDsJK/IvF0yEbo rQParQfIjeE8SMWHjEqooXQUp0U/3v9EEcbLtpfianMHAgnI0BF1ZIar3SPfWp5X4GGf/WYs5r NgpEf64o7LcidbLc+Gd9GxvFeetA0B8T+831cflob71Dd0oIrnKpJxWoM2z6GJaT72xXIQJcJy oiK+a9XqFYyV/v64jHsxysOKJs676O1M+cMNQibt+52ve6c628Uic9GX7UR41T8DPYfVSbVmfK IntunuyX+dd0a/I4QezZYbIo X-IronPort-AV: E=Sophos;i="5.88,365,1635199200"; d="scan'208,217";a="5787246" X-MGA-submission: =?us-ascii?q?MDFKZj+tHvr22JA8aW4DOBb4bBcP5Y5B4sJqIe?= =?us-ascii?q?kVdPqa24cETg/trTQwIx62XV8VXapT4Ya87mo89JMEBi4b/hOeGJAAMm?= =?us-ascii?q?0fBuphJg2qzgpQ3tv+SJjX6rYLaEY1Cvq0HFM7dgLvBcqS0MujMAWpQK?= =?us-ascii?q?m/LaM8KBR1OonFeQjLIyjFeQ=3D=3D?= Received: from smtpout01-ext2.partage.renater.fr ([194.254.240.33]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Feb 2022 17:56:03 +0100 Received: from zmtaauth01.partage.renater.fr (zmtaauth01.partage.renater.fr [194.254.240.25]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id CA24462145 for ; Sun, 13 Feb 2022 17:56:00 +0100 (CET) Received: from zmtaauth01.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPS id C278814008C for ; Sun, 13 Feb 2022 17:56:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTP id AFBCD14042C for ; Sun, 13 Feb 2022 17:56:00 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zmtaauth01.partage.renater.fr AFBCD14042C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=college-de-france.fr; s=05BE819C-8883-4F62-9828-EF4D49272C46; t=1644771360; bh=KnbeLDbVThJQUurCqEkuMUHTxJrGbTiW7nMfoUohtj8=; h=MIME-Version:From:Date:Message-ID:To; b=KW42KlKMK7UM6+fjDld086Ye870brUp4z2VFxzKKV/VAAE3Z21SxLjwKmfyy+E8kw 1daC+VnycrW7nr6tJ/2KXOLJSox1IjWQ8OSurSanzpECmDkghhIR8uXdtxsYzLJhRO ngDU41g5E3nVOIF+grBWtmSXQdV0YtXBb7gpwQ76TcHtR63S1OskKaNXSsxBFQLRyI Lt2B/Hh593EYGOPASYgQZ4obwnB0r1bvU+eLnI+p8kNhpYDNDDbvCrf2iGfO1K+6kL jzrCzV7YkS17W6hh4FGBc8IF+UfbZKOElnF62OUE6CiPXEpwfh9+v/cFrqNov8SQIQ P/EmB+ryyr23g== X-Virus-Scanned: amavisd-new at zmtaauth01.partage.renater.fr Received: from zmtaauth01.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth01.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t2ZONMCIpOqd for ; Sun, 13 Feb 2022 17:56:00 +0100 (CET) Received: from 209.85.128.49 (unknown [194.254.241.251]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPA id 81A2F14008C for ; Sun, 13 Feb 2022 17:56:00 +0100 (CET) Received: by mail-wm1-f49.google.com with SMTP id i19so6909978wmq.5 for ; Sun, 13 Feb 2022 08:56:00 -0800 (PST) X-Gm-Message-State: AOAM530OoxRmrAs2UeImJNTNeYkiobHgsJi4YFmlcHzjRP6fhUJ9lqze pFPzQ8BLlnuvcpPt1DEVYzDgA0Ip82bH2XCds/M= X-Google-Smtp-Source: ABdhPJzBzidnAIPmTW6DvdIE/Q1VDPzLdQONH+uJQGuj/N7gZip7NV5acRXSbnf5uX2l9aFbSoJqo+c+SpL5OfBJmBY= X-Received: by 2002:a7b:c34c:: with SMTP id l12mr8099252wmj.101.1644771360326; Sun, 13 Feb 2022 08:56:00 -0800 (PST) MIME-Version: 1.0 References: <3496160576413589fd508d9af3902f195cf2f1ee.camel@cea.fr> In-Reply-To: <3496160576413589fd508d9af3902f195cf2f1ee.camel@cea.fr> From: Xavier Leroy Date: Sun, 13 Feb 2022 17:55:34 +0100 X-Gmail-Original-Message-ID: Message-ID: To: BOBOT Francois Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary="000000000000ab492605d7e92c69" X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: -100 Subject: Re: [Caml-list] Dynamic link of C library Reply-To: Xavier Leroy X-Loop: caml-list@inria.fr X-Sequence: 18695 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --000000000000ab492605d7e92c69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 11, 2022 at 7:18 PM BOBOT Francois wrote: > Hi everyone, > > I'm a little lost with some binding. Usually I bind statically > C library in OCaml libraries (except for C libraries already present on > the system). It works well for all the targets (bytecode, native static > .cmxa, native dynamic .cmxs) by keeping the C library in the OCaml > library. Usually one just need to be sure that libfoo.a is compiled > with -fPic (which is not usual). However static linking lose the > advantage of a C library with the *L*GPL licence (no?). So I'm lost > between everything we have: > > - .cmxs needs ld to be able to find the dynamic C library, libfoo.so > - there is the stublibs directory, but it is only for bytecode and > files are prefixed by dll instead of lib so ld can't find them. > - There is no directory to install dynamic C library in opam, no > LD_LIBRARY_PATH set > - -dllpath requires to know the install directory during compilation > > > -dllpath is usually the chosen solution but hardcoding path makes build > cache less useful, and dune knows the install directory only at the > end. Is there an elegant solution I haven't seen or some of our tools > need to be modified? > This problem with Unix-style shared libraries is not specific to OCaml: you run into the same issues with a program entirely written in C, if I'm not mistaken. Popular wisdom says that .so files must be installed in /usr/lib or /usr/local/lib or some other public place advertised in /etc/ld.so.conf. (With semantic versioning, if applicable.) Some applications install their own .so files in a specific directory, then consist in a shell script that sets LD_LIBRARY_PATH before running the main executable. I'm not convinced OCaml tools should try to implement a different behavior. In particular, I would object to OPAM setting LD_LIBRARY_PATH in the environment to point to a directory owned by the user: it looks like a security risk. Kind regards, - Xavier Leroy > > Best, > > -- > Fran=C3=A7ois > --000000000000ab492605d7e92c69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 11, 2022 at 7:18 PM BOBOT Francois <Francois.BOBOT@cea.fr> wrote:
Hi everyone,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm a little lost with some binding. Usuall= y I bind statically
C library in OCaml libraries (except for C libraries already present on
the system). It works well for all the targets (bytecode, native static
.cmxa, native dynamic .cmxs) by keeping the C library in the OCaml
library. Usually one just need to be sure that libfoo.a is compiled
with -fPic (which is not usual). However static linking lose the
advantage of a C library with the *L*GPL licence (no?). So I'm lost
between everything we have:

=C2=A0 =C2=A0- .cmxs needs ld to be able to find the dynamic C library, lib= foo.so
=C2=A0 =C2=A0- there is the stublibs directory, but it is only for bytecode= and
files are prefixed by dll instead of lib so ld can't find them.
=C2=A0 =C2=A0- There is no directory to install dynamic C library in opam, = no
LD_LIBRARY_PATH set
=C2=A0 =C2=A0- -dllpath requires to know the install directory during compi= lation


-dllpath is usually the chosen solution but hardcoding path makes build
cache less useful, and dune knows the install directory only at the
end. Is there an elegant solution I haven't seen or some of our tools need to be modified?

This problem with = Unix-style shared libraries is not specific to OCaml: you run into the same= issues with a program entirely written in C, if I'm not mistaken.

Popular wisdom says that .so files must be installed i= n /usr/lib or /usr/local/lib or some other public place advertised in /etc/= ld.so.conf.=C2=A0 (With semantic versioning, if applicable.)=C2=A0 Some app= lications install their own .so files in a specific directory, then consist= in a shell script that sets LD_LIBRARY_PATH before running the main execut= able.=C2=A0

I'm not convinced OCaml tools= should try to implement a different behavior.=C2=A0 In particular, I would= object to OPAM setting LD_LIBRARY_PATH in the environment to point to a di= rectory owned by the user: it looks like a security risk.
Kind regards,

- Xavier Leroy
=C2=A0
=C2=A0

Best,

--
Fran=C3=A7ois
--000000000000ab492605d7e92c69--