On Die, 2008-07-08 at 18:02 +0200, Holger Levsen wrote: 
> Hi,
> 
> On Tuesday 08 July 2008 12:42, Bernd Petrovitsch wrote:
> [...]
> > So the string is at least in there somewhere.
> 
> Yes, but as I see it wrongly:
> 
> gcc  -Wl,-export-dynamic  -Wl,-rpath,/home/holgi/Projects/olsr/collab-maint/build-area/olsrd-0.5.6~rc7/debian/olsrd/usr/lib/olsrd/

Ooops. Now we know where you work;-)

> And thats the problem :) And that me wonder why and then I found the reason:
> 
> In the build target in debian/rules I used "$(MAKE) 
> DESTDIR=$(CURDIR)/debian/olsrd" instead of the correct "$(MAKE)"...
> 
> IOW: DESTDIR only makes sense for the install target :) Gah :-D Thanks for 

Yes, like DESTDIR as used by the autotools: It should be used only at
`make install` time (and not `make build_all`).
What you need and we want is a PREFIX (similar to the autotools).
Yes, I remember a patch from the BSD folks.

> bringing me on the right track!

De nada.

> Unfortunatly this brown paper bug is also present in the etch package, though 
> it's not really doing harm there, as I stayed with the /usr/lib default 
> there.

Hmm, adding a file with /usr/lib/olsrd into /etc/ld.so.conf.d is
probably unwanted and doesn't make much sense.

> And here I thought I was done with this topic, but unfortunatly not. The next 
> problem is, that there are no seperated build and install targets for the 
> plugins in the (olsrd) Makefile, so to build and install them I call 

I don't understand: There is `make build_all` and `make install_all`.

Can't you just do `make build_all LIBDIR=/usr/lib/olsrd` and 
`make install_all DESTDIR=/some/where LIBDIR=/some/where/usr/lib/olsrd`
or a similar ugly hack?

> "$(MAKE) DESTDIR=$(CURDIR)/debian/olsrd-plugins $(PLUGINS) STRIP=:" in 
> debian/rules, and thus the plugins included my builddir in their rpath :-( I 
> solved this in my packaging by patching the olsrd Makefile to provide 
> ${pluginname}_install targets. Not sure if there is a better way.

In theory it should work as above (even if one ignores the install
target if it's unusable - which is the common handling if upstream
delivers e.g. not-cross-compile-friendly packages).
But I don't know enough about .deb building ...

	Bernd

> P.S.: I also saw this, you might or might not want to address 
> it: "dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided 
> if "debian/olsrd/usr/sbin/olsrd" were not uselessly linked against it (they 
> use none of its symbols)."

Some plugins (BMF, the others doesn't come to my mind ATM) use threads.
And there were some reports that they couldn't be loaded if olsrd
doesn't link against libpthread (even if the core doesn't use it).
And the core doesn't need it ATM and even if, there is no locking or
whatever .......

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




