tensorflow: Failure to build on OS/X

copying nsync*.h from dist-packages/external/nsync/public (or https://github.com/google/nsync/tree/master/public) to /usr/include also does the trick without modifying tensorflow files.

Hi, I came up with a solution. Taking into account that I was able to compile everything from source on different machines, I just changed the file mutex.h for the following code:

/* Copyright 2015 The TensorFlow Authors. All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
==============================================================================*/

#ifndef TENSORFLOW_PLATFORM_DEFAULT_MUTEX_H_
#define TENSORFLOW_PLATFORM_DEFAULT_MUTEX_H_

// IWYU pragma: private, include "third_party/tensorflow/core/platform/mutex.h"
// IWYU pragma: friend third_party/tensorflow/core/platform/mutex.h

#include <chrono>
#include <condition_variable>
#include <mutex>
#include "tensorflow/core/platform/thread_annotations.h"
namespace tensorflow {

#undef mutex_lock

enum LinkerInitialized { LINKER_INITIALIZED };

// A class that wraps around the std::mutex implementation, only adding an
// additional LinkerInitialized constructor interface.
class LOCKABLE mutex : public std::mutex {
 public:
  mutex() {}
  // The default implementation of std::mutex is safe to use after the linker
  // initializations
  explicit mutex(LinkerInitialized x) {}

  void lock() ACQUIRE() { std::mutex::lock(); }
  bool try_lock() EXCLUSIVE_TRYLOCK_FUNCTION(true) {
    return std::mutex::try_lock();
  };
  void unlock() RELEASE() { std::mutex::unlock(); }
};

class SCOPED_LOCKABLE mutex_lock : public std::unique_lock<std::mutex> {
 public:
  mutex_lock(class mutex& m) ACQUIRE(m) : std::unique_lock<std::mutex>(m) {}
  mutex_lock(class mutex& m, std::try_to_lock_t t) ACQUIRE(m)
      : std::unique_lock<std::mutex>(m, t) {}
  mutex_lock(mutex_lock&& ml) noexcept
      : std::unique_lock<std::mutex>(std::move(ml)) {}
  ~mutex_lock() RELEASE() {}
};

// Catch bug where variable name is omitted, e.g. mutex_lock (mu);
#define mutex_lock(x) static_assert(0, "mutex_lock_decl_missing_var_name");

using std::condition_variable;

inline ConditionResult WaitForMilliseconds(mutex_lock* mu,
                                           condition_variable* cv, int64 ms) {
  std::cv_status s = cv->wait_for(*mu, std::chrono::milliseconds(ms));
  return (s == std::cv_status::timeout) ? kCond_Timeout : kCond_MaybeNotified;
}

}  // namespace tensorflow

#endif  // TENSORFLOW_PLATFORM_DEFAULT_MUTEX_H_

Can you edit your post and show specs of machine, tensorflow version & bazel. Thanks (Just to detect where can be the mistake).

I changed the file tensorflow/core/platform/default/mutex.h by adding the relative path as prefix of nsync_cv.h and nsync_mu.h to fix the issue, as follows:

#include "external/nsync/public/nsync_cv.h"
#include "external/nsync/public/nsync_mu.h"

I feel as though this issue should be re-opened, because a fresh clone of master (as of b20ec5c461031f9375274cf026a7dfff0f903acc) results in the Aforementioned NSync compilation bug when trying to integrate libtensorflow into other apps - the only working solution was to use @alc1218 's variant of mutex.h - which is a breaking change to the codebase.

Thank you.

Had the same issue: search for nsync_cv.h file using: sudo find / -name nsync_cv.h then add it in the file mutex.h #include "tensorflow/contrib/makefile/downloads/nsync/public/nsync_cv.h" #include "tensorflow/contrib/makefile/downloads/nsync/public/nsync_mu.h"

If you get linker error after above step try this: https://github.com/tensorflow/tensorflow/issues/12904#issuecomment-328234880