Bug#123887: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Tue, Jan 01, 2002 at 09:57:40AM -0600, Kevin Corry wrote:
> On Monday 31 December 2001 19:23, Matt Zimmerman wrote:
> > - Shared library versioning
>
> I thought libevms did have a version number. There ought to be a
> libevms-0.2.4.so, with libevms.so as a link to the specific version. Is
> that not how it's set up on your system?
Currently, the default installation names the library libevms.0.2.4.so and
libevms.so is a symlink to that. However, the soname is libevms.so:
objdump -x /usr/lib/libevms.0.2.4.so | grep SONAME
objdump: /usr/lib/libevms.0.2.4.so: no symbols
SONAME libevms.so
And this is the name which is embedded in executables which are linked
against the library:
ldd =evms
libdl.so.2 => /lib/libdl.so.2 (0x4001f000)
libdlist.so => /usr/lib/libdlist.so (0x40023000)
libevms.so => /usr/lib/libevms.so (0x40027000)
libc.so.6 => /lib/libc.so.6 (0x40050000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
I believe what you want is the -soname linker option, but I normally use
libtool for this kind of thing. Since you don't have to worry about OS
portability, you can probably get away with calling ld directly, but could
easily put together a libtool setup for it (and automake as well) if you're
interested.
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.
> 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.
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.
> > - Manual pages
> >
> > Debian requires that every program have a manual page. This is not a
> > big deal; I will write the man pages if you don't have any.
>
> I believe we have someone working on some man pages. Currently I think
> they will just be for evms (command line) and evmsgui. I will check to see
> if we can write some man pages for the LVM-emulation utilities. If you'd
> like to take an initial shot at those, feel free.
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?
> > - Makefile stuff
> >
> > I modified the makefiles to support DESTDIR, and to remove the
> > autoconf clutter in 'clean' instead of 'distclean'. I can't run
> > 'distclean' from the package build scripts because it removes
> > 'configure'; I'm not sure why this is, since configure is part of the
> > distribution. My diff is attached.
>
> I guess I've never used the DESTDIR construct before. I assume that is
> just an externally set environment variable? I will patch in these changes
> to the Makefiles.
I believe it started as a GNU standard ( (standards)Command Variables ), but
it has become common in other circles as well.
<quote>
Optionally, you may prepend the value of `DESTDIR' to the target
filename. Doing this allows the installer to create a snapshot of the
installation to be copied onto the real target filesystem later. Do not
set the value of `DESTDIR' in your Makefile, and do not include it in
any installed files. With support for `DESTDIR', the above examples
become:
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
$(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
</quote>
> Because new plugins are still being written for the engine, we set up the
> Makefile to remove 'configure' on a 'make distclean'. This forces you to
> run 'autoconf' to regenerate 'configure' in the event new plugin or
> user-interface subdirectories were added to the engine. I suppose in the
> future, before releasing a package I should modify the Makefile to not
> delete 'configure' on 'make distclean', since the end-user will have no
> need for this functionality.
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)
In the definition used by the GNU standards, 'distclean' should remove
everything that is not included in the distribution. Using this name might
cause some confusion since it does something different in evms (I was
certainly surprised when I lost configure).
> There is an LVM-emulation utility called 'evms_pvremove' that should be
> used on unassigned PVs to remove them from the LVM region manager. It is
> basically the opposite of 'evms_pvcreate'. We are working on similar
> functionality for the GUI.
I see, thanks.
--
- mdz
Reply to: