[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] fluidsynth 1.1.3 build troubles with cmake
Date: Fri, 15 Oct 2010 19:41:23 +0200
User-agent: KMail/1.13.5 (Linux/; KDE/4.4.4; i686; ; )

On Friday 15 October 2010, Heinz Wiesinger wrote:
> On Friday 15 October 2010 17:04:40 Pedro Lopez-Cabanillas wrote:
> > On Friday 15 October 2010, Heinz Wiesinger wrote:
> > > linux/4.4.4/../../../../lib64/libreadline.so:
> > > undefined reference to `tgetstr'
> > > collect2: ld returned 1 exit status
> > > make[2]: *** [src/fluidsynth] Error 1
> > > make[1]: *** [src/CMakeFiles/fluidsynth.dir/all] Error 2
> > > make: *** [all] Error 2
> > > 
> > > I tried adding -lcurses, -lncurses and/or -ltermcap to the list of
> > > libraries to link, but nothing seemed to help.
> > 
> > To link the transitive dependency, add some arguments to CMake. For
> > instance: $ cmake \
> >     -DCMAKE_EXE_LINKER_FLAGS=-lncurses \
> >     -DCMAKE_SHARED_LINKER_FLAGS=-lncurses \
> >     ...
> Thanks, that one worked. I still think that if autotools can do it 
> automatically, cmake should be able to do it too (IMHO).

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.

In other distros, this issue doesn't exist. Here is the ouput of the two 
mentioned commands in my system:

$ nm -u /usr/lib/libreadline.so 
nm: /usr/lib/libreadline.so: no symbols

(libreadline has no undefined symbols)

$ ldd /usr/lib/libreadline.so 
        linux-gate.so.1 =>  (0xffffe000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb76b9000)
        libc.so.6 => /lib/libc.so.6 (0xb754e000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7549000)
        /lib/ld-linux.so.2 (0xb778f000)

(libreadline is linked here to libncurses, a correct situation).

In my system, linking fluidsynth doesn't require any workaround for external 
library problems, like the one provided by the autotools build system. If you 
want more details, here are some explanations:

> However, that issue being resolved, I ran into another, although more minor 
> one. The installation path for manual pages is hardcoded to 
> "PREFIX/share/man/man1", which is an issue for me since Slackware puts man 
> pages in "PREFIX/man/man1" instead.
> Now I know I can simply move the files there, but I would much rather have a 
> cmake switch for that. Something like -DINSTALL_MAN_DIR or so. Would it be 
> possible to include such a switch with the next release?

Sure. Please add a ticket as remainder.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]