Quoting David Henningsson <[email protected]>:
Bernat Arlandis i Mañó skrev:
David Henningsson escrigué:
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...)
It seems like autotools gets the dependencies for the project as a whole
and then applies them to every piece built. There should be some way to
tell which dependencies are for the lib and which ones for the
executable, but I don't know. Have you asked DD?
No, as you're the only one that has worried about it, and it seems that
the problem originates from upstream. My personal guess is that the
warning is quite minor and can be safely ignored.
Its libtool that is adding in all the dependencies, which are
dependencies of libfluidsynth. I think it is a rather minor issue.
Those warnings are likely for the purpose of weeding out unnecessary
dependencies for a package. Since fluidsynth and libfluidsynth are
part of the same package, this doesn't really help, unless a library
is getting linked that both libfluidsynth and fluidsynth don't
actually depend on.
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.
You're way too much picky with the licensing issues. Anyone (even Debian
developers) would pick upstream's word as stated in the source code and
documentation unless it's proved wrong by someone.
I've checked DDD's configure.ac and it is GPL (v2+) - and not stating
that in our configure.ac is a GPL violation. I don't think the problem
is larger than that we could add the necessary GPL notice.
I don't see any reason to have configure.ac be LGPL, since that
provides no advantage whatsoever over GPL. We could just declare it
GPL and be done with it. I don't think there was ever a declared
license for it and by using GPL code it would fall under GPL (and I
wrote a huge portion of it anyways). I think its somewhat silly to
license configure.ac in the first place, since it really isn't rocket
science, but it certainly doesn't hurt.
By playing the devil you're going against yourself and upstream.
I'm here on double roles currently, both as a FluidSynth developer and
as a Debian maintainer. I would appreciate if you could see me as a
mediator, rather than a devil.
Perhaps having both roles is bad, as it seems to cause some confusion
sometimes. Let me know if you would prefer me giving up one of those tasks.
// David
I think you are doing a fine job, so no worries. This whole free
software licensing thing is a mess though, in my opinion. When you
just want to write free software, its annoying to have to deal with
the legal details of licenses. Licenses which were created for the
purpose of keeping software free and promoting open contribution and
collaboration shouldn't impede those very same things. Just my little
rant, not meant to go any further.. ;)
Regards,
Josh
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
