On Sun, Jan 06, 2002 at 10:07:48PM +0100, Tollef Fog Heen wrote:
> ldconfig creates the necessary links and cache (for use by the run-
> time linker, ld.so) to the most recent shared libraries found in the
> directories specified on the command line, in the file
>
* Matt Zimmerman
| If portability is an issue, the software in question should be using libtool
| anyway, which takes care of this for you. If it will only ever work on
| GNU/Linux, ldconfig -n with an explanatory comment should be sufficient.
Example from where I've used ldconfig -n:
mklibs.p
On Sun, Jan 06, 2002 at 05:59:55PM +0100, Tollef Fog Heen wrote:
> * Marcus Brinkmann
>
> | Sure, evms seems only to be available on GNU/Linux, too. But just
> because | it happens to work by chance it is no excuse to do the wrong
> thing. People | might take it as an example and use it in the
* Marcus Brinkmann
| Sure, evms seems only to be available on GNU/Linux, too. But just because
| it happens to work by chance it is no excuse to do the wrong thing. People
| might take it as an example and use it in their own software, where it
| doesn't work (on GNU/Hurd, and other systems).
On Wed, Jan 02, 2002 at 11:55:52PM +0100, Tollef Fog Heen wrote:
> * Wichert Akkerman
>
> | Previously Kevin Corry wrote:
> | > Could the "ldconfig" call be added to the top-level Makefile "install"
> | > target?
> |
> | No, since you might not be installing on a real system but a temporary
> |
* Wichert Akkerman
| Previously Kevin Corry wrote:
| > Could the "ldconfig" call be added to the top-level Makefile "install"
| > target?
|
| No, since you might not be installing on a real system but a temporary
| location to build a package or for some other reason. Also if you
| are not runni
On Wed, Jan 02, 2002 at 04:00:21PM -0600, Kevin Corry wrote:
> On Wednesday 02 January 2002 14:35, Matt Zimmerman wrote:
> > 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 y
On Wednesday 02 January 2002 15:01, Matt Zimmerman wrote:
> On Wed, Jan 02, 2002 at 01:18:07PM -0600, Kevin Corry wrote:
> > Basically, we don't want to force the user-interfaces to to be
> > recompiled on every minor change to the engine core that doesn't change
> > any of the external APIs. We o
On Wednesday 02 January 2002 14:35, Matt Zimmerman wrote:
> On Wed, Jan 02, 2002 at 08:32:28AM -0600, Kevin Corry wrote:
> > 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.
Great!
>
On Wed, Jan 02, 2002 at 01:18:07PM -0600, Kevin Corry wrote:
> What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the
> filename for the library (where x is the version major number, y is minor,
> and z is patchlevel)? This seems to be common on many of the libraries on
> my syste
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 son
On Wednesday 02 January 2002 14:04, Adam Heath wrote:
> On Wed, 2 Jan 2002, Kevin Corry wrote:
> > What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the
> > filename for the library (where x is the version major number, y is
> > minor, and z is patchlevel)? This seems to be common
On Wed, 2 Jan 2002, Kevin Corry wrote:
> What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the
> filename for the library (where x is the version major number, y is minor,
> and z is patchlevel)? This seems to be common on many of the libraries on my
> system.
>
> Basically, we d
On Wednesday 02 January 2002 08:32, Kevin Corry wrote:
> 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/libevm
On Tuesday 01 January 2002 14:39, Matt Zimmerman wrote:
> > 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-interfa
Previously Kevin Corry wrote:
> Could the "ldconfig" call be added to the top-level Makefile "install"
> target?
No, since you might not be installing on a real system but a temporary
location to build a package or for some other reason. Also if you
are not running as root but with fakeroot ldconf
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
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
> t
On Monday 31 December 2001 19:23, Matt Zimmerman wrote:
> I have a set of packages which work for me, but a few things will need to
> be resolved before they can go into Debian proper.
>
> - Shared library versioning
>
> libevms and libdlist have sonames with no version number (libevms.so and
>
19 matches
Mail list logo
