From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vorfeed Canal Newsgroups: gmane.lisp.guile.user Subject: Re: PHP to GUILE Date: Tue, 27 Sep 2005 00:18:47 +0400 Message-ID: <6efab2350509261318537b55a4@mail.gmail.com> References: <6efab235050925145055ba774c@mail.gmail.com> <873bnrlix6.fsf@ossau.uklinux.net> <6efab235050926131843ce69e2@mail.gmail.com> Reply-To: Vorfeed Canal NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1127766442 19509 80.91.229.2 (26 Sep 2005 20:27:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Sep 2005 20:27:22 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Sep 26 22:27:13 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EJzY5-0000zG-W4 for guile-user@m.gmane.org; Mon, 26 Sep 2005 22:26:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EJzY5-0002VA-Cn for guile-user@m.gmane.org; Mon, 26 Sep 2005 16:26:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EJzTy-0001bO-KT for guile-user@gnu.org; Mon, 26 Sep 2005 16:21:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EJzTn-0001Vm-VX for guile-user@gnu.org; Mon, 26 Sep 2005 16:21:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EJzTl-0001LZ-7G for guile-user@gnu.org; Mon, 26 Sep 2005 16:21:37 -0400 Original-Received: from [72.14.204.193] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EJzR2-0000fO-5P for guile-user@gnu.org; Mon, 26 Sep 2005 16:18:48 -0400 Original-Received: by qproxy.gmail.com with SMTP id e12so472249qbe for ; Mon, 26 Sep 2005 13:18:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LuiawGK2NpWVpa3remg3vUPk9JOjkJHiOSXcDOusH01Z8flIK17H9wXRPwWpqnVEyrZJwJjFgLKz7T1dsY+LTCnElbiRgWJsuLnBsWPWJcXyyqjPKgklFELBPEpxOv1+geMl5b32nYmiFCSXuKQtDf83eeeoLDoEZ427QlNCGwA= Original-Received: by 10.65.116.14 with SMTP id t14mr548858qbm; Mon, 26 Sep 2005 13:18:47 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Mon, 26 Sep 2005 13:18:47 -0700 (PDT) Original-To: guile-user@gnu.org In-Reply-To: <6efab235050926131843ce69e2@mail.gmail.com> Content-Disposition: inline X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4781 Archived-At: > > static void * > > sysdep_dynl_link (const char *fname, const char *subr) > > { > > - lt_dlhandle handle; > > - handle =3D lt_dlopenext (fname); > > + lt_dlhandle handle =3D NULL; > > + SCM scm_search_path =3D scm_string_join (*scm_loc_load_path, > > + scm_from_locale_string (":"), > > + SCM_UNDEFINED/*scm_sym_infix*/= ); > > + char * search_path =3D scm_to_locale_string (scm_search_path); > > + scm_frame_free (search_path); > > + if (!lt_dlsetsearchpath (search_path)) > > + { > > + handle =3D lt_dlopenext (fname); > > + } > > Will this still allow loading from the usual places as well? > Yes. http://www.gnu.org/software/libtool/manual.html#Libltdl-interface If libltdl cannot find the library and the file name filename does not have a directory component it will additionally search in the following search paths for the module (in the order as follows): 1. user-defined search path: This search path can be changed by the program using the functions lt_dlsetsearchpath, lt_dladdsearchdir and lt_dlinsertsearchdir. 2. libltdl's search path: This search path is the value of the environment variable LTDL_LIBRARY_PATH. 3. system library search path: The system dependent library search path (e.g. on Linux it is LD_LIBRARY_PATH). In reality libltdl will search in user-defined search path first, then in $LTDL_LIBRARY_PATH, then in $LD_LIBRARY_PATH, then in default path (/lib then /usr/lib on linux), then finally in current directory. Good from security viewpoint (of course from security viewpoint it'll be the best to avoid current directory altogether, but.. we can not have everything, right?). > Conclusion: this looks OK to me, but I'm not an expert on this > subject. I recall previous threads on why it is (or is not) desirable > for all Guile libraries to go into /usr/local/lib or /usr/lib, but I > can't remember what the arguments were. I'm not talking about GUILE libraries. I'm talking about EXTENSIONS libraries. While GUILE libraries for different versions of GUILE can happily live in /usr/lib (they have different API versions) this is NOT true for the extensions: their SO-number is related to API of the EXTENSION, not GUILE but this library is linked to GUILE library as well. Thus - collisions. It's possible to avoid this probloem with some hacks but... it's really better to just supply extension-writers with sane place DIFFERENT for different versions of GUILE. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user