Re: [hatari-devel] cmake doesn't detect correctly the readline library on osx.

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

I'm guessing this problem stems from how homebrew forces that link to its own readline rather than the one in /usr/lib. You can message() the variables from cmake/FindReadline.cmake to see what they end up as:

FIND_PATH(READLINE_INCLUDE_DIR readline.h PATH_SUFFIXES readline)
FIND_LIBRARY(READLINE_LIBRARY NAMES readline)
​
message(${READLINE_LIBRARY})
message(${READLINE_INCLUDE_DIR})

I think it's this difference between check_symbol_exists and check_function_exists that trips up:

"check_function_exists() only verifies linking, it does not verify that the function is declared in system headers."

regards,
Troed​

-------- Original Message --------
 On February 13, 2018 11:17 PM, benoît tuduri <benoit.tuduri@xxxxxxxxx> wrote:

>Hello,
>
> I still have detection problems for readline with cmake, Look my cmake listing :
>
> [1] libedit detected like readline => it's ok , readline is
>detected (attachement 01_log.txt)
> [2] readline 7.0.3
> Note:  I forced to link my system to use the readline 7.0.3 :
> $ brew link --force readline
> (attachement 02_log.txt)
>
> I investigate why cmake is able to detect the right libreadline (
> /Users/user/homebrew/lib/libreadline.dylib ) but not
> rl_filename_completion_function. (attachment 03_log.txt)
>
> To solve this detection problem, I changed some stuff in
> FindReadme.cmake (attachment
> check_function_exists_cmake_rl_filename_completion_function.patch)
>
> And the detection works like a charm : (attachment 04_log.txt)
>
> I hope the patch will not break under linux or windows or newer
> versions of osx or macports.
>
> Could you give me a feedback ?
>
> Regards,
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/