Re: packaging the add-on libs...

[tomas]

On Fri, Oct 11, 2002 at 10:59:53AM -0500, Rob Browning wrote:
> address@hidden writes:
> 
> > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
> > then and still feel uneasy abut it (see below).
> 
> Well FWIW, I did some experimentation [...]

[enlightening example snipped]

I totally agree with you in that this double linkage leads to undefined
behaviour (different from system to system and probably not explicitly
documented on most systems, so that e.g. ld-linux.so might feel free to
change its behaviour some day without saying so). It's most undesirable,
so I think the ideas you posted elsewhere (checking the lib version I'm
linked against to catch this case) are definitely worth a try.

[...]

> The main problem with this is that any apps or libs linked against
> these "add-on" libs will have to do something special to access the
> libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc.

That was more or less what I was pleading for: in the cases we can
(that is: for what can be considered a guile ``plugin''), do it --
in the cases we can't (that is: ``standard system libs''), well,
don't -- just use system standard searching and loading mechanism.
That imposes the burden of differentiating plugins from simple
libraries (in a way less elegant). But it buys us something.

>                                                    and as we've
> discussed, there are some definite issues with doing that portably,
> and in a way that doesn't have the potential to interact badly with
> other libs that might do the same thing, so we'd have to be cautious
> when considering this approach.  For libs no-one's ever allowed to
> link directly to, there's no problem.

You have more experience with those issues than me, so I'm ready to
shut up, having made enough noise already ;-)

Regards
-- tomas