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

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


Hello,

Troed, I prefixed the important value by the sign --> . As you can
remark, the path is in my home directory and the
"rl_filename_completion_function" (without quotes) is in readline.h
file.

Regards,

2018-02-13 23:48 GMT+01:00 Troed Sångberg <troed@xxxxxxxxxxx>:
> 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,
>>
>
>
-- The C compiler identification is AppleClang 8.0.0.8000038
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test MUDFLAP_AVAILABLE
-- Performing Test MUDFLAP_AVAILABLE - Failed
-- Found SDL2: /Users/user/homebrew/lib/libSDL2main.a;/Users/user/homebrew/lib/libSDL2.dylib;-framework Cocoa  
-- Found MATH: /usr/lib/libm.dylib  
-- Found READLINE: /Users/user/homebrew/lib/libreadline.dylib  
libs path->    /Users/user/homebrew/lib/libreadline.dylib
incl path->    /Users/user/homebrew/include/readline
-- Looking for rl_filename_completion_function
-- Looking for rl_filename_completion_function - not found
-- Found TERMCAP: /usr/lib/libtermcap.dylib  
-- Looking for rl_filename_completion_function
-- Looking for rl_filename_completion_function - not found
-- Found Curses: /usr/lib/libcurses.dylib  
-- Looking for rl_filename_completion_function
-- Looking for rl_filename_completion_function - not found




$ grep -Ri "rl_filename_completion_function" /Users/user/homebrew/include/readline
/Users/user/homebrew/include/readline/readline.h:extern char *rl_filename_completion_function PARAMS((const char *, int));



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