<HTML><BODY>The path seems right and LGTM from my side.<br><br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
        Четверг, 17 октября 2019, 14:57 +03:00 от Igor Munkin <imun@tarantool.org>:<br>
        <br>
        <div id="">






<div class="js-helper js-readmsg-msg">
        <style type="text/css"></style>
        <div>
                
                
            <div id="style_15713134481769941290_BODY">Sasha,<br>
<br>
Thanks, the wording is great and the whole patch LGTM.<br>
<br>
As discussed offline I've created a new follow-up ticket #4575.<br>
<br>
On 17.10.19, Alexander Turenko wrote:<br>
<div class="mail-quote-collapse">> I fixed all known flaws now: see inline answers and the whole new patch<br>
> at end of the email.<br>
> <br>
> WBR, Alexander Turenko.<br>
> <br>
> On Tue, Sep 24, 2019 at 04:15:56PM +0300, Igor Munkin wrote:<br>
> > Sasha,<br>
> > <br>
> > Thanks, see no flaws except for the issue with Apple CommandLineTools<br>
> > compiler on OSX Mojave you're working on. Please consider a sole minor<br>
> > comment below.<br>
> <br>
> Fixed it by passing -isysroot=<SDK_PATH> via CPPFLAGS (PP is a<br>
> preprocessor) and CFLAGS.<br>
> <br>
> Added the following paragraph to the commit message:<br>
> <br>
>  | When CC is passed to libcurl's configure script, the new problem opens<br>
>  | on Mac OS. CMake chooses XCode toolchain by default (at least on a<br>
>  | particular system where I tried it), which requires -isysroot=<SDK_PATH><br>
>  | option to be passed to a preprocessor and a compiler in order to find<br>
>  | system headers. See [2] for more information.<br>
>  |<br>
>  | <...><br>
>  |<br>
>  | [2]: <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623" target="_blank">https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623</a><br>
> <br>
> > <br>
> > On 23.09.19, Alexander Turenko wrote:<br>
> > > FreeBSD has OpenSSL as part of the base system: libraries are located in<br>
> > > /usr/lib, headers are in /usr/include. However a user may install the<br>
> > > library into /usr/local/{lib,include} from ports / pkg. In this case<br>
> > > tarantool did choose /usr/local version, while libcurl will pick up a<br>
> > > base system library. This is fixed by passing --with-ssl option with an<br>
> > > argument (/usr/local or /usr if custom -DOPENSSL_ROOT_DIR=<...> is not<br>
> > > passed).<br>
> > > <br>
> > > Now the behaviour is the following. If -DOPENSSL_ROOT_DIR=<...> is<br>
> > > passed, then try to use OpenSSL from it. Otherwise find the library in<br>
> > > /usr/local and then in /usr. This is right as for tarantool's crypto<br>
> > > module as well as for libcurl submodule.<br>
> > > <br>
> > > There is a flaw here: a user is unable to choose a base system library<br>
> > > if a ports / pkg version of OpenSSL is installed. The reason here is<br>
> > > that tarantool's crypto module depends on other libraries and<br>
> > > -I/usr/local/include may be added to build options. I have no good<br>
> > > solution for that, so `cmake . -DOPENSSL_ROOT_DIR=/usr` will give a<br>
> > > warning on FreeBSD and `gmake` likely will fail if libraries are of<br>
> > > different versions (see cmake/os.cmake comments for more information).<br>
> > > See also a [discussion][1] in FreeBSD community about all those /usr and<br>
> > > /usr/local problems.<br>
> > > <br>
> > > There were two other problems that may fail tarantool build on FreeBSD:<br>
> > > they are fixed in this commit and described below.<br>
> > > <br>
> > > First, libcurl's configure script chooses GCC by default if it exists<br>
> > > (say, installed from ports / pkg). It is unexpected behaviour when<br>
> > > tarantool sources itself are built with clang. Now it is fixed by<br>
> > > passing a compiler explicitly to the libcurl's configure script: the<br>
> > > library will use base system clang by default or one that a user pass to<br>
> > > tarantool's cmake.<br>
> > > <br>
> > > Side note: GCC has /usr/local/include in its default headers search<br>
> > > paths; libcurl's configure script chooses GCC as a compiler and OpenSSL<br>
> > > from a base system by default that leads to OpenSSL header / library<br>
> > > mismatch. It is the primary reason of the build fail that was fixed in<br>
> > > 1f2338bd809585b0b38fe07fd9f80c31747374c2 ('build: FreeBSD packages<br>
> > > installation'). It is not much relevant anymore, because we don't try to<br>
> > > link with a base system OpenSSL if /usr/local one exists (if it is asked<br>
> > > explicitly with -DOPENSSL_ROOT_DIR=<...> we'll do, but will give a<br>
> > > warning). Anyway, it is important to know such details if we'll change<br>
> > > build scripts in a future.<br>
> <br>
> Added a note in parentheses:<br>
> <br>
>  | Side note: GCC has /usr/local/include in its default headers search<br>
>  | paths; libcurl's configure script chooses GCC as a compiler and OpenSSL<br>
>  | from a base system by default (when CC and --with-ssl=<...> are not set)<br>
>  | <...><br>
> <br>
> > > <br>
> > > Second, backtraces are not supported on FreeBSD, but were enabled if<br>
> > > libunwind headers is found. This leads to an error on cmake stage,<br>
> > > because of unability to find a right library (this is the bug). Now we<br>
> > > disable backtraces on FreeBSD by default even if libunwind is found. See<br>
> > > #4278 for more information.<br>
> > > <br>
> > > [1]: <a href="https://wiki.freebsd.org/WarnerLosh/UsrLocal" target="_blank">https://wiki.freebsd.org/WarnerLosh/UsrLocal</a><br>
> > > <br>
> > > Follows up #4490.<br>
> > > ---<br>
> > > <br>
> > > <a href="https://github.com/tarantool/tarantool/issues/4490" target="_blank">https://github.com/tarantool/tarantool/issues/4490</a><br>
> > > <a href="https://github.com/tarantool/tarantool/commits/Totktonada/gh-4490-fix-freebsd-openssl-linking-problems-full-ci" target="_blank">https://github.com/tarantool/tarantool/commits/Totktonada/gh-4490-fix-freebsd-openssl-linking-problems-full-ci</a><br>
> > > <br>
> > > This is more request for review of wording rather then of the code: hope<br>
> > > I verified it carefully enough.<br>
> > > <br>
> > >  cmake/BuildLibCURL.cmake | 15 +++++++--------<br>
> > >  cmake/compiler.cmake     |  4 +++-<br>
> > >  cmake/os.cmake           | 27 +++++++++++++++++++++++++++<br>
> > >  3 files changed, 37 insertions(+), 9 deletions(-)<br>
> > > <br>
> > > diff --git a/cmake/BuildLibCURL.cmake b/cmake/BuildLibCURL.cmake<br>
> > > index 866b3c49e..45f5af23e 100644<br>
> > > --- a/cmake/BuildLibCURL.cmake<br>
> > > +++ b/cmake/BuildLibCURL.cmake<br>
> > > @@ -14,14 +14,10 @@ macro(curl_build)<br>
> > >          message(FATAL_ERROR "Unable to find zlib")<br>
> > >      endif()<br>
> > >  <br>
> > > -    # Set curl option to find OpenSSL library.<br>
> > > -    if ("${OPENSSL_ROOT_DIR}" STREQUAL "")<br>
> > > -        # Linux / FreeBSD.<br>
> > > -        set(LIBCURL_OPENSSL_OPT "--with-ssl")<br>
> > > -    else()<br>
> > > -        # Mac OS.<br>
> > > -        set(LIBCURL_OPENSSL_OPT "--with-ssl=${OPENSSL_ROOT_DIR}")<br>
> > > -    endif()<br>
> > > +    # Use the same OpenSSL library for libcurl as is used for<br>
> > > +    # tarantool itself.<br>
> > > +    get_filename_component(FOUND_OPENSSL_ROOT_DIR ${OPENSSL_INCLUDE_DIR} DIRECTORY)<br>
> > > +    set(LIBCURL_OPENSSL_OPT "--with-ssl=${FOUND_OPENSSL_ROOT_DIR}")<br>
> > >  <br>
> > >      include(ExternalProject)<br>
> > >      ExternalProject_Add(<br>
> > > @@ -35,6 +31,8 @@ macro(curl_build)<br>
> > >          CONFIGURE_COMMAND<br>
> > >              cd <SOURCE_DIR> && ./buildconf &&<br>
> > >              cd <BINARY_DIR> && <SOURCE_DIR>/configure<br>
> > > +                CC=${CMAKE_C_COMPILER}<br>
> > > +                CXX=${CMAKE_CXX_COMPILER}<br>
> > <br>
> > This changeset breaks build for OSX Mojave. The note is left as a<br>
> > reminder of known problem to be fixed in a while.<br>
> <br>
> Yep, fixed (see CPPFLAGS and CFLAGS in the new patch).<br>
> <br>
> > <br>
> > >                  --prefix <INSTALL_DIR><br>
> > >                  --enable-static<br>
> > >                  --enable-shared<br>
> > > @@ -112,6 +110,7 @@ macro(curl_build)<br>
> > >          set(CURL_LIBRARIES ${CURL_LIBRARIES} rt)<br>
> > >      endif()<br>
> > >  <br>
> > > +    unset(FOUND_OPENSSL_ROOT_DIR)<br>
> > >      unset(LIBCURL_INSTALL_DIR)<br>
> > >      unset(LIBCURL_BINARY_DIR)<br>
> > >      unset(LIBCURL_SOURCE_DIR)<br>
> > > diff --git a/cmake/compiler.cmake b/cmake/compiler.cmake<br>
> > > index 887485c80..c9ad2b092 100644<br>
> > > --- a/cmake/compiler.cmake<br>
> > > +++ b/cmake/compiler.cmake<br>
> > > @@ -128,8 +128,10 @@ else()<br>
> > >  endif()<br>
> > >  find_library(UNWIND_LIBRARY PATH_SUFFIXES system NAMES ${UNWIND_LIB_NAME})<br>
> > >  <br>
> > > +# Disabled backtraces support on FreeBSD by default, because of<br>
> > > +# gh-4278.<br>
> > >  set(ENABLE_BACKTRACE_DEFAULT OFF)<br>
> > > -if (UNWIND_LIBRARY AND HAVE_LIBUNWIND_H)<br>
> > > +if (NOT TARGET_OS_FREEBSD AND UNWIND_LIBRARY AND HAVE_LIBUNWIND_H)<br>
> > >      set(ENABLE_BACKTRACE_DEFAULT ON)<br>
> > >  endif()<br>
> > >  <br>
> > > diff --git a/cmake/os.cmake b/cmake/os.cmake<br>
> > > index ea581108b..fe96ce773 100644<br>
> > > --- a/cmake/os.cmake<br>
> > > +++ b/cmake/os.cmake<br>
> > > @@ -22,6 +22,33 @@ elseif (${CMAKE_SYSTEM_NAME} STREQUAL "kFreeBSD")<br>
> > >  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD")<br>
> > >      set(TARGET_OS_FREEBSD 1)<br>
> > >      find_package_message(PLATFORM "Building for FreeBSD" "${CMAKE_SYSTEM_NAME}")<br>
> > > +<br>
> > > +    # FreeBSD has OpenSSL library installed in /usr as part of a<br>
> > > +    # base system. A user may install OpenSSL from ports / pkg to<br>
> > > +    # /usr/local. It is tricky to use the library from /usr in the<br>
> > > +    # case, because a compilation unit can also depend on<br>
> > > +    # libraries from /usr/local. When -I/usr/local/include is<br>
> > > +    # passed to a compiler it will find openssl/ssl.h from<br>
> > > +    # /usr/local/include first.<br>
> > > +    #<br>
> > > +    # In theory we can create a directory on the build stage and<br>
> > > +    # fill it with symlinks to choosen headers. However this way<br>
> > > +    # does not look as usual way to pick libraries to build<br>
> > > +    # against. I suspect that this is common problem on FreeBSD<br>
> > > +    # and we should wait for some general resolution from FreeBSD<br>
> > > +    # developers rather then work it around.<br>
> > > +    #<br>
> > > +    # Verify that /usr is not set as a directory to pick OpenSSL<br>
> > > +    # library and header files, because it is likely that a user<br>
> > > +    # set it to use the library from a base system, while the<br>
> > > +    # library is also installed into /usr/local.<br>
> > > +    get_filename_component(REAL_OPENSSL_ROOT_DIR "${OPENSSL_ROOT_DIR}"<br>
> > > +                           REALPATH BASE_DIR "${CMAKE_BINARY_DIR}")<br>
> > > +    if ("${REAL_OPENSSL_ROOT_DIR}" STREQUAL "/usr")<br>
> > <br>
> > It would be much clearer if you dropped a few words for the warning<br>
> > level usage instead of fatal one here (I guess I saw the rationale<br>
> > within a commit message).<br>
> <br>
> Added the following paragraph:<br>
> <br>
>  | It is possible however that a user is aware of the problem,<br>
>  | but want to use -DOPENSSL_ROOT_DIR=<...> CMake option to<br>
>  | choose OpenSSL from /usr anyway. We should not fail the<br>
>  | build and block this ability. Say, a user may know that<br>
>  | there are no OpenSSL libraries in /usr/local, but finds it<br>
>  | convenient to set the CMake option explicitly due to some<br>
>  | external reason.<br>
> <br>
> > <br>
> > > +        message(WARNING "Using OPENSSL_ROOT_DIR on FreeBSD to choose base "<br>
> > > +                        "system libraries is not supported")<br>
> > > +    endif()<br>
> > > +    unset(REAL_OPENSSL_ROOT_DIR)<br>
> > >  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "NetBSD")<br>
> > >      set(TARGET_OS_NETBSD 1)<br>
> > >      find_package_message(PLATFORM "Building for NetBSD" "${CMAKE_SYSTEM_NAME}")<br>
> > > -- <br>
> > > 2.22.0<br>
> > > <br>
> > <br>
> > -- <br>
> > Best regards,<br>
> > IM<br>
> <br>
> ----<br>
> <br>
> build: fix OpenSSL linking problems on FreeBSD<br>
> <br>
> FreeBSD has OpenSSL as part of the base system: libraries are located in<br>
> /usr/lib, headers are in /usr/include. However a user may install the<br>
> library into /usr/local/{lib,include} from ports / pkg. In this case<br>
> tarantool did choose /usr/local version, while libcurl will pick up a<br>
> base system library. This is fixed by passing --with-ssl option with an<br>
> argument (/usr/local or /usr if custom -DOPENSSL_ROOT_DIR=<...> is not<br>
> passed).<br>
> <br>
> Now the behaviour is the following. If -DOPENSSL_ROOT_DIR=<...> is<br>
> passed, then try to use OpenSSL from it. Otherwise find the library in<br>
> /usr/local and then in /usr. This is right as for tarantool's crypto<br>
> module as well as for libcurl submodule.<br>
> <br>
> There is a flaw here: a user is unable to choose a base system library<br>
> if a ports / pkg version of OpenSSL is installed. The reason here is<br>
> that tarantool's crypto module depends on other libraries and<br>
> -I/usr/local/include may be added to build options. I have no good<br>
> solution for that, so `cmake . -DOPENSSL_ROOT_DIR=/usr` will give a<br>
> warning on FreeBSD and `gmake` likely will fail if libraries are of<br>
> different versions (see cmake/os.cmake comments for more information).<br>
> See also a [discussion][1] in FreeBSD community about all those /usr and<br>
> /usr/local problems.<br>
> <br>
> There were two other problems that may fail tarantool build on FreeBSD:<br>
> they are fixed in this commit and described below.<br>
> <br>
> First, libcurl's configure script chooses GCC by default if it exists<br>
> (say, installed from ports / pkg). It is unexpected behaviour when<br>
> tarantool sources itself are built with clang. Now it is fixed by<br>
> passing a compiler explicitly to the libcurl's configure script: the<br>
> library will use base system clang by default or one that a user pass to<br>
> tarantool's cmake.<br>
> <br>
> Side note: GCC has /usr/local/include in its default headers search<br>
> paths; libcurl's configure script chooses GCC as a compiler and OpenSSL<br>
> from a base system by default (when CC and --with-ssl=<...> are not set)<br>
> that leads to OpenSSL header / library mismatch. It is the primary<br>
> reason of the build fail that was fixed in<br>
> 1f2338bd809585b0b38fe07fd9f80c31747374c2 ('build: FreeBSD packages<br>
> installation'). It is not much relevant anymore, because we don't try to<br>
> link with a base system OpenSSL if /usr/local one exists (however if it<br>
> is asked explicitly with -DOPENSSL_ROOT_DIR=<...> we'll do, but will<br>
> give a warning). Anyway, it is important to know such details if we'll<br>
> change build scripts in a future.<br>
> <br>
> Second, backtraces are not supported on FreeBSD, but were enabled if<br>
> libunwind headers is found. This leads to an error on cmake stage,<br>
> because of inability to find a right library (this is a bug). Now we<br>
> disable backtraces on FreeBSD by default even if libunwind is found. See<br>
> #4278 for more information.<br>
> <br>
> When CC is passed to libcurl's configure script, the new problem opens<br>
> on Mac OS. CMake chooses XCode toolchain by default (at least on a<br>
> particular system where I tried it), which requires -isysroot=<SDK_PATH><br>
> option to be passed to a preprocessor and a compiler in order to find<br>
> system headers. See [2] for more information.<br>
> <br>
> [1]: <a href="https://wiki.freebsd.org/WarnerLosh/UsrLocal" target="_blank">https://wiki.freebsd.org/WarnerLosh/UsrLocal</a><br>
> [2]: <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623" target="_blank">https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623</a><br>
> <br>
> Follows up #4490.<br>
> ---<br>
>  cmake/BuildLibCURL.cmake | 25 ++++++++++++++++++-------<br>
>  cmake/compiler.cmake     |  4 +++-<br>
>  cmake/os.cmake           | 35 +++++++++++++++++++++++++++++++++++<br>
>  3 files changed, 56 insertions(+), 8 deletions(-)<br>
> <br>
> diff --git a/cmake/BuildLibCURL.cmake b/cmake/BuildLibCURL.cmake<br>
> index 866b3c49e..0dc7676d6 100644<br>
> --- a/cmake/BuildLibCURL.cmake<br>
> +++ b/cmake/BuildLibCURL.cmake<br>
> @@ -14,13 +14,18 @@ macro(curl_build)<br>
>          message(FATAL_ERROR "Unable to find zlib")<br>
>      endif()<br>
>  <br>
> -    # Set curl option to find OpenSSL library.<br>
> -    if ("${OPENSSL_ROOT_DIR}" STREQUAL "")<br>
> -        # Linux / FreeBSD.<br>
> -        set(LIBCURL_OPENSSL_OPT "--with-ssl")<br>
> -    else()<br>
> -        # Mac OS.<br>
> -        set(LIBCURL_OPENSSL_OPT "--with-ssl=${OPENSSL_ROOT_DIR}")<br>
> +    # Use the same OpenSSL library for libcurl as is used for<br>
> +    # tarantool itself.<br>
> +    get_filename_component(FOUND_OPENSSL_ROOT_DIR ${OPENSSL_INCLUDE_DIR} DIRECTORY)<br>
> +    set(LIBCURL_OPENSSL_OPT "--with-ssl=${FOUND_OPENSSL_ROOT_DIR}")<br>
> +<br>
> +    # Pass -isysroot=<SDK_PATH> option on Mac OS to a preprocessor<br>
> +    # and a C compiler to find header files installed with an SDK.<br>
> +    set(LIBCURL_CPPFLAGS "")<br>
> +    set(LIBCURL_CFLAGS "")<br>
> +    if (TARGET_OS_DARWIN AND NOT "${CMAKE_OSX_SYSROOT}" STREQUAL "")<br>
> +        set(LIBCURL_CPPFLAGS "${LIBCURL_CPPFLAGS} ${CMAKE_C_SYSROOT_FLAG} ${CMAKE_OSX_SYSROOT}")<br>
> +        set(LIBCURL_CFLAGS "${LIBCURL_CFLAGS} ${CMAKE_C_SYSROOT_FLAG} ${CMAKE_OSX_SYSROOT}")<br>
>      endif()<br>
>  <br>
>      include(ExternalProject)<br>
> @@ -35,6 +40,9 @@ macro(curl_build)<br>
>          CONFIGURE_COMMAND<br>
>              cd <SOURCE_DIR> && ./buildconf &&<br>
>              cd <BINARY_DIR> && <SOURCE_DIR>/configure<br>
> +                CC=${CMAKE_C_COMPILER}<br>
> +                CPPFLAGS=${LIBCURL_CPPFLAGS}<br>
> +                CFLAGS=${LIBCURL_CFLAGS}<br>
>                  --prefix <INSTALL_DIR><br>
>                  --enable-static<br>
>                  --enable-shared<br>
> @@ -112,6 +120,9 @@ macro(curl_build)<br>
>          set(CURL_LIBRARIES ${CURL_LIBRARIES} rt)<br>
>      endif()<br>
>  <br>
> +    unset(LIBCURL_CPPFLAGS)<br>
> +    unset(LIBCURL_CFLAGS)<br>
> +    unset(FOUND_OPENSSL_ROOT_DIR)<br>
>      unset(LIBCURL_INSTALL_DIR)<br>
>      unset(LIBCURL_BINARY_DIR)<br>
>      unset(LIBCURL_SOURCE_DIR)<br>
> diff --git a/cmake/compiler.cmake b/cmake/compiler.cmake<br>
> index 887485c80..c9ad2b092 100644<br>
> --- a/cmake/compiler.cmake<br>
> +++ b/cmake/compiler.cmake<br>
> @@ -128,8 +128,10 @@ else()<br>
>  endif()<br>
>  find_library(UNWIND_LIBRARY PATH_SUFFIXES system NAMES ${UNWIND_LIB_NAME})<br>
>  <br>
> +# Disabled backtraces support on FreeBSD by default, because of<br>
> +# gh-4278.<br>
>  set(ENABLE_BACKTRACE_DEFAULT OFF)<br>
> -if (UNWIND_LIBRARY AND HAVE_LIBUNWIND_H)<br>
> +if (NOT TARGET_OS_FREEBSD AND UNWIND_LIBRARY AND HAVE_LIBUNWIND_H)<br>
>      set(ENABLE_BACKTRACE_DEFAULT ON)<br>
>  endif()<br>
>  <br>
> diff --git a/cmake/os.cmake b/cmake/os.cmake<br>
> index ea581108b..0ed554b9b 100644<br>
> --- a/cmake/os.cmake<br>
> +++ b/cmake/os.cmake<br>
> @@ -22,6 +22,41 @@ elseif (${CMAKE_SYSTEM_NAME} STREQUAL "kFreeBSD")<br>
>  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD")<br>
>      set(TARGET_OS_FREEBSD 1)<br>
>      find_package_message(PLATFORM "Building for FreeBSD" "${CMAKE_SYSTEM_NAME}")<br>
> +<br>
> +    # FreeBSD has OpenSSL library installed in /usr as part of a<br>
> +    # base system. A user may install OpenSSL from ports / pkg to<br>
> +    # /usr/local. It is tricky to use the library from /usr in the<br>
> +    # case, because a compilation unit can also depend on<br>
> +    # libraries from /usr/local. When -I/usr/local/include is<br>
> +    # passed to a compiler it will find openssl/ssl.h from<br>
> +    # /usr/local/include first.<br>
> +    #<br>
> +    # In theory we can create a directory on the build stage and<br>
> +    # fill it with symlinks to choosen headers. However this way<br>
> +    # does not look as usual way to pick libraries to build<br>
> +    # against. I suspect that this is common problem on FreeBSD<br>
> +    # and we should wait for some general resolution from FreeBSD<br>
> +    # developers rather then work it around.<br>
> +    #<br>
> +    # Verify that /usr is not set as a directory to pick OpenSSL<br>
> +    # library and header files, because it is likely that a user<br>
> +    # set it to use the library from a base system, while the<br>
> +    # library is also installed into /usr/local.<br>
> +    #<br>
> +    # It is possible however that a user is aware of the problem,<br>
> +    # but want to use -DOPENSSL_ROOT_DIR=<...> CMake option to<br>
> +    # choose OpenSSL from /usr anyway. We should not fail the<br>
> +    # build and block this ability. Say, a user may know that<br>
> +    # there are no OpenSSL libraries in /usr/local, but finds it<br>
> +    # convenient to set the CMake option explicitly due to some<br>
> +    # external reason.<br>
> +    get_filename_component(REAL_OPENSSL_ROOT_DIR "${OPENSSL_ROOT_DIR}"<br>
> +                           REALPATH BASE_DIR "${CMAKE_BINARY_DIR}")<br>
> +    if ("${REAL_OPENSSL_ROOT_DIR}" STREQUAL "/usr")<br>
> +        message(WARNING "Using OPENSSL_ROOT_DIR on FreeBSD to choose base "<br>
> +                        "system libraries is not supported")<br>
> +    endif()<br>
> +    unset(REAL_OPENSSL_ROOT_DIR)<br>
>  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "NetBSD")<br>
>      set(TARGET_OS_NETBSD 1)<br>
>      find_package_message(PLATFORM "Building for NetBSD" "${CMAKE_SYSTEM_NAME}")<br>
</div><br>
-- <br>
Best regards,<br>
IM<br>
<br>
</div>
            
        
                
        </div>

        
</div>


</div>
</blockquote>
<br>
<br>-- <br>Alexander Tikhonov<br></BODY></HTML>