From: tomas@fabula.de
Cc: tomas@fabula.de, guile-devel@gnu.org
Subject: Re: packaging the add-on libs...
Date: Mon, 14 Oct 2002 13:34:45 +0200 [thread overview]
Message-ID: <20021014113445.GA26258@www> (raw)
In-Reply-To: <87zntl0xvq.fsf@raven.i.defaultvalue.org>
On Fri, Oct 11, 2002 at 10:59:53AM -0500, Rob Browning wrote:
> tomas@fabula.de 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
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-10-14 11:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-10 5:03 packaging the add-on libs Rob Browning
2002-10-10 7:12 ` tomas
2002-10-10 15:22 ` Rob Browning
2002-10-11 9:41 ` tomas
2002-10-11 15:59 ` Rob Browning
2002-10-14 11:34 ` tomas [this message]
2002-10-11 16:14 ` Rob Browning
2002-10-11 17:10 ` Greg Troxel
2002-10-11 18:26 ` Rob Browning
2002-10-11 20:37 ` Greg Troxel
2002-10-10 12:51 ` Greg Troxel
2002-10-10 15:37 ` Rob Browning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021014113445.GA26258@www \
--to=tomas@fabula.de \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).