guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]