Enable loading native libraries with RTLD_DEEPBIND

base/native_library_mac.mm

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/native_library.h"
 
 #include <dlfcn.h>
 #include <mach-o/getsect.h>
 
 #include "base/files/file_path.h"
@@ skipping 21 matching lines @@
       reinterpret_cast<const struct mach_header_64*>(info.dli_fbase),
       SEG_DATA, "__objc_imageinfo");
   return section ? OBJC_PRESENT : OBJC_NOT_PRESENT;
 }
 
 std::string NativeLibraryLoadError::ToString() const {
   return message;
 }
 
 // static
-NativeLibrary LoadNativeLibrary(const FilePath& library_path,
-                                NativeLibraryLoadError* error) {
+NativeLibrary LoadNativeLibraryWithOptions(const FilePath& library_path,
+                                           const NativeLibraryOptions& options,
+                                           NativeLibraryLoadError* error) {
   // dlopen() etc. open the file off disk.

[Primiano Tucci (use gerrit), 2016/08/24 22:14:09]

I think here you want to CHECK that you don't have any options, as those are not
supported on mac.

[Ken Rockot(use gerrit already), 2016/08/24 23:23:57]

I would prefer we silently ignore the option since it's really only a flag to
prefer local resolution when not the default behavior. Ideally IMHO user code
shouldn't have add platform guards when using this. But then maybe a more
accurate name would be force_own_symbols or force_local_resolution or something?

[Primiano Tucci (use gerrit), 2016/08/25 10:20:44]

Silently changing ignoring a requested behavior feels a bad API to me.
IMHO either you guarantee that such behavior just happens to work that way in
windows and mac, in which case is fine to leave it because it happens that
"prefer_own_symbols" just works by default on those platforms (but in this case
please make sure that the test works).
If not you should check.
If the user code tries to request this feature on a platform where this feature
is not available we should IMHO hard crash and make it evident that the user
code is doing something wrong.

[Ken Rockot(use gerrit already), 2016/08/25 15:52:12]

If we were actually going to make the feature unavailable on other platforms,
I'd rather restrict the definition itself to only those platforms. In any case
this requires all to write noise like

  #if defined(OS...)
  options.prefer_own_symbols = true;
  #endif

which seems unfortunate to me when the meaning of the flag seems justifiable
even without a corresponding OS feature: the flag is defined to have no effect
when |false|; and when |true|, it forces behavior that is already the default on
some platforms. The test exists to ensure that this is the case.

[Primiano Tucci (use gerrit), 2016/08/25 16:14:33]

Oh hold on, I think we might be saying the same thing.
Let me try to reword it: if we can guarantee that on the other platforms (where
we ignore the flag) true corresponds with the default behavior I agree we don't
need any #ifdef.
My only concern is: if we cannot support it, let's not silently ignore it. But
from your comments sounds like we are already in the state where the other
platforms are fine (%android where I'd CHECK(false))

   if (library_path.Extension() == "dylib" || !DirectoryExists(library_path)) {
     void* dylib = dlopen(library_path.value().c_str(), RTLD_LAZY);
     if (!dylib) {
       if (error)
         error->message = dlerror();
       return nullptr;
     }
     NativeLibrary native_lib = new NativeLibraryStruct();
     native_lib->type = DYNAMIC_LIB;
     native_lib->dylib = dylib;
@@ skipping 62 matching lines @@
   return function_pointer;
 }
 
 // static
 std::string GetNativeLibraryName(StringPiece name) {
   DCHECK(IsStringASCII(name));
   return "lib" + name.as_string() + ".dylib";
 }
 
 }  // namespace base