[llvm-bugs] [Bug 28831] New: Bad logic around CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28831

            Bug ID: 28831
           Summary: Bad logic around CMAKE_OSX_SYSROOT and
                    CMAKE_OSX_ARCHITECTURES
           Product: libc++
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david at bamsoftware.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
    Classification: Unclassified

Created attachment 16870
  --> https://llvm.org/bugs/attachment.cgi?id=16870&action=edit
Fixes CMake logic around some Mac variables.

I'm using CMake v2.8.12.2 and building libcxx like this:
    cd libcxx
    mkdir build
    cd build
    cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE:STRING=Release
-DCMAKE_C_FLAGS="-target x86_64-apple-darwin10" -DCMAKE_CXX_FLAGS="-target
x86_64-apple-darwin10" -DCMAKE_SYSTEM_NAME=Darwin
-DCMAKE_OSX_SYSROOT=/home/build/MacOSX10.7.sdk -DLLVM_PATH=$HOME/llvm ..
I'm cross compiling from GNU/Linux (Debian) to x86_64-apple-darwin10.

There is a bug in lib/CMakeLists.txt's handling of CMAKE_OSX_SYSROOT.

lib/CMakeLists.txt has this code that doesn't do what it is apparently
trying to do (I added comments for branch labels):

    if ( ${CMAKE_OSX_SYSROOT} )
      # Branch A
      list(FIND ${CMAKE_OSX_ARCHITECTURES} "armv7" OSX_HAS_ARMV7)
      if (OSX_HAS_ARMV7)
        # Branch C
        set(OSX_RE_EXPORT_LINE
          "${CMAKE_OSX_SYSROOT}/usr/lib/libc++abi.dylib"
         
"-Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/libc++sjlj-abi.exp")
      else()
        # Branch D
        set(OSX_RE_EXPORT_LINE
          "-Wl,-reexport_library,${CMAKE_OSX_SYSROOT}/usr/lib/libc++abi.dylib")
      endif()
    else()
      # Branch B
      set(OSX_RE_EXPORT_LINE "/usr/lib/libc++abi.dylib
-Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/libc++abi${LIBCXX_LIBCPPABI_VERSION}.exp")
    endif()

By setting CMAKE_OSX_SYSROOT and leaving CMAKE_OSX_ARCHITECTURES blank,
I expected Branch D to be run. Instead, Branch B is always run.

The first bug is in the syntax of the toplevel "if", which causes it to
be false even if CMAKE_OSX_SYSROOT is defined. According to the CMake
documentation,
    https://cmake.org/cmake/help/v3.3/command/if.html#command:if
    "The if command was written very early in CMake’s history,
    predating the ${} variable evaluation syntax, and for
    convenience evaluates variables named by its arguments as shown
    in the above signatures. Note that normal variable evaluation
    with ${} applies before the if command even receives the
    arguments."
The way the condition is written is causing CMAKE_OSX_SYSROOT to be
dereferenced twice instead of once. It should instead be:
    if ( CMAKE_OSX_SYSROOT )
or perhaps better:
    if ( DEFINED CMAKE_OSX_SYSROOT )

After the "if", there is another bug. This code appears to be checking
for "armv7" in CMAKE_OSX_ARCHITECTURES:
    list(FIND ${CMAKE_OSX_ARCHITECTURES} "armv7" OSX_HAS_ARMV7)
    if (OSX_HAS_ARMV7)
The code treats OSX_HAS_ARMV7 as if it were a boolean, but according to
the documentation, it is an index where -1 means not found:
    https://cmake.org/cmake/help/v3.3/command/list.html#command:list
    "FIND will return the index of the element specified in the list
    or -1 if it wasn’t found."
-1 is treated as a true value, so the condition is true except when
"armv7" is the zeroth element of CMAKE_OSX_ARCHITECTURES. According to
http://www.vtk.org/Wiki/CMake/Examples#Check_if_a_list_contains_a_value,
the way to check for list membership is:
    list(FIND "${CMAKE_OSX_ARCHITECTURES}" "armv7" OSX_HAS_ARMV7)
    if (NOT OSX_HAS_ARMV7 EQUAL -1)

I don't know much about CMake, but the attached patch was sufficient to
get Branch D to execute for me and get the SDK path into
OSX_RE_EXPORT_LINE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160803/f483d793/attachment.html>