On 9/27/05, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
> 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?
Of course it must - how else can it load them ? With my patch it knows
about few default places and can be instructed about other places in
nice shemely way.
> This is wrong. The user knows it, the Scheme module that
> loads it knows it, but Guile itself doesn't care.
... and as a result the whole system does not work. Yeah - this is
exactly what I see.
In our real imperfect world neither module creater nor user care about
libraries placement so it's obvious that guile should do this, there
are noone else. Module creator does not care since it's not really
important for him/her (it should be somewhere where guile can find it
- no other preferences usually), user has even less reasons to care
(he's just a user - why should he care?) and when libguile does not
care as well the whole thing breaks down.
The real strange thing is that libguile actually *knows* about
it:"guile-config info pkglibdir" will print correct information (true
for both GUILE 1.6.x and GUILE 1.7.x).
-- cut --
$ /somewhere/there/bin/guile-config info pkglibdir
/somewhere/there/lib/guile
-- cut --
it just never actually uses this knowleadge.
> > 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.
This is one solution. And IMO not the best solution. If package DOES
HAVE pkglibdir (and GUILE has one - just check "guile-config info
pkglibdir" with GUILE 1.6.x and/or GUILE 1.7.x) then I should be able
to put my architecture-dependent file there without further dances!
> Note that `(ice-9 readline)' works around this by having the library
> name contain version information.
Are we on the same planet ? On my planet this:
-- cut --
$ /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"
-- cut --
means that "(ice-9 readline) does not work".
> > 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?
IETF principle: It's better to have working code today then perfect
code "sometime in the future". Let's handle existing use-cases now,
then think about perfection. GUILE exists for 8 eyars yet still
mishandle common cases. May be it's time to stop worrying about
perfection ?
> > 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*. When I configured GUILE I specified this info. If GUILE lost
it - it's not my problem.
> > 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.
>
Oh the infinite wisdom of RFC1925. Yes, "with sufficient thrust, pigs
fly just fine". But you forgot the next part: "However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead." Yes, it's possible to hack around GUILE's idiosyncrasies -
but I think my time will be better spent doing something else.
> The only thing (admittedly important!) that may not work, though, is
> other extension libraries, as we noted above.
>
And this is the problem I've started the thread with.
> > 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.
>
...and without offering adequate tools for peacefull coexistence of
few GUILE versions. Brilliant decision. Just brilliant.
And this bullshit about lack of manpower is just that. Bullshit. I've
coded working solution in half-hour. It does not handle everything
(libguilereadline still goes to /somewhere/there/lib/, not to
/somewhere/there/lib/guile/1.7), but it's easy enough to fix. TTN
proposed something similar more then year ago. Yet GUILE still does
not have working solution.
> 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).
>
This is what attracted me in first place, yes. Serious concerns about
binary-compatibility are great but if you are not offereing TOTAL
compatibility will ALL versions then you need some tool to keep few
versions around at the same time.
> 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.
>
Relative is operational word here.
> > 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?
>
Why should I ? I'm not univercity, science fund or Google to offer
sponsorship. I'm perfectly happy to offer what few hacks I've
developed/will develop for my own needs but if the only way to
acception is to create "perfect solution" then it's probably better to
try my luck elsewhere.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
