Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote:
> 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.
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?
I have also switched the library file name to libevms-x.y.z.so from
libevms.x.y.z.so.
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.
> > 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?
> 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?
> > 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?
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.
Hopefully the only noticable difference to the users are just the verbose
messages, which are obviously going to be different than in LVM. Also, in the
EVMS tools, the "-v" and "-d" options both control the level of logging in
the engine.
> > > - 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>
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.
> > 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)
Ok. So the idea would be just to run "make configure" instead of explicitly
calling "autoconf"?
-Kevin
Reply to: