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

[benoît tuduri <benoit.tuduri@xxxxxxxxx>]

Hello,

I removed check_symbol_exists and fixed manually check_symbol_exists
with TRUE and its ok for the compilation.
An otool -L hatari binaries gives this information (attachment 01_otool-L.txt)

2018-02-17 14:27 GMT+01:00 benoît tuduri <benoit.tuduri@xxxxxxxxx>:
> Yes, we agree. :)
>
> Else, I will investigate. But for the moment, i will use the libedit by default.
>
> Regards,
>
> 2018-02-17 11:50 GMT+01:00 Troed Sångberg <troed@xxxxxxxxxxx>:
>> Hi,
>>
>> It's a bit hard to follow without being able to test it myself, but looking at the readline source I think that define should be set when compiling the readline library (it's done by all the .c files), but not when using readline from external source. So it's indeed a path problem, but the solution should be (I think) to figure out why <readline/*.h> isn't valid with the include path you have (set by brew, I assume)
>>
>> regards,
>> Troed
>>
>>
>> -------- Original Message --------
>>  On February 17, 2018 11:16 AM, benoît tuduri <benoit.tuduri@xxxxxxxxx> wrote:
>>
>>>Hello,
>>>
>>> It's a path problem, I guess (attachment 01_cmake01_cmake_log.txt
>>> (trace log cmake detection)) :
>>>
>>> During the compilation of test program to enable the detection of
>>> "rl_filename_completion_function", it report an error "
>>> readline.h:35:12: fatal error: 'readline/rlstdc.h' file not found "
>>> (attachment 02_CMakeError.log)
>>>
>>> The readline.h (attachements 03_head_readline.txt) file contains a
>>> macro READLINE_LIBRARY. This macro is not set but in my case, it
>>> should be done but not and the else branch is taken. The consequencies
>>> is a snowball effect, the bad includes are used, the compilation test
>>> program fail and the detection too.
>>>
>>> I don't know how fix it. If you had an idea... :-) (certainly force in
>>> my case READLINE_LIBRARY=1 but maybe for you, it will destroy the
>>> detection for you)
>>>
>>> Regards,
>>>
>>> 2018-02-15 23:46 GMT+01:00 Troed Sångberg troed@xxxxxxxxxxx:
>>>>Hi,
>>>>I agree those values look just fine. What does CMakeFiles/CMakeError.log say about why it didn't find it?
>>>>regards,
>>>> Troed
>>>>-------- Original Message --------
>>>> On February 15, 2018 10:43 PM, benoît tuduri benoit.tuduri@xxxxxxxxx wrote:
>>>>>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.
>>>>>
>>>>
>>>
>>
>>
>>

hatari.app/Contents/MacOS/hatari:
	/Users/user/homebrew/opt/sdl2/lib/libSDL2-2.0.0.dylib (compatibility version 8.0.0, current version 8.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
	/Users/user/homebrew/opt/readline/lib/libreadline.7.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/Users/user/homebrew/opt/libpng/lib/libpng16.16.dylib (compatibility version 51.0.0, current version 51.0.0)
	/Users/user/homebrew/opt/portaudio/lib/libportaudio.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	/Users/user/homebrew/opt/portmidi/lib/libportmidi.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.47.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1259.20.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1259.32.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)