[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Thread Plug-in Support #2
From: |
Rob Browning |
Subject: |
Re: [PATCH] Thread Plug-in Support #2 |
Date: |
14 Apr 2001 16:51:51 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
Marius Vollmer <address@hidden> writes:
> In what way is it a problem that we have a lot of libraries in
> /usr/lib?
And bear in mind that given that our search method respects
LD_LIBRARY_PATH, you can always choose an alternate location (or
locations) with a suitable choice of -rpath or setting for
LD_LIBRARY_PATH. For example, if Debian suddenly decrees that having
all the guile shared libs in /usr/lib directly is "forthwith too much
clutter", then I can always fix up the guile build process for the
Debian packages to put these libs in /usr/lib/guile/ and find them
there, or maybe even /usr/lib/guile/VERSION/ if we use -rpath...
Whatever we do, we should maintain the ability to *safely* have two
versions of guile installed with the same --prefix (plus or minus some
doc and binary renaming -- which Debian handles via
update-alternatives and symlinks). This is one reason we need to be
careful about shared library versioning/naming/placement.
And while the libltdl solution may not be optimal, I'm tending to
agree that sticking with the ldso/libtool model is probably best
until/unless we're sure about something else, though we'll still
probably need some libtldl enhancements.
> The Unix/C model of libraries might be broken, but I'd say that we
> only make it worse when we try to fight it. The bla-config utilities
> (like gnome-config, guile-config, etc), convenient as they might seem,
> are already on the verge of doing too much, and being too clever. For
> example, on one box, I have libgtk in /usr/lib and libguile in ~/lib.
> In a program that uses both, I get a linker line like
>
> ... -L/usr/lib -lgtk ... -L/home/mvo/lib -lguile ...
>
> This breaks because there is also a (old) libguile in /usr/lib.
It breaks in other cases too. I had to do something ugly like:
$(gnome-config foo | grep -v BAR)
the other day in a build script because gnome was insisting on some -W
options that conflicted with what I needed for my app itself :<
> I'm all for improving the Unix way of managing software components,
> but I think we need to do this by changing the build tools like the
> compiler itself, if we want to do it right. IMO.
Agreed. It would be really nice if we could figure out some general
improvements that help everyone. I think the foo-config scripts are
in many ways better than what we had before, but there are still
things that seem to need fixing.
--
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930
- Re: [PATCH] Thread Plug-in Support #2, (continued)
- Re: [PATCH] Thread Plug-in Support #2, NIIBE Yutaka, 2001/04/13
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/14
- Re: [PATCH] Thread Plug-in Support #2, NIIBE Yutaka, 2001/04/14
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/14
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/15
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/15
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/18
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/15
- Re: [PATCH] Thread Plug-in Support #2,
Rob Browning <=
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/13
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/13
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/13
Re: [PATCH] Thread Plug-in Support #2, Dirk Herrmann, 2001/04/12