From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: cong gu Newsgroups: gmane.lisp.guile.user Subject: Re: using GSL with cblas via FFI Date: Mon, 4 Jun 2012 01:11:46 -0500 Message-ID: References: <87d35fn24s.fsf@gnuvola.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1338790316 23234 80.91.229.3 (4 Jun 2012 06:11:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Jun 2012 06:11:56 +0000 (UTC) Cc: guile-user@gnu.org To: Thien-Thi Nguyen Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jun 04 08:11:55 2012 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SbQWA-0005rI-P5 for guile-user@m.gmane.org; Mon, 04 Jun 2012 08:11:54 +0200 Original-Received: from localhost ([::1]:48742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbQWA-0003dG-Co for guile-user@m.gmane.org; Mon, 04 Jun 2012 02:11:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbQW6-0003d3-1l for guile-user@gnu.org; Mon, 04 Jun 2012 02:11:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbQW4-0000oD-4N for guile-user@gnu.org; Mon, 04 Jun 2012 02:11:49 -0400 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:60329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbQW3-0000n8-S1 for guile-user@gnu.org; Mon, 04 Jun 2012 02:11:48 -0400 Original-Received: by obbwd18 with SMTP id wd18so8366846obb.0 for ; Sun, 03 Jun 2012 23:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X3iCSJFda8B1mqoPPQkQedBRynFfqP/KK5umHApjh8Y=; b=Y7pahNURbVfyswGpujAJmHJOUBNsJ3pjGBGHVfH7V+Z26OseWmlvNi41K+DGYvCGXH ZtsY6lK3lFWk+7EDb+agcJPULCtO3PyLRkfmk0qCUBuNjVBUD0aPLMXc2DYP1krBqww7 dGkX4XsynrVHrv5UYakysmxIbQ8o6ur992dNqLBrxCFCOLF5JQJCQrV+Jwcq9wC2FIYH zPt8+w+726RbLVZvJ6PY7EoKp/tPutHb02TuYyy1M+JC+1oUomH6D9cuTtwEwmUPWHCT W1zjKY2Bop17NaPYe3VfDTkIOv58YVbOVksI+NRcSDgRV35qoC1WmvY2gvT5KibGREiy cFFQ== Original-Received: by 10.182.111.7 with SMTP id ie7mr10545925obb.14.1338790306046; Sun, 03 Jun 2012 23:11:46 -0700 (PDT) Original-Received: by 10.76.123.40 with HTTP; Sun, 3 Jun 2012 23:11:46 -0700 (PDT) In-Reply-To: <87d35fn24s.fsf@gnuvola.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.169 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:9494 Archived-At: On Sun, Jun 3, 2012 at 11:15 PM, Thien-Thi Nguyen wrote: > () cong gu > () Sun, 3 Jun 2012 17:04:29 -0500 > > =A0 I found libtool offers a way to make a shared library globally > =A0 available. =A0So I wrote a patch that provides `dynamic-link-global'. > =A0 A call like `(dynamic-link-global "libgslcblas")' should make > =A0 things work. > > =A0 I don't know whether it is portable, though. =A0Documentation of > =A0 libtool mentioned that not all loaders are able to act upon this > =A0 `advice'. > > Aside from portability, there is also coherence in design to consider. > In (info "(libtool) Libltdl interface") i see seven funcs that take > =91lt_dladvise *ADVISE=92: > > =A0lt_dladvise_init > =A0lt_dladvise_destroy > =A0lt_dladvise_ext > =A0lt_dladvise_global > =A0lt_dladvise_local > =A0lt_dladvise_resident > =A0lt_dladvise_preload > > The first two manage the object; the last five mutate its internals. > > Your proposal sequences =91lt_dladvise_ext=92 and =91lt_dladvise_global= =92 > with =91lt_dlopenadvise=92, essentially. =A0This is fine for your needs > today, no doubt. =A0How about further on, when you need _resident > or _preload, or _FOO (in some future libtool release), or when you > want _global but not _ext? > > With five bits, you have 32 combinations (actually less, as not all > combinations are meaningful, e.g., _global and _local together). =A0It > would be awkward to eventually find all these combinations wrapped > individually, in C and exposed to Scheme. =A0What is a better way? Yes, I addmit this is a quick hack to the problem at hand. And your consideration is absolutely right. Firstly, I think this feature is essential to a more useful dynamic FFI. A shared library may require another shared library to actually run some function, for example in the case of libgsl and libgslcblas. It is annoying to link them into one object before I can use the library. This patch is just a proof of idea or a working hack. I really hope this can serve as an inspriation to someone more familiar with guile's design, and this functionality will someday be incorprated in guile in a better way. At the moment, I can write and live with a extension module doing the job. Back to the design, the original `dynamic-link' is just equivalent to calling only `lt_dladvise_ext' and leave other "advise" unspecified or platform dependent. Maybe we can add some optional argument to specify those "advise". Some test maybe needed to see whether the loader act upon these "advise", either during configuration or dynamically. . --=20 Cong Gu