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