Re: Library packaging and missing .a file

> so basically it should provide only a -dev package. Is it ok to > package only -dev, or is it agains policies? https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". T

Re: Library packaging and missing .a file

On Fri, Apr 25, 2014 at 08:57:48AM +0200, Christian Kastner wrote: > > I have got another problem. Libstrophe only provides .a file, no .so, > > so basically it should provide only a -dev package. Is it ok to > > package only -dev, or is it agains policies? > > Not that I'm aware of, but I very mu

Re: Library packaging and missing .a file

On 2014-04-25 07:58, Dariusz Dwornikowski wrote: >> On 24.04.14 10:23:23, Christian Kastner wrote: > I have got another problem. Libstrophe only provides .a file, no .so, > so basically it should provide only a -dev package. Is it ok to > package only -dev, or is it agains policies? Not that I'm a

Re: Library packaging and missing .a file

>On 24.04.14 10:23:23, Christian Kastner wrote: > > It is sufficient to change these to eg: > >usr/lib/*/lib*.a Thanks for this. I have got another problem. Libstrophe only provides .a file, no .so, so basically it should provide only a -dev package. Is it ok to package only -dev, or is it

Re: Library packaging and missing .a file

On 2014-04-24 08:16, Dariusz Dwornikowski wrote: > dh_install: libstrophe-dev missing files (usr/lib/lib*.a), aborting > > The libstrophe.a file is installed into /usr/lib/x86_64-linux-gnu, > instead of /usr/lib. When should the .a file be installed into > /usr/lib and when into x86... ? The new

Library packaging and missing .a file

Hi, I am packaging libstrophe XMPP library in order to introduce www.profanity.im to Debian. make[2]: Entering directory `/home/tdi/dev/libstrophe-0.8.4' /bin/mkdir -p '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu' /usr/bin/install -c -m 644 libstrophe.a '/home/tdi/dev

Re: shared library packaging

Heyho! On Thursday 05 August 2010 21.57:06 Michael Tautschnig wrote: > Current dpkg (versions in testing and unstable) has a > version of dpkg-gensymbols that supports symbol tags, including the "c++" > tag. Ah. Yes, RTFM, but the dpkg-gensymbols manpage is refeerence documentation and not easy

Re: shared library packaging

[...] (Adrian would like to be CC'ed) > > I'd be very happy for a few hints on how to manage the package. I know > I should watch for changes to the symbols, but I'm not quite sure how to > manage the symbol files. Looking at the buildd logs, I can see that > there are quite a few ABIs (I gu

shared library packaging

Heyho! [cc:s welcome, thank you.] I was recently made aware that my management of webkitkde / libkwerbkit1 was quite a mess. I've now tried to get the package in better shape (0.9.6svn1158036-2) by adding symbol files and renaming the library package back so the library package matches the so

Re: Shared library packaging question

rsioning scheme. Scrap it, and bash the upstream with the libtool manual. It is usually a good sign that either he has not read the manual thoroughly, or he has not understood it, or both." (Debian Library Packaging guide) > Regarding the dev packages: Of course I will keep the > deve

RE: Shared library packaging question

Thank you, Stanislav, for your helpful explanations. Regarding the name of the package: For many years the upstream project has been called "lmfit" (since the main application is curve fitting), but the shared library has been called "lmmin.so" (since the fundamental mathematical operation is mini

Re: Shared library packaging question

On Sat, Mar 27, 2010 at 06:57:03PM +0100, Wuttke, Joachim wrote: > One more question (which possibly elucidates my previous questions): > > The upstream project is structured as follows: > > lmfit/configure.ac > lmfit/Makefile.am > # ... and all the resulting autotools stuff > > lmfit/lib/ # con

Re: Shared library packaging question

On Sat, Mar 27, 2010 at 06:35:42PM +0100, Wuttke, Joachim wrote: > Dear specialists, > > I need more help. Specifically, I am going to ask 3 questions. > > My debian directory is still messed up, as it has been from the beginning: > either the automatic scripts are not ready to assist in generat

RE: Shared library packaging question

One more question (which possibly elucidates my previous questions): The upstream project is structured as follows: lmfit/configure.ac lmfit/Makefile.am # ... and all the resulting autotools stuff lmfit/lib/ # contains library sources and the include file lmmin.h lmfit/demo/ # contains applicat

Shared library packaging question

Dear specialists, I need more help. Specifically, I am going to ask 3 questions. My debian directory is still messed up, as it has been from the beginning: either the automatic scripts are not ready to assist in generating a shared-library package, or I used them in wrong way. Here my control

Re: Need advices library packaging.

. Is there a guide process, like packaging binary file, for library packaging ? 2009/3/17 S'orlok Reaves > > > > Hello, > Assuming that you have double-checked that you are reading to package > axis2c, the new maintainer's guide is a very good place to begin: > h

Re: Need advices library packaging.

7;s probably already had that same error. Good luck, -->Seth --- On Tue, 3/17/09, Anthony Gasperin wrote: > From: Anthony Gasperin > Subject: Need advices library packaging. > To: debian-mentors@lists.debian.org > Date: Tuesday, March 17, 2009, 9:40 AM > Hi everybody, >

Re: Need advices library packaging.

On Tue, Mar 17, 2009 at 10:40 PM, Anthony Gasperin wrote: > My problem is that I do not know how to process with library packaging, > I am wondering if somebody would know where I could find relative > documentation. http://packages.debian.org/libpkg-guide http://www.netfort.gr.j

Need advices library packaging.

Hi everybody, I'm intended to package axis2c api, which is a set of api for implement soap service/client. My problem is that I do not know how to process with library packaging, I am wondering if somebody would know where I could find relative documentation. Thanks a lot !

Re: advise needed for library packaging

* Paul Wise [081229 01:01]: > I would suggest adding a .symbols file for the new ABI so you can > detect ABI breakage in newer upstream versions. s/so you can detect/so dpkg-gensymbols can warn in case of some easy to detect / Before someone thinks that a symbols file suffices to check for ABI b

Re: advise needed for library packaging

On Tue, 30 Dec 2008 16:30:28 +0200 George Danchev wrote: > > "some sort of API version discriminator" doesn't sound as if you've > > understood SONAME transitions. > > ... or you better understand [1] that you should avoid keeping SONAME > artifacts in the -dev package names, thus avoid changin

Re: advise needed for library packaging

On Tuesday 30 December 2008 00:07:34 Neil Williams wrote: > On Mon, 29 Dec 2008 22:12:24 +0200 > > George Danchev wrote: > > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html > > > http://bugs.debian.org/libpkg-guide > > > > > > Firstly, do you need that library? Nothing in

Re: advise needed for library packaging

On Tuesday 30 December 2008 04:04:55 Paul Wise wrote: > On Tue, Dec 30, 2008 at 5:12 AM, George Danchev wrote: > > Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort > > of API version discriminator ? > > Both of those are the same, I'm glad to read that. > my comment was

Re: advise needed for library packaging

On Tue, Dec 30, 2008 at 5:12 AM, George Danchev wrote: > Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort of > API version discriminator ? Both of those are the same, my comment was about libfooABI-API-dev vs libfoo-API-dev. -- bye, pabs http://wiki.debian.org/PaulWis

Re: advise needed for library packaging

On Mon, 29 Dec 2008 22:12:24 +0200 George Danchev wrote: > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html > > http://bugs.debian.org/libpkg-guide > > > > Firstly, do you need that library? Nothing in sid seems to depend on > > it, not even sleuthkit. > > Library package

Re: advise needed for library packaging

On Monday 29 December 2008 02:01:56 Paul Wise wrote: > On Sun, Dec 28, 2008 at 6:04 PM, Martin Godisch wrote: > > I'm not doing library packaging all day and I'm a bit unsure about the > > new sleuthkit upstream release. It would be nice if some of you could > >

Re: advise needed for library packaging

On Sun, Dec 28, 2008 at 6:04 PM, Martin Godisch wrote: > I'm not doing library packaging all day and I'm a bit unsure about the > new sleuthkit upstream release. It would be nice if some of you could > have a look at sleuthkit 3.0.0 here [1] and 2.0.5 in unstable and tell &g

Re: Library Packaging

On Sat, Oct 4, 2008 at 8:50 AM, Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote: > There is a guide covering some of the basic issues at > Unfortunately it doesn't yet cover using symbols files, for more info on that see thes

Re: Library Packaging

Hello, On Fri, 03 Oct 2008, Neil Williams wrote: > On Fri, 2008-10-03 at 16:16 -0400, Jonathan Steel wrote: > > I'm trying to create a package of a shared library and I can't figure > > out how to do it. I can do it for a normal binary using dh_make and > > debuild. Ive read through all the debi

Re: Library Packaging

On Fri, Oct 03, 2008 at 09:44:44PM +0100, Neil Williams wrote: > Generally, I don't recommend that anyone on this list seriously > considers packaging shared libraries until they have a couple of > ordinary binary packages in the archive. I would agree with that. Debian packaging is quite dauntin

Re: Library Packaging

On Fri, 2008-10-03 at 16:16 -0400, Jonathan Steel wrote: > Hi > > I'm trying to create a package of a shared library and I can't figure > out how to do it. I can do it for a normal binary using dh_make and > debuild. Ive read through all the debian packaging guides I can find. Shared libraries

Re: Library Packaging

On Fri, 03 Oct 2008 16:16:47 -0400, Jonathan Steel wrote: > Hi > > I'm trying to create a package of a shared library and I can't figure > out how to do it. I can do it for a normal binary using dh_make and > debuild. You already tried with "dh_make -l", right? -- . ''`. Debian maintainer

Library Packaging

Hi I'm trying to create a package of a shared library and I can't figure out how to do it. I can do it for a normal binary using dh_make and debuild. Ive read through all the debian packaging guides I can find. But there is a lack of info on how to do it for shared libraries. I end up with a

RE: library packaging problem

Hi, I have solved my problem of empty .debs in a library package: in the debian/rules file, I had to change the install command from $(MAKE) install prefix=$(CURDIR)/debian/tmp to read $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr so that dh_movefiles could move the files into debian//usr/

RE: library packaging problem

Hi, I have solved my problem of empty .debs in a library package: in the debian/rules file, I had to change the install command from $(MAKE) install prefix=$(CURDIR)/debian/tmp to read $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr so that dh_movefiles could move the files into debian//usr/

RE: library packaging problem

Below is the output of dpkg-buildpackage -rfakeroot. Perhaps anyone can see what went wrong? Thank you, Matthias ---OUTPUT BEGIN dpkg-buildpackage: source package is libulxmlrpcpp dpkg-buildpackage: source version is 1.4.5-1 dpkg-buildpackage: source maintainer is Matthias Zenk

RE: library packaging problem

gt; From: Laszlo 'GCS' Boszormenyi [mailto:[EMAIL PROTECTED] > Sent: Monday, August 23, 2004 8:41 PM > To: Zenker, Matthias (Otometrics Stuttgart) > Cc: debian-mentors@lists.debian.org > Subject: Re: library packaging problem > > > * [EMAIL PROTECTED] <[EMAIL PROTECTE

RE: library packaging problem

gt; From: Laszlo 'GCS' Boszormenyi [mailto:[EMAIL PROTECTED] > Sent: Monday, August 23, 2004 8:41 PM > To: Zenker, Matthias (Otometrics Stuttgart) > Cc: [EMAIL PROTECTED] > Subject: Re: library packaging problem > > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> > [2

Re: library packaging problem

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2004-08-23 18:16:20 +0200]: > Could anyone give me a hint where I have to look to find my (certainly > trivial) error? Can we look into the package's source? Without checking we have a hard time guessing. Regards, Laszlo/GCS

Re: library packaging problem

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2004-08-23 18:16:20 +0200]: > Could anyone give me a hint where I have to look to find my (certainly trivial) > error? Can we look into the package's source? Without checking we have a hard time guessing. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email t

library packaging problem

Hi, I am trying to package a library. This is my first package (yes, I know that it is depreciated for packaging newbies, but I need it in my job...). I have used upstream .tar.gz sources (they use autoconf and automake) and tried to follow the new maintainer's guide. The problem is that the d

library packaging problem

Hi, I am trying to package a library. This is my first package (yes, I know that it is depreciated for packaging newbies, but I need it in my job...). I have used upstream .tar.gz sources (they use autoconf and automake) and tried to follow the new maintainer's guide. The problem is that the d

Re: Library packaging

This one time, at band camp, Mark Brown wrote: >That's a first step but it is also possible for there to be incompatible >semantic changes which can't be detected in this fashion. This is true, but I'm not aiming to make the perfect tool -- I have strong instincts that the complete problem intract

Re: Library packaging

This one time, at band camp, Junichi Uekawa wrote: >There could, however, be changes in the source >which does affect. This is true, I feel there are many cases that are not easily tested; so I will _not_ be trying to make a universal soname checker, guaranteed to work 100%. >I don't know if ther

Re: updated library packaging FAQ

Hi Junichi, Hi all! After a first reading here are some commentss and some polishing. Perhaps this should also be aired on debian-doc for further checking of the language (I'm not perfect either..) On Mon, Mar 18, 2002 at 01:07:36AM +0900, Junichi Uekawa wrote: > [Traits of Debian] > > First, le

Re: Library packaging

This one time, at band camp, Mark Brown wrote: >That's a first step but it is also possible for there to be incompatible >semantic changes which can't be detected in this fashion. This is true, but I'm not aiming to make the perfect tool -- I have strong instincts that the complete problem intrac

Re: Library packaging

This one time, at band camp, Junichi Uekawa wrote: >There could, however, be changes in the source >which does affect. This is true, I feel there are many cases that are not easily tested; so I will _not_ be trying to make a universal soname checker, guaranteed to work 100%. >I don't know if the

Re: updated library packaging FAQ

Hi Junichi, Hi all! After a first reading here are some commentss and some polishing. Perhaps this should also be aired on debian-doc for further checking of the language (I'm not perfect either..) On Mon, Mar 18, 2002 at 01:07:36AM +0900, Junichi Uekawa wrote: > [Traits of Debian] > > First, l

updated library packaging FAQ(Re: Library packaging)

Junichi Uekawa <[EMAIL PROTECTED]> cum veritate scripsit: Well, now I updated the doc a little bit, I'll post it here. I've received exactly one response so far, and I'm feeling a bit naive about the contents of this document. Please comment: Library packaging Guide (very m

Re: Library packaging

On Mon, Mar 18, 2002 at 12:33:40AM +1100, Jamie Wilkinson wrote: > So, as I understand it, there's an _incompatible_ API change (and thus > requiring a SONAME change) when: > * function prototypes (incl names) that are exported are changed or obsoleted > * structs change or are obsoleted > I thi

Re: Library packaging

Jamie Wilkinson <[EMAIL PROTECTED]> cum veritate scripsit: > So, as I understand it, there's an _incompatible_ API change (and thus > requiring a SONAME change) when: > > * function prototypes (incl names) that are exported are changed or obsoleted > * structs change or are obsoleted > > I think

updated library packaging FAQ(Re: Library packaging)

Junichi Uekawa <[EMAIL PROTECTED]> cum veritate scripsit: Well, now I updated the doc a little bit, I'll post it here. I've received exactly one response so far, and I'm feeling a bit naive about the contents of this document. Please comment: Library packaging Guide (very m

Re: Library packaging

This one time, at band camp, Junichi Uekawa wrote: ># If anyone has a good tool, please tell me. Well, I'm thinking of a way to automate these checks, hence my question. So, as I understand it, there's an _incompatible_ API change (and thus requiring a SONAME change) when: * function prototypes

Re: Library packaging

On Mon, Mar 18, 2002 at 12:33:40AM +1100, Jamie Wilkinson wrote: > So, as I understand it, there's an _incompatible_ API change (and thus > requiring a SONAME change) when: > * function prototypes (incl names) that are exported are changed or obsoleted > * structs change or are obsoleted > I th

Re: Library packaging

Jamie Wilkinson <[EMAIL PROTECTED]> cum veritate scripsit: > >However, in the library sense, if it is binary-incompatible, > >it should have a new soname, i.e. 1.0.0 > > Are there ways to test libraries against other versions to check for a > binary incompatibility, or does it rely on a human rec

Re: Library packaging

Jamie Wilkinson <[EMAIL PROTECTED]> cum veritate scripsit: > So, as I understand it, there's an _incompatible_ API change (and thus > requiring a SONAME change) when: > > * function prototypes (incl names) that are exported are changed or obsoleted > * structs change or are obsoleted > > I thin

Re: Library packaging

This one time, at band camp, Junichi Uekawa wrote: ># If anyone has a good tool, please tell me. Well, I'm thinking of a way to automate these checks, hence my question. So, as I understand it, there's an _incompatible_ API change (and thus requiring a SONAME change) when: * function prototypes

Re: Library packaging

Jamie Wilkinson <[EMAIL PROTECTED]> cum veritate scripsit: > >However, in the library sense, if it is binary-incompatible, > >it should have a new soname, i.e. 1.0.0 > > Are there ways to test libraries against other versions to check for a > binary incompatibility, or does it rely on a human re

Re: Library packaging

This one time, at band camp, Junichi Uekawa wrote: >The upstream may "fix the package slightly" to make >binary-incompatible change to the library, and call it >0.3.0 (well, it's only natural). > >However, in the library sense, if it is binary-incompatible, >it should have a new soname, i.e. 1.0.0

Re: Library packaging

This one time, at band camp, Junichi Uekawa wrote: >The upstream may "fix the package slightly" to make >binary-incompatible change to the library, and call it >0.3.0 (well, it's only natural). > >However, in the library sense, if it is binary-incompatible, >it should have a new soname, i.e. 1.0.

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > > That sounds like a bad news, a potential sign of upstream changing > > binary interface between 0.1.0 and 0.2.0 > > I don't know... The upstream may "fix the package slightly" to make binary-incompatible change to the library, and c

Re: Library packaging

Junichi Uekawa: > That doesn't tell much. > objdump -p /usr/lib/libMowitz.so | grep SONAME er$ objdump -p /usr/lib/libMowitz.so | grep SONAME SONAME libMowitz.so.0 > That sounds like a bad news, a potential sign of upstream changing > binary interface between 0.1.0 and 0.2.0 I don't know

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > > That sounds like a bad news, a potential sign of upstream changing > > binary interface between 0.1.0 and 0.2.0 > > I don't know... The upstream may "fix the package slightly" to make binary-incompatible change to the library, and

Re: Library packaging

Junichi Uekawa: > That doesn't tell much. > objdump -p /usr/lib/libMowitz.so | grep SONAME er$ objdump -p /usr/lib/libMowitz.so | grep SONAME SONAME libMowitz.so.0 > That sounds like a bad news, a potential sign of upstream changing > binary interface between 0.1.0 and 0.2.0 I don't kno

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > $ ls -l /usr/lib/libMowitz.* > -rw-r--r--1 root root 400490 13 mar 18.42 /usr/lib/libMowitz.a > -rw-r--r--1 root root 717 13 mar 18.41 /usr/lib/libMowitz.la > lrwxrwxrwx1 root root 18 13 ma

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > $ ls -l /usr/lib/libMowitz.* > -rw-r--r--1 root root 400490 13 mar 18.42 /usr/lib/libMowitz.a > -rw-r--r--1 root root 717 13 mar 18.41 /usr/lib/libMowitz.la > lrwxrwxrwx1 root root 18 13 m

Re: Library packaging

Junichi Uekawa: > Are you sure of the soname version number? It is at least the version used in the files: $ ls -l /usr/lib/libMowitz.* -rw-r--r--1 root root 400490 13 mar 18.42 /usr/lib/libMowitz.a -rw-r--r--1 root root 717 13 mar 18.41 /usr/lib/libMowitz.la lrwxr

Re: Library packaging

Junichi Uekawa: > Are you sure of the soname version number? It is at least the version used in the files: $ ls -l /usr/lib/libMowitz.* -rw-r--r--1 root root 400490 13 mar 18.42 /usr/lib/libMowitz.a -rw-r--r--1 root root 717 13 mar 18.41 /usr/lib/libMowitz.la lrwx

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > > Binary package names are incorrect, name them "lib"mowitz0 and > > "lib"mowitz-dev > > Okay. I was a bit uncertain about that. I just used the names that > dh_make used. If that's the case, I also have doubts whether it should be ca

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > > Binary package names are incorrect, name them "lib"mowitz0 and > > "lib"mowitz-dev > > Okay. I was a bit uncertain about that. I just used the names that > dh_make used. If that's the case, I also have doubts whether it should be c

Re: Library packaging

Junichi Uekawa: > Without too much looking at, my first question is: why do you have > mowitz-config in diff.gz? It seems that it is not removed properly when doing a make distclean. I'll fix that. > Binary package names are incorrect, name them "lib"mowitz0 and > "lib"mowitz-dev Okay. I was a

Re: Library packaging

Junichi Uekawa: > Without too much looking at, my first question is: why do you have > mowitz-config in diff.gz? It seems that it is not removed properly when doing a make distclean. I'll fix that. > Binary package names are incorrect, name them "lib"mowitz0 and > "lib"mowitz-dev Okay. I was a

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > Could someone please have a look at the files that I put up at > http://www.softwolves.pp.se/tmp/mowitz/ and see if I have done it right > or not? Without too much looking at, my first question is: why do you have mowitz-config in diff.g

Library packaging

Hi! When upgrading Siag Office to its latest version I found that parts of the code had been broken out into a library. Since I have never before packaged a library I would appreciate some help to check whether I am doing things correctly or not. Could someone please have a look at the files that

Re: Library packaging

peter karlsson <[EMAIL PROTECTED]> cum veritate scripsit: > Could someone please have a look at the files that I put up at > http://www.softwolves.pp.se/tmp/mowitz/ and see if I have done it right > or not? Without too much looking at, my first question is: why do you have mowitz-config in diff.

Library packaging

Hi! When upgrading Siag Office to its latest version I found that parts of the code had been broken out into a library. Since I have never before packaged a library I would appreciate some help to check whether I am doing things correctly or not. Could someone please have a look at the files tha

Re: Library packaging

On Sun, Mar 04, 2001 at 11:39:46AM +1100, Sam Couter wrote: > > Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and > > you'll be fine. No symlinks are necessary I'd think. > > If the library is in some directory other than a normal library directory, > the full path will hav

Re: Library packaging

Josip Rodin <[EMAIL PROTECTED]> wrote: > > Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and > you'll be fine. No symlinks are necessary I'd think. More details are in order, I think. To use the library, you use a command line something like: LD_PRELOAD=libnjamd.so progr

Re: Library packaging

On Sun, Mar 04, 2001 at 11:39:46AM +1100, Sam Couter wrote: > > Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and > > you'll be fine. No symlinks are necessary I'd think. > > If the library is in some directory other than a normal library directory, > the full path will ha

Re: Library packaging

Josip Rodin <[EMAIL PROTECTED]> wrote: > > Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and > you'll be fine. No symlinks are necessary I'd think. More details are in order, I think. To use the library, you use a command line something like: LD_PRELOAD=libnjamd.so prog

Re: Library packaging

On Sat, Mar 03, 2001 at 07:56:39PM +0100, Josip Rodin wrote: > On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote: > > NJAMD works by being loaded with LD_PRELOAD. The normal package contains a > > shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and > > libnjamd.so),

Re: Library packaging

On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote: > NJAMD works by being loaded with LD_PRELOAD. The normal package contains a > shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and > libnjamd.so), just like most shared objects. Just put the file in a private direc

Re: Library packaging

On Sat, Mar 03, 2001 at 07:56:39PM +0100, Josip Rodin wrote: > On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote: > > NJAMD works by being loaded with LD_PRELOAD. The normal package contains a > > shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and > > libnjamd.so)

Re: Library packaging

On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote: > NJAMD works by being loaded with LD_PRELOAD. The normal package contains a > shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and > libnjamd.so), just like most shared objects. Just put the file in a private dire

Re: Library packaging

On Sat, 3 Mar 2001, Sam Couter wrote: > I tried to use the electric-fence and dmalloc packages as examples to > follow. Neither are named libwhatever, both contain shared objects. dmalloc > has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does > have a .so symlink, but it's

Library packaging

I'm a fairly new maintainer, and I have a few questions about packaging libraries. I'm trying to package NJAMD. It's a malloc debugging library, similar in some ways to ElectricFence or dmalloc. NJAMD works by being loaded with LD_PRELOAD. The normal package contains a shared object (libnjamd.so.

Re: Library packaging

On Sat, 3 Mar 2001, Sam Couter wrote: > I tried to use the electric-fence and dmalloc packages as examples to > follow. Neither are named libwhatever, both contain shared objects. dmalloc > has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does > have a .so symlink, but it'

Library packaging

I'm a fairly new maintainer, and I have a few questions about packaging libraries. I'm trying to package NJAMD. It's a malloc debugging library, similar in some ways to ElectricFence or dmalloc. NJAMD works by being loaded with LD_PRELOAD. The normal package contains a shared object (libnjamd.so

Re: library packaging howto?

On Fri, Jan 08, 1999 at 02:36:57PM -0800, Ben Gertzfield wrote: > Josip> Also, libblah1 goes to libs section, and -dev and -dbg into > Josip> devel section, right? If so, libfltk-dev is misplaced. > Josip> FWIW I'd like -devs in libs section. > > There isn't policy (unfortunately) but

Re: library packaging howto?

> "Josip" == Josip Rodin <[EMAIL PROTECTED]> writes: Ben> The short is: Ben> Ben> .so.1 and .so.1.0.0 go into libblah1 .so and .a and .h files Ben> go into libblah-dev (optional) debugging-enabled .a goes into Ben> libblah-dbg Ben> Ben> Your numbers may vary.

Re: library packaging howto?

> "Will" == Will Lowe <[EMAIL PROTECTED]> writes: Will> I've been around for a while, I have a couple of packages. Will> I'm about to undertake packaging my first set of libraries, Will> and I'm not sure what's different. I understand that a Will> stripped copy of the library

library packaging howto?

I've been around for a while, I have a couple of packages. I'm about to undertake packaging my first set of libraries, and I'm not sure what's different. I understand that a stripped copy of the library goes into the {package}lib.deb, and that a debugging-enabled copy (and header files) go in