aMule Forum
English => en_Bugs => Topic started by: Vollstrecker on May 12, 2009, 10:05:53 AM
-
Hi,
while building the pkg's, I get these warnings:
dpkg-shlibdeps: warning: dependency on libwx_baseu_net-2.8.so.0 could be avoided if "debian/amule-alcc/usr/bin/alcc" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if "debian/amule-alcc/usr/bin/alcc" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libX11.so.6 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libjpeg.so.62 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libpng12.so.0 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libfontconfig.so.1 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libXpm.so.4 could be avoided if "debian/amule-cas/usr/bin/cas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_gtk2u_adv-2.8.so.0 could be avoided if "debian/amule-alc/usr/bin/alc" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_baseu_net-2.8.so.0 could be avoided if "debian/amule-alc/usr/bin/alc" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if "debian/amule-alc/usr/bin/alc" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_gtk2u_adv-2.8.so.0 could be avoided if "debian/amule-wxcas/usr/bin/wxcas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if "debian/amule-wxcas/usr/bin/wxcas" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libthreadutil.so.2 could be avoided if "debian/amule/usr/bin/amule" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libthreadutil.so.2 could be avoided if "debian/amuleweb/usr/bin/amuleweb" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libthreadutil.so.2 could be avoided if "debian/amule-daemon/usr/bin/amuled" were not uselessly linked against it (they use none of its symbols).
Are these deps needed somewhwere else, or should I investigate that further in the build-process?
-
Dependency on libthreadutil is imported by libupnp, unused dependencies on cas are coming from libgd. See:
topi:~$ pkg-config --libs libupnp
-lupnp -lthreadutil -lixml
topi:~$ gdlib-config --libs
-lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm
topi:~$
These dependencies actually cannot be removed, only the warning, but I think it would cost more than what we'd gain. See, for example cas depends on libgd, and
topi:~$ dpkg -p libgd
Package: libgd
Priority: optional
Section: Libraries
Installed-Size: 508
Architecture: i386
Source: gd_2.0.33-1
Version: 2.0.33-1.9
Depends: bash, fontconfig (>= 2.3.95), freetype2 (>= 2.1.10), glibc (>= 2.4), libjpeg (>= 6b), libpng (>= 1.2.8), libx11 (>= 1.0.1), libxpm (>= 3.5.5), uhu-pkg, zlib (>= 1.2.3)
Size: 143574
... all the dependencies you were warned about are coming in again.
Dependecies on wx libraries: they could be removed, we just need another handful of `wx-config --libs xxxx` lines in the configure script, and the accompanying variables.
libpthread: the wx-config script emits '-pthread' for all '--libs' request if wxWidgets was compiled with threading support. The only way to get rid of it is to use a wxWidgets build without threading support for those binaries (alc, alcc, wxcas, amulecmd and amuleweb don't require threads)
Decide for yourself whether it worths the effort...
-
It should be possible, but there are more important things. I just thought they are set by hand.
-
It wasn't easy, but now I got it.
-
I'm not sure...
It seems to break darwin and netbsd... (and maybe something else, I'll have to test).
-
On which part? Is -lpthread needed on these platforms? I could add them later to the flags again, but I can't find anaything in the sources where symbols of it are needed. At least in the bins I chnaged. The other apps still get it over MULELDFLAGS.
-
MULELDFLAGS might contain things other than just -lpthread. The correct way would be to create a PTHREAD_FLAG separate from MULELDFLAGS, and then you can decide where to add an where not.
-
(and maybe something else, I'll have to test).
I did my homework. Removing dependent libraries from GDLIB_LIBS breaks linking on at least mingw32 (although other platforms may also be affected).
Btw, I found an elegant solution to your issue (THE solution, likely): setting LDFLAGS="-Wl,--as-needed" removes reference to unneeded libraries from the executable.
-
Seems to be THE solution. Do you add it? In 9870 I can only find it one time in changelog and nowhere else.
-
Seems to be THE solution. Do you add it? In 9870 I can only find it one time in changelog and nowhere else.
No, I won't add it as default, because
1. we would have to check if the linker supports it,
2. GNU binutils developers surely had their reason not to make it the default behaviour of ld.
Of course you're free to add it to the debian build (debian/rules maybe?), and I'll happily commit it if you decide to do so.
-
k, I tried and it didn't work. No effect at all. I could modify the patch, that it only removes the unneded flags on linux. Would that be commitable?
-
No effect at all.
I wouldn't say that. The patch below has pretty nice effects (tested on stable).
Index: debian/rules
===================================================================
--- debian/rules (revision 9872)
+++ debian/rules (working copy)
@@ -316,6 +316,7 @@
config.status: configure
dh_testdir
CFLAGS="$(CFLAGS)" dh_auto_configure -- --host=$(DEB_HOST_GNU_TYPE)\
+ LDFLAGS="-Wl,--as-needed ${LDFLAGS}"\
--enable-ccache\
--enable-geoip\
${AMULECMD}\
The only thing remaining is the warning about libpthread.so.0, and this is where things turn interesting. Actually everyone is wrong. We are wrong to link to it. dpkg-shlibdeps is wrong in saying that none of its symbols are used. Although dpkg-shlibdeps is right in that we shouldn't use it. Now I won't go into details (although I might if you're interested), I'll see later if I can find a nice way to resolve this issue.
-
I see my error. I configured as usual and gave the LDFLAGS to make. They appeared, but didn't work. But I'm very interested in the details.
Btw. Try MULELDFLAGS, this should move the statement far enough to the front to get -lpthread, too.
-
But I'm very interested in the details.
Here you are. As you might know, there are objects that has to be defined per-thread in a multithreaded program, e.g. errno (we don't want and error on one thread to propagate to the other). To stay with this example, __errno_location is exported by both libpthread and libc, first found is used. Thus, if you have -lphtread on the linker command line (linking a multithreaded program) __errno_location from libpthread.so.0 will be used.
That's why I said dpkg-shlibdeps is wrong in saying that none of its symbols are used, actually there are several symbols used from libpthread.so.0 if we use -lpthread, and that's why -Wl,--as-needed doesn't remove it. But it's also true that each of these symbols are also exported by libc, and we should use the libc ones is we aren't multithreaded.
As I said before, I'll address this issue later.