[email protected] skrev: > Quoting David Henningsson <[email protected]>: > >> Bernat Arlandis i Mañó skrev: >>> dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided >>> if "debian/fluidsynth/usr/bin/fluidsynth" were not uselessly linked >>> against it (they use none of its symbols). >> >> Since "ldd fluidsynth" displays a dependency on libpthread this issue >> seems to be inherited from upstream. Is this a problem that can be fixed >> by editing the autotools files? Josh, perhaps you know how to fix that? > > I lack some knowledge in the area of shared libraries. I notice that > when running ldd on the fluidsynth executable, it comes up with a large > list of dependencies, which aren't actually used in the fluidsynth > application itself, but are instead dependencies of libfluidsynth. > Perhaps ldd is recursively listing the dependencies though?
These rows is what builds the fluidsynth executable: /bin/bash ../libtool --tag=CC --mode=link gcc -Wall -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -Wall -W -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wstrict-prototypes -Wno-unused -Winline -o fluidsynth fluidsynth-fluidsynth.o libfluidsynth.la -lpthread libtool: link: gcc -Wall -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -Wall -W -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wstrict-prototypes -Wno-unused -Winline -o .libs/fluidsynth fluidsynth-fluidsynth.o ./.libs/libfluidsynth.so /usr/lib/liblash.so -luuid -lreadline -lncurses -ljack /usr/lib/libasound.so -lm -ldl -lpulse-simple -lpulse /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -lpthread -pthread Do we need all these "-l":s above, and if we don't, how do we get rid of them? (Hmm, ticket #38 suddenly comes to mind...) > I'm fairly certain there aren't any issues with Ardour borrowed code. > The rest of FluidSynth should be fairly clean also. Like Bernat > mentioned, I think we should assume it is safe code (I'm fairly certain > it is) and take action if someone complains. I would like to have such an approach. The question is if that is sufficient for a Debian maintainer (but that question should be directed to Debian and not you). While we're at it, I discovered another thing in configure.ac: dnl The following script checks for ncurses support. dnl I copied and adapted it from DataDisplayDebugger's (DDD) dnl configure.in, written by Andreas Zeller <[email protected]>. DDD is GPL, and so is their configure.ac. This should not render fluidsynth GPL though, since configure.ac is not linked with fluidsynth, but I don't really know what else gets tainted by GPL, given this. // David _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
