On Sun, Jun 3, 2012 at 11:15 PM, Thien-Thi Nguyen <t...@gnuvola.org> wrote: > () cong gu <gucong43...@gmail.com> > () Sun, 3 Jun 2012 17:04:29 -0500 > > I found libtool offers a way to make a shared library globally > available. So I wrote a patch that provides `dynamic-link-global'. > A call like `(dynamic-link-global "libgslcblas")' should make > things work. > > I don't know whether it is portable, though. Documentation of > libtool mentioned that not all loaders are able to act upon this > `advice'. > > Aside from portability, there is also coherence in design to consider. > In (info "(libtool) Libltdl interface") i see seven funcs that take > ‘lt_dladvise *ADVISE’: > > lt_dladvise_init > lt_dladvise_destroy > lt_dladvise_ext > lt_dladvise_global > lt_dladvise_local > lt_dladvise_resident > lt_dladvise_preload > > The first two manage the object; the last five mutate its internals. > > Your proposal sequences ‘lt_dladvise_ext’ and ‘lt_dladvise_global’ > with ‘lt_dlopenadvise’, essentially. This is fine for your needs > today, no doubt. How 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). It > would be awkward to eventually find all these combinations wrapped > individually, in C and exposed to Scheme. What 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. . -- Cong Gu