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: Search path for C libraries Date: Tue, 18 Oct 2005 14:12:56 +0400 Message-ID: <6efab2350510180312r59e14d94he768ba03ac18a97b@mail.gmail.com> References: <878xwx5ld2.fsf@ossau.uklinux.net> <8764s0a7e6.fsf@laas.fr> <8764rzj8py.fsf@ossau.uklinux.net> <87ach8bmdg.fsf@laas.fr> <87mzl7grnd.fsf_-_@laas.fr> 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 1129630803 10124 80.91.229.2 (18 Oct 2005 10:20:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2005 10:20:03 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Oct 18 12:19:49 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ERoXq-0006Te-QP for guile-user@m.gmane.org; Tue, 18 Oct 2005 12:18:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERoXo-0004vK-Vd for guile-user@m.gmane.org; Tue, 18 Oct 2005 06:18:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ERoSr-00039V-19 for guile-user@gnu.org; Tue, 18 Oct 2005 06:13:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ERoSo-00036t-Nb for guile-user@gnu.org; Tue, 18 Oct 2005 06:12:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERoSn-00035T-G6 for guile-user@gnu.org; Tue, 18 Oct 2005 06:12:57 -0400 Original-Received: from [72.14.204.192] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ERoSn-0000cu-DY for guile-user@gnu.org; Tue, 18 Oct 2005 06:12:57 -0400 Original-Received: by qproxy.gmail.com with SMTP id e14so1059634qbc for ; Tue, 18 Oct 2005 03:12:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H6RU1Kw+Z8/eaPSBx/bjidDBXm9ietvSdk+V7wG0qqFjSDDcAllg/vUUJW04lfYAMPtZVt6UY0I/k7N3SRjVJ6SRLu/9vcIDJwLKB31nDe2PARy43HClS5NC69w9pitM+EX77KijsNIW8pHc1lMVAAoc6BzBR3EQLHZK4UKvAm4= Original-Received: by 10.65.98.6 with SMTP id a6mr2881522qbm; Tue, 18 Oct 2005 03:12:56 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Tue, 18 Oct 2005 03:12:56 -0700 (PDT) Original-To: Guile Users In-Reply-To: <87mzl7grnd.fsf_-_@laas.fr> 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:4869 Archived-At: On 10/18/05, Ludovic Court=E8s wrote: > Hi, > > Greg Troxel writes: > > > Perhaps dynamic-link should look in guilelibdir _only_ if an absolute > > path is not given, or a primitive that does this. One important > > feature is that inclusion, dynamic link, etc. should be able to ensure > > it gets exactly what was searched for and tested at configure time. > > Right. This is one of the concerns that was raised by Vorfeed Canal > earlier I think. > Yup. This is EXACTLY why libltdl have search_path in first place. Of course libltdl WILL NOT try to use this path if full path is given in load-extension - this is all built in ltdl: http://www.gnu.org/software/libtool/manual.html#Using-libltdl In my patch I moved search_path to scheme level and when dynamic loaded is used old ltdl search_path will be forgotten. Since guile is designed to be used in big, complex programs perhaps its better to save search path and then restore it. And this must be done under=20 lt_dlmutex_lock/lt_dlmutex_unlock, obviously. I left all this out of patch since this was proof-of-concept kinda thing anyway and since before guile 1.8 release someone should do something with this: -- guile-1.7.2/libguile/dynl.c /* From the libtool manual: "Note that libltdl is not threadsafe, i.e. a multithreaded application has to use a mutex for libltdl.". Guile does not currently support pre-emptive threads, so there is no mutex. Previously SCM_CRITICAL_SECTION_START and SCM_CRITICAL_SECTION_END were used: they are mentioned here in case somebody is grepping for thread problems ;) */ -- cut -- Libtool manual does not say this anymore: http://www.gnu.org/software/libtool/manual.html#Thread-Safety-in-libltdl and guile DOES have support for pre-emptive threads now so it's good idea to do something about this. This is separate problem and there are not much to discuss: ltdl can not be used in multi-threaded environment without lt_dlmutex_lock/lt_dlmutex_unlock (it changes global variable search-path internally, for example!) and while you can export ltdl's variable to scheme level "as is" you'll be forced to export LT_PATHSEP_CHAR as well and then every scheme module will be exposed to gory details of OS dynamic loading mechanism (":" vs ";") so it all will look quite ugly (barely better then current way of parsing and changing of LD_LIBRARY_PATH/LTDL_LIBRARY_PATH). > Maybe the right way to do this would in fact to have module developers > generate the `dynamic-link' code at configure-time (using Autoconf > substitution) in order to hard-wire the library path. It can be done already, but most distribution's HOWTOs are quite vocal about never using -rpath with C libraries - and this is the same thing. > Unfortunately, this isn't very elegant and it precludes, for instance, ru= nning the > module's test suite before installing it (because `dynamic-link' would > either fail or load the wrong library). This is one reason, yes. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user