Cannot start msedgedriver 87.0.666.0 or after on macOS

Question

This question is very similar to https://learn.microsoft.com/en-us/answers/questions/122694/unable-to-start-msedgedriver-in-macos-catalina.html, but I think it's not resolved completely.

When I download msedgedriver 87.0.669.0 or 87.0.666.0 and launch it, I've got an error dyld: Library not loaded: @rpath/libc++.dylib. I have checked dependencies by otool -l /path/to/msedgedriver and found this entry

   Load command 34  
             cmd LC_LOAD_DYLIB  
         cmdsize 48  
            name @rpath/libc++.dylib (offset 24)  
      time stamp 2 Thu Jan  1 09:00:02 1970  
         current version 0.0.0  
   compatibility version 0.0.0  

But we don't have libc++.dylib in the downloaded files, and there is no entry for LC_RPATH in otools output. I guess this is why I've got an error.

When I tried msedgedriver 87.0.664.24, I can easily launch it. The difference is

• Downloaded files include libc++.dylib
• There is an entry which specifies LC_RPATH Load command 41
  cmd LC_RPATH
  cmdsize 32
  path @executable_path/. (offset 12)

Currently we can use 86.0.622.61, 87.0.664.24, 88.0.690.0. But I'm worried that newer revisions of 87.XX have problems. If libc++.dylib is not correctly linked for all available revisions for one major version, we cannot test the major version.

Can we regard that missing libc++.dylib is just an exceptional bug for those revisions?

Answer 1

Hi @Hiroko ,

The issue is that libc++.dylib is not found when referencing dynamic library. This article explains why it can't be found. To put it simply, macOS has added a defensive wall to prevent third parties from maliciously modifying the app, and does not allow the app to load dynamic libraries or scripts.

You can use the install_name_tool to relocate libc++.dylib in the executable on a command line like this. Please note to change the path to your owns when use it:

install_name_tool -change  @rpath/libc++.dylib executable_path/libc++.dylib <full pathname to your executable>  

You can also refer to this thread for more information.

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Regards,
Yu Zhou

Answer 2

Sorry for my late response. Thanks, the workaround seems OK.

Actually, what I really wanted to ask was which distribution (without libc++.dylib or with libc++.dylib) will be the standard. But currently the latest version has the file, so maybe we can believe it...