From: Greg Troxel <gdt@ir.bbn.com>
Cc: guile-devel@gnu.org
Subject: Re: packaging the add-on libs...
Date: 10 Oct 2002 08:51:24 -0400 [thread overview]
Message-ID: <rmiptuisbhv.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: Rob Browning's message of "Thu, 10 Oct 2002 00:03:42 -0500"
Putting the guile version in the name makes sense to me, and I'd go so
far as to think about making libguile.a be libguile16.a. Given how
many things link to guile 1.4 (e.g. gnomeish stuff), it seems critical
to make it easy for package systems to install both guile14 and
guile16, and that therefore these must have totally disjoint sets of
files, with the possible exception of the guile-config link to
guile16-config. A nice guile.m4 to find the 'right' version might
also be an exception.
IIRC {Free,Net}BSD took this approach when packaging glib, so that
glib10 and glib12 could coexist. Now, glib-2.0 (which is to glib 1.2
as guile 1.6 is to 1.4, more or less, I think) has a different name:
> l /usr/pkg/lib/libglib*
-rw-r--r-- 1 root wheel 497840 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.a
-rwxr-xr-x 1 root wheel 774 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.la
lrwxr-xr-x 1 root wheel 18 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so -> libglib-2.0.so.0.1
lrwxr-xr-x 1 root wheel 18 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.1
-rwxr-xr-x 1 root wheel 430869 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so.0.1
-rw-r--r-- 1 root wheel 183560 Nov 21 2001 /usr/pkg/lib/libglib.a
-rwxr-xr-x 1 root wheel 733 Nov 21 2001 /usr/pkg/lib/libglib.la
lrwxr-xr-x 1 root wheel 16 Nov 21 2001 /usr/pkg/lib/libglib.so -> libglib.so.13.10
lrwxr-xr-x 1 root wheel 16 Nov 21 2001 /usr/pkg/lib/libglib.so.13 -> libglib.so.13.10
-rwxr-xr-x 1 root wheel 151468 Nov 21 2001 /usr/pkg/lib/libglib.so.13.10
It's kludgy for packagers to add this, and causes extra differences,
where if guile itself does it, it is just the way the world is and
will be the same everywhere.
On the other hand, putting all the dependent libs in
$(prefix)/libexec/guile/1.6/ also seems quite sensible to me, as long
as they are dlopened with an absolute path and no one is asked to put
this in LD_LIBRARY_PATH :-) Following the path of the P crowd seems
somewhat sensible, especially if there hasn't been large amounts of
pain from that approach.
But this still leaves the issue of libguile.a, which currently would
collide on my NetBSD system if I had 1.4 and 1.6 in the same prefix.
It is necessary to have both installed for compiling with, not just
running, since people need to be able to build programs from source
that link against older guile versions.
Greg Troxel <gdt@ir.bbn.com>
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-10-10 12:51 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
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 [this message]
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=rmiptuisbhv.fsf@fnord.ir.bbn.com \
--to=gdt@ir.bbn.com \
--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).