[llvm-bugs] [Bug 47992] New: Please backport e72d792c147ee506e337401e20c0f23042cc43fe: Guard `find_library(tensorflow_c_api ...)` by checking for TENSORFLOW_C_LIB_PATH to be set by the user

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Oct 28 01:12:14 PDT 2020


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

            Bug ID: 47992
           Summary: Please backport
                    e72d792c147ee506e337401e20c0f23042cc43fe: Guard
                    `find_library(tensorflow_c_api ...)` by checking for
                    TENSORFLOW_C_LIB_PATH to be set by the user
           Product: new-bugs
           Version: 11.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mgorny at gentoo.org
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
            Blocks: 47800

Created attachment 24109
  --> https://bugs.llvm.org/attachment.cgi?id=24109&action=edit
0001-backport-D88371-guard-find_library-tensorflow_c_api.patch

The TF logic in 11.0.0 causes LLVM to fail to build on Gentoo when TF is
installed.

I'm attaching the rebased version of the commit that applies to 11.x.


commit e72d792c147ee506e337401e20c0f23042cc43fe
Author: Mehdi Amini <joker.eph at gmail.com>
Date:   2020-09-28 22:46:22 +0200

    Guard `find_library(tensorflow_c_api ...)` by checking for
TENSORFLOW_C_LIB_PATH to be set by the user

    Also have CMake fails if the user provides a TENSORFLOW_C_LIB_PATH but
    we can't find TensorFlow at this path.

    At the moment the CMake script tries to figure if TensorFlow is
    available on the system and enables support for it. This is in general
    not desirable to customize build features this way and instead it is
    preferable to let the user opt-in explicitly into the features they want
    to enable. This is in line with other optional external dependencies
    like Z3.
    There are a few reasons to this but amongst others:
    - reproducibility: making features "magically" enabled based on whether
      we find a package on the system or not makes it harder to handle bug
      reports from users.
    - user control: they can't have TensorFlow on the system and build LLVM
      without TensorFlow right now. They also would suddenly distribute LLVM
      with a different set of features unknowingly just because their build
      machine environment would change subtly.

    Right now this is motivated by a user reporting build failures on their
system:

    .../mesa-git/llvm-git/src/llvm-project/llvm/lib/Analysis/TFUtils.cpp:23:10:
fatal error: tensorflow/c/c_api.h: No such file or directory
       23 | #include "tensorflow/c/c_api.h"
          |          ^~~~~~

    It looks like we detected TensorFlow at configure time but couldn't set all
the paths correctly.

    Differential Revision: https://reviews.llvm.org/D88371


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=47800
[Bug 47800] [meta] 11.0.1 Release Blockers
-- 
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/20201028/2c9fe6f2/attachment.html>


More information about the llvm-bugs mailing list