Re: [fluid-dev] New debian/ubuntu package available for testing

[David Henningsson]

address@hidden skrev:
> Quoting David Henningsson <address@hidden>:
> 
>> 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 <address@hidden>.

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