guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Better support for transition to guile-1.6


From: Marius Vollmer
Subject: Re: Better support for transition to guile-1.6
Date: 21 Nov 2001 20:36:51 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Rob Browning <address@hidden> writes:

> >> If so, would libfoo4 be provided via a symlink, or what?  We'll still
> >> need the plain old libfoo.so.4... around, otherwise direct C linking
> >> won't work right,
> >
> > Yes, that would be the compromise until dynamic-link understands
> > versions.  I don't think symlinks will work right since it might trick
> > the dynamic linker to load a library twice, under its two names.
> 
> But we'd have the same problem if we provided the lib twice under two
> names, wouldn't we?  It seemed to me that a symlink was more likely to
> prevent duplicate loads.  If ldso is smart, it should probably be
> using the resolved inode number anyhow.

Yes, _if_ it is smart.  Some time ago GNU/Linux ld.so was not smart
enough and I had mysterious failures with guile-gtk due to libguilegtk
being loaded more than once.

> As an interim measure, do you think we could go ahead and adopt the
> interface we eventually want, say (dynamic-link "libfoo" 4), and then
> implement some logic ourselves in dynl.c?

Hmm, I shortly thought about that myself, but in the end I wouldn't
fell comfortable to add an interface to a non-existing feature.  We
don't know yet how the new feature will look in detail, so we might
specify a wrong interface and nothing would have been gained.

But, of course, if you are sure about what will happen, that would be
good and we can implement the interface nevertheless.  Actually,
making it only work on GNU/Linux might be good enough for a start...

> That and a little bit of documentation telling people how they have
> to set up their symlinks (or whatever) might allow us to let people
> start writing code that they won't have to change later.  I can
> provide an implementation of the libtool versioning logic -- I
> believe we already have one in gnucash in the gnc-module code.  If
> not, it should be easy to translate.

Wouldn't two different versions of a shared library need two different
".la" files?  Additionally, wouldn't we need to have a way to specify
interface versions to the command line linker as well?

Hmm, this all seems to be taken care of by making the version part of
the library name.  This wouldn't probably be as sophisticated as
libtools scheme with interface ages, etc, however.

(Sometimes I think the libtool approach is noble but impossible hard.
Instead of trying to unifying all existing shared library systems, it
might have been better to just define one, sane, shared library system
and provide a portable implementation of it.  If that requires
replacing the OS native dynamic linker, so what?)



reply via email to

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