[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release-critical Bugreport for December 7, 1998

In article <13934.16884.705984.829779@bolero>, Matthias Klose <doko@cs.tu-berlin.de> writes:
> Nice to see some discussion on how to build shared libs ...

Always happy to share what I've learned...

> Adam Di Carlo writes:
>> In article <19981208222718.B18101@gate.cks.com>, David Welton <davidw@gate.cks.com> writes:
>> My jade package ships two binary packages (jade, sp) which depend on
>> libsp1; there's libsp1-dev to boot.  See the rules file for the source
>> package, but what I do in a nutshell is (from build-arch rule):
>> echo "libsp1:ShlibVersion=libsp1 (>= $(SHLIBS_PKGVER))" \
>> >> debian/substvars

> Nice. Although the lines are doubled if you run the binary target
> twice (And the variable name could be something like libsp1:Dependency).

Well, see the debian/rules file.  Prior to the quoted line I used the
rather idiomatic:

	: > debian/substvars

> Perhaps a dh_substvars command would be helpful which replaces an
> already existing variable name.

Perhaps... *shrug*.  I don't really see what dh_* would buy here...

>> ...
>> echo "libsp      1 libsp1 (>= $(SHLIBS_PKGVER))" > debian/shlibs.local
>> echo "libgrove   1 libsp1 (>= $(SHLIBS_PKGVER))" >> debian/shlibs.local
>> echo "libspgrove 1 libsp1 (>= $(SHLIBS_PKGVER))" >> debian/shlibs.local
>> echo "libstyle   1 libsp1 (>= $(SHLIBS_PKGVER))" >> debian/shlibs.local

> That's overworked. You already have the dependency in the control
> file. echo "libsp 1" > debian/shlibs.local is enough to ignore the
> dependency that dpkg-shlibdeps finds.

Um, it is required that I ship a shlibs file with a shlibs providing
package.  This file serves that purpose.  Below the quoted lines you find:

	$(install_file) debian/shlibs.local $(prefix-libsp1)/DEBIAN/shlibs

>> ...
>> LD_LIBRARY_PATH=$(prefix-libsp1)/usr/lib			\
>> LD_PRELOAD=							\
>> dpkg-shlibdeps -pshlibs-sp $(bindir-sp)/*

> Should be noted that $(prefix-libsp1) is an absolute path, else
> dpkg-shlibdeps won't recognize the ldd output.

Um... Hmm.. actually it's not.  In that case I would have said:

	LD_LIBRARY_PATH=$(SRCDIR)/$(prefix-libsp1)/usr/lib ...

However, instead, the whole thing (which I should have disclosed
before) is:

	cd $(prefix-libsp1)/usr/lib && LD_LIBRARY_PATH=.		\
	  LD_PRELOAD=							\
	  dpkg-shlibdeps -pshlibs-libsp1 -O lib*.so.*.*		 	\
	  >> $(SRCDIR)/debian/substvars

> To simplify this: Would it be wrong, if the debhelper dh_shlibdeps
> searches for shared libs and sets the LD_LIBRARY_PATH itself?

Eh... I dunno.  I think dh_makeshlibs already does do some of this.
In the bugs section of dh_makeshlibs:

       This is a "do what I Mean" type program -  you  have  been

> Why is the LD_PRELOAD needed?

Um, it's not any more.  That was working around fakeroot when it would
double-entering libc6 in the depends line.  I don't think it's needed
anymore but it doesn't hurt. ;)

> And it's pretty critical that this isn't described anywhere. I don't
> want to know how many shared libs are not correctly built ...
> Where does the documentation belong to? In the packaging manual?

Yes.  There is documentation there; I agree the documentation isn't as
strong as it should be.  This is complex stuff though.  Perhaps you
could go over it and submit a diff to the SGML as a bug against the

.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Reply to: