Bug#123887: Evms-devel] EVMS: shared libraries with unversioned sonames
On Wed, Jan 02, 2002 at 08:32:28AM -0600, Kevin Corry wrote:
> On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote:
> > I would recommend libevms-0.2.4.so, as you said above, over the current
> > libevms.0.2.4.so, since many other programs use that convention.
>
> I have tried changing the soname to the version-specific name, and
> everything seems to work. The only problem I see now is that the user must
> run "ldconfig" after installing, because the user-interfaces are linked
> against "evms", and not against the specific version of evms. But this
> really shouldn't be a problem. It also means we probably don't need to
> explicitly create the sym-link on "make install", since "ldconfig" will do
> that. Could the "ldconfig" call be added to the top-level Makefile
> "install" target?
Anything linking against the library must be linked against the versioned
name, so that the library doesn't change on them unexpectedly.
For example:
libsnmp-0.4.2.so => /usr/lib/libsnmp-0.4.2.so (0x4001f000)
is correct, and:
libevms.so => /usr/lib/libevms.so (0x40027000)
is not. After changing the soname, if you re-link the executables against
the new library, it should embed the versioned name in the executable so
that it looks more like:
libevms-0.2.4.so => /usr/lib/libevms-0.2.4.so (0x40027000)
> If you are interested in creating an automake/libtool setup, give it a try
> and I will look it over and see if we can include it in the future.
OK, will do.
> > > Currently the dlist package doesn't have any version number, but I'm sure
> > > we can come up with one if it makes things easier. I will try to do that
> > > tomorrow.
> >
> > Since libdlist is so small (and not subject to a lot of revision), you
> > might just want to statically link it and avoid the issue altogether.
>
> I suppose that would be possible. But wouldn't that just bloat the size of
> the engine core and plugin libraries?
It would sacrifice a little bit of bloat (libdlist.so on my i386 system is
about 10k) for not having to worry about shared library management for this
library. If you want to just keep the versioning in sync with the other
library, that should work, too, or you can have a completely separate
versioning scheme (in which case libdlist will need to go in a separate
binary package).
> > By the way, dlist.h defines a type dlist_t, and as I understand it,
> > types ending with the "_t" suffix are reserved by POSIX.
>
> Is that going to be a huge problem? Changing that is going to entail a lot
> of searching-and-replacing in the code. And evms has other data structures
> with similar naming-schemes (see engine/include/enginestructs.h). Are
> those a problem as well?
It isn't causing any immediate problems for me, so unless POSIX decides to
define a type dlist_t and it is widely implemented, it should be safe for
now. It's just a standards conformance/cosmetic type of issue.
> > > [man pages for LvmUtils]
> >
> > I can certainly do that; for the most part, it should just be a matter
> > of copying the corresponding LVM man pages and noting differences in
> > behaviour, right?
>
> Pretty much. Those utilities are meant to model the ones from LVM. All of
> the options should be the same, except some of the options are ignored in
> EVMS, either because they aren't implemented yet or aren't pertinent. If
> you glance through the code in engine/UserInterfaces/LvmUtils, each source
> file has a function called parse_options() that should give you an idea of
> which options are ignored in EVMS.
I will spend some time on this after I have a satisfactory set of initial
packages. One other thing, should I change the terminology in the man pages
to use the EVMS terms, since that is what the commands actually do, or leave
them with the LVM terms, since they correspond to the commands?
> I've applied your Makefiles patch, and everything seems to work fine. Only
> one other question: In the top-level make.rules, we have some #defines
> that are based on configuration options (notably PluginDirectory). This is
> set so the core engine will know which directory to look in to find the
> plugin libraries. Does the DESTDIR construct affect this define? In other
> words, should the PluginDirectory define be prepended with DESTDIR as
> well? My guess is no, based on your quote above, which implies that
> DESTDIR is kind of a temporary location.
You are correct that those variables should not reference DESTDIR. This is
precisely the difference between DESTDIR and modifying the prefix variables;
it just specifies where to place the files for installation, not the
location from where they will actually be executed.
> > Is the idea to get the latest aclocal.m4, which has the latest list of
> > plugin subdirectories? If so, another method would be to have a Makefile
> > rule for building configure which depends on aclocal.m4, something like:
> >
> > configure: configure.in aclocal.m4
> > autoconf
> >
> > (this is what automake does by default)
>
> Ok. So the idea would be just to run "make configure" instead of explicitly
> calling "autoconf"?
Yes. The automake stuff does a pretty good job of this, and it gets pretty
complex with all of autoconf's dependencies and re-generating individual
makefiles. I'll prepare an experimental automake patch so you can decide if
you want to go that way.
--
- mdz
Reply to: