Re: [fluid-dev] fluidsynth 1.1.3 build troubles with cmake

[Pedro Lopez-Cabanillas]

On Friday 15 October 2010, Heinz Wiesinger wrote:
>> FluidSynth doesn't use any termcap-API functions, why should we link one of
>> the libraries providing those functions? It is the readline package in your
>> distro that should be fixed, IMHO.
> 
> Well, I get your point. Nonetheless I don't see readline getting "fixed" in 
> Slackware anytime soon. I had a quick try on building readline in a way to 
> link against ncurses and it requires some build system hackery to 
> accomplish, 

It requires only this command line when compiling Readline:
$ make SHLIB_LIBS=-lncurses

> which hints at an upstream problem. The upstream problem is afair a
> licensing one, so it probably won't be fixed. And Slackware has a long
> history of not fixing upstream issues (contrary to a lot of other distros
> out there).

It is not a license problem. Both readline and ncurses are GPL licensed. The 
INSTALL file in readline-6.1 says: "Readline uses the termcap functions, but 
does not link with the termcap or curses library itself, allowing applications  
  
which link with readline the to choose an appropriate library." [sic] :-)

So, it is a decission problem. It is a choice. Upstream don't want to make a  
choice that forces all applications linked to readline to use one termcap 
implementation instead of another. This type of decissions are usually made  
by the distributions. They decide in which prefix are installed the libraries, 
which compiler and tools versions to use, and the preferred implementation of 
the termcap API, among other choices.

Making the decission in FluidSynth build systems is possible, but not very 
convenient. If the packager didn't want to compile Readline using the well 
documented option "SHLIB_LIBS=-lncurses", then he can use later the cmake 
option "-DCMAKE_SHARED_LINKER_FLAGS=-lncurses" when compiling Fluidsynth. 
That's all. No dirty hackery is required.

Regards,
Pedro