Hello,
Vorfeed Canal <[EMAIL PROTECTED]> writes:
> 1. Not really:
> A. They are usually useless for programs not linked to guile - and
> such programs will know where to find them anyway since libguile will
> know this.
Libguile knows where _any_ third party library (the shared object) gets
installed? This is wrong. The user knows it, the Scheme module that
loads it knows it, but Guile itself doesn't care.
> B. If program A is linked to libguile.so.12 (guile 1.6.7) while
> program B is linked to libguile.so.16 (guile 1.7.2) they'll need
> DIFFERENT versions of such libraries - and this is somewhat
> problematic with libtool.
This is true I guess, because `dynamic-link' doesn't allow to specify
version info. _This_ is an issue and maybe this procedure could be
fixed by allowing the user to pass Libtool-like version information.
Note that `(ice-9 readline)' works around this by having the library
name contain version information.
> C. While it's true "these libraries can do this and they can do
> that" in almost 100% cases today they just export some functions for
> scheme level.
Maybe. So what?
> 2. You can not install them "in the usual place" anyway:
>
> $ ./configure --prefix=/somewhere/there ; make ; make install
> $ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
> ERROR: In procedure dynamic-link:
> ERROR: file: "libguilereadline-v-16", message:
> "libguilereadline-v-16.so: cannot open shared object file: No such
> file or directory"
>
> Oops ?
That doesn't look so weird to me. The convention on Unix systems is
that you _have to_ specify at run-time a list of directories where
libraries may be searched for by the loader.
> I did not. Right now it's IMPOSSIBLE to install two versions of guile
> at all - let alone in the sane way
> (/usr/bin/guile-{1.6,1.7},/usr/lib/guile-{1.6,1.7},/usr/share/guile-{1.6,1.7}
Debian has two Guile packages that may be installed together alongside.
Guile itself would work fine. Even `(ice-9 readline)' will work fine
thanks to the workaround above.
The only thing (admittedly important!) that may not work, though, is
other extension libraries, as we noted above.
> so I can not see how guile development is done in first place (it's
> standard practice to have 3-4 different versions of program while it's
> in developmet and guile does not work this way at all - and even if
> you'll fix guile itself third-party extensions will not obey your
> decision).
This is true. The point is that there is apparently no sufficient
manpower to address all these issues. In particular, I guess the
current Guile developers work hard to improve Guile itself, at the
expense of breaking binary compatibility.
Note, however, that Guile 1.6 was compatible at the source-level with
Guile 1.4 (and people were greatly encourage to drop the `gh_'
interface), and Guile 1.7 is source-level compatible with Guile 1.6 (and
it also encourage users to migrate to the new API when relevant).
Apparently, the C API of Guile 1.7 was designed to me as much
``future-proof'' as possible, given the goals that can be envisioned
today. The internals are no longer exposed to the C user. I'm
confident in the relative stability of this API.
> I've tried it few years ago and back then it was not really usable:
> was not able to even work with 10GiB partition. Today... It does not
> even detect my SATA HDD in my NForce4-based system. May be I've used
> too old version, of course... or did something wrong. Plus AFAIK even
> today it's still "not recommended for production use" - after >10
> years of development and I'm not really interested in OS development
> (or for that matter GUILE development): I want something that WORKS.
> NOW. It's Ok if I need to spend some time with tuning/fixing, but not
> YEARS, sorry.
Why don't you sponsor a few developers, or even just a single one?
Thanks,
Ludovic.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
