On Wed, Jan 10, 2007 at 12:29:21AM -0500, Hubert Chan wrote:
Assuming that I want to publish some at least partially useful
packages (for a start, much of the use will be via python bindings
rather than linking against the .so) until upstream has committed to
an soname policy, and made a
On Thu, 11 Jan 2007 17:32:49 +, Dominic Hargreaves [EMAIL PROTECTED] said:
Actually I could use an soname of libmapnik.so.0d for now (idea from
Josselin Mouette's talk that I recently watched the video of :) which
I can increment to my heart's content until upstream makes a release
with
Justin Pryzby wrote:
On Tue, Jan 09, 2007 at 08:46:59AM +0100, Andreas Fester wrote:
Hi,
Junichi Uekawa wrote:
[Andreas]
so I suppose that the format libfoo-1.2.3.so only exists for historical
reasons, right? IMHO new packages have to use the form libfoo.so.1.2.3 ?
That's not quite
On (10/01/07 12:43), Kevin B. McCarty wrote:
I'm guessing that people who name libraries like libfoo-1.2.3.so often
tend to (lazily) use the software version number as the release number,
so they don't need to keep track of (or try to prevent) ABI
incompatibilities. Hence the soname changes
On Tue, Jan 09, 2007 at 08:46:59AM +0100, Andreas Fester wrote:
Hi,
Junichi Uekawa wrote:
Too, there are actually two forms of library soname file naming used:
libfoo.so.1.2.3
and
libfoo-1.2.3.so
Only the first one is mentioned in the various packaging guides,
hmmm ?
On Fri, Jan 05, 2007 at 01:25:56PM -0700, Hubert Chan wrote:
On Fri, 5 Jan 2007 17:56:17 +, Dominic Hargreaves [EMAIL PROTECTED]
said:
[...]
Mapnik consists of a C++ shared library with python bindings. Also
included are some .so plugins but I don't believe that they are
Hi,
Too, there are actually two forms of library soname file naming used:
libfoo.so.1.2.3
and
libfoo-1.2.3.so
Only the first one is mentioned in the various packaging guides,
hmmm ? excluding this?
Hi,
Junichi Uekawa wrote:
Too, there are actually two forms of library soname file naming used:
libfoo.so.1.2.3
and
libfoo-1.2.3.so
Only the first one is mentioned in the various packaging guides,
hmmm ? excluding this?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Justin Pryzby wrote:
./libgnomevfs-pthread.so
[...]
No. *.so are linker symlinks used at compiled time. The compile flags -lfoo
Not this one:
$ ls -la /usr/lib/libgnomevfs-pthread.so
- -rw-r--r-- 1 root root 34624 2005-09-02 01:53
On Sun, Jan 07, 2007 at 06:19:00PM +0100, Andreas Fester wrote:
Justin Pryzby wrote:
./libgnomevfs-pthread.so
[...]
No. *.so are linker symlinks used at compiled time. The compile flags
-lfoo
Not this one:
$ ls -la /usr/lib/libgnomevfs-pthread.so
- -rw-r--r-- 1 root root 34624
Hi,
I'm in the process of packaging Mapnik http://www.mapnik.org/ and find
myself in at the deep end trying to understand the way sonames and
libraries names work (in general and in Debian -- to date my involvement
has only been with binary-independent perl packages) and also how to
deal with
On Fri, 5 Jan 2007 17:56:17 +, Dominic Hargreaves [EMAIL PROTECTED] said:
[...]
Mapnik consists of a C++ shared library with python bindings. Also
included are some .so plugins but I don't believe that they are
problematic currently; they can simply reside in /usr/lib/mapnik/ .
Remember
On Fri, Jan 05, 2007 at 05:56:17PM +, Dominic Hargreaves wrote:
Hi,
Hi Dominic,
Inspection of /usr/lib on my system reveals around 50 nonsymlinks of the
form /usr/lib/*.so. Are these all bugs? eg:
./libdb-4.4.so
./liba52-0.7.4.so
./libdb-4.3.so
./libc.so
./libdb-4.1.so
13 matches
Mail list logo
