Hi Arnaud, On Fri, Jan 25, 2008 at 04:50:48PM +0100, Arnaud Quette wrote: > would you be able to test the below 1 line patch?
> -libupsclient_la_LDFLAGS = -version-info 0:0:0 > +libupsclient_la_LDFLAGS = -version-info 0:0:0 -prefer-pic I did a quick test and judging from the build log, it does not change anything. Unfortunately, I don't have the time to do further changes right now and I did not find any documentation about the expected consequences from using this flag. Anyway, this does not sound like the right thing to do in the first place. I guess, I should have been somewhat more verbose when writing the bug report - sorry for that. One first thing to note: the Debian Policy requires static libraries to be built without -fPIC (which is supposed to perform better on some architectures as far as I understood it). Unfortunately, this makes the static libraries basically unusable for linking into shared objects (which obviously need to be relocatable). Some architectures (among them e.g. i386) seem to do some kind of strange magic to still make it possible but it fails on most other architectures. Imho, the best way to solve this would be to provide a shared library as well (which obviously has to be compiled with -fPIC, which is handled by libtool). However, this is explicitly disabled in debian/rules. What's the reason for that? Providing a static library only is usually done when the API is _very_ unstable. In all other cases a shared library should be preferred. As a side note: Please be aware that you, especially in the role of upstream, have to take special care of API changes and appropriate soname bumps then. The Debian Library Packaging guide ([1]) includes some rough guidelines about when to change sonames. If providing a shared library really does not make any sense, you could provide an _additional_ package with the static library build with -fPIC. Thus you need to compile the library twice. Have a look at lapack3-pic, libdiscover1-pic or similar as an example (please note that I did not have a look at any of those packages but I just did a quick "apt-cache search" - so I'm not saying that the above mentioned packages are particularly good examples). Please see the Debian Policy (section 10.2), the Debian Library Packaging guide, the additional info provided at [2] (section 5.f), the thread following [3] and possibly [4] for more details on this topic. HTH, Sebastian [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [2] http://release.debian.org/etch/rc_policy.txt [3] http://lists.debian.org/debian-devel/2001/08/msg01045.html [4] http://lists.debian.org/debian-devel/2001/08/msg01105.html -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
