[Olsr-dev]solved but found new problems.. (Re: trying to set LIBDIR to /usr/lib/olsrd/)

[Holger Levsen]

Hi,

On Tuesday 08 July 2008 20:38, Bernd Petrovitsch wrote:
> > -Wl,-rpath,/home/holgi/Projects/olsr/collab-maint/build-area/olsrd-0.5.6~
> Ooops. Now we know where you work;-)

That info was in the strace file too and maybe even in some .debs... so 
usualyl when I upload I build them in pbuilder again :) 

> What you need and we want is a PREFIX (similar to the autotools).
> Yes, I remember a patch from the BSD folks.

Is that patch in or lost?

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

Right. 

> 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?

it works, but then lintian told me: "E: olsrd-plugins: shlib-with-non-pic-code 
usr/lib/olsrd/olsrd_httpinfo.so.0.1" which has this as an extended 
description:

"The listed shared libraries contain object code that was compiled 
without -fPIC. All object code in shared libraries should be recompiled 
separately from the static libraries with the -fPIC option. 
Another common mistake that causes this problem is linking with 
gcc -Wl,-shared instead of gcc -shared. 
In some cases, exceptions to this rule are warranted. If this is such a case, 
follow the procedure outlined in Policy and then please document the 
exception by adding a lintian override to this package. 
Refer to Policy Manual, section 10.2 for details. "


(I actually used make build_all, make install and make install_libs, since I 
want to install the plugins into a different debian binary package...)

> > "$(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 ...

See above. 

So for now, I'll resort to my patch to provide $pluginname and 
$pluginname_install targets. Because the above also has the problem that some 
unwanted plugins show up in the package. Of course I could rm them, but I 
have a working solution atm, so why bother.

> > 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 .......

Ic.


regards,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20080709/be685a89/attachment.sig>