CEF Forum

Hello people!
I'm implementing CEF in a Unreal Engine, and UE4 is linking against CRT on windows dynamically. This is fine with regular CEF usage as I can set /MD flag when building the libcef_dll_wrapper.lib via CMake. Unfortunately though I'd also need to support sandboxed sub-processes, and cef_sandbox.lib provided in the distributables apparently expects static linkage to CRT. I get these errors:

Code: Select all

cef_sandbox.lib(*.obj): Error LNK2038 : mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in SharedPCH.Engine.ShadowErrors.h.obj


Where SharedPCH.Engine.ShadowErrors.h.obj is something UE4 generates.
So my question is, how do I work with a forced /MD environment when using cef_sandbox.lib?

Linking the sandbox with /MD is not supported.

Oh that's unfortunate. Can I make my own CEF build which supports that, or is it a technical/security constraint?

It's a technical constraint, in that you would need to build a substantial portion of Chromium with /MD, and that is also not supported.

as a follow-up for people who might have the same issue: I managed to build chromium and run ceftests and cefclient without a problem when I compiled CEF and Chromium with /MD by default. Here's what I did:

• I've crudely just modified the default_crt config in MyChromium/build/config/win/BUILD.gn
  

  Code: Select all

  # Configures how the runtime library (CRT) is going to be used.
# See https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx for a reference of
# what each value does.
config("default_crt") {
  if (is_component_build) {
    # Component mode: dynamic CRT. Since the library is shared, it requires
    # exceptions or will give errors about things not matching, so keep
    # exceptions on.
    configs = [ ":dynamic_crt" ]
  } else {
    if (current_os == "winuwp") {
      # https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/
      # contains a details explanation of what is happening with the Windows
      # CRT in Visual Studio releases related to Windows store applications.
      configs = [ ":dynamic_crt" ]
    } else {
      # Desktop Windows: static CRT.
      # This was ":static_crt"
      configs = [ ":dynamic_crt" ]
    }
  }
}


  
  
• I had to #pragma comment( lib, "Propsys" ) in MyChromium/base/win/win_util.cc base/win/win_util.cc
• And #pragma comment( lib, "Wbemuuid" ) in MyChromium/base/win/wmi.cc base/win/wmi.cc
• Unfortunately the allocator shimming Chromium does by default on windows is not compatible with /MD (as far as I've gathered) but fortunately that can be disabled via GN_DEFINES="use_allocator=none use_allocator_shim=false". As far as I gathered this will result in more memory usage, but nothing breaking so far when I ran ceftests or cefclient
• Making a distributable still fails when combining lib files for cef_sandbox.lib, lib.exe just fails on whichever lib file is the first in its arguments
  

  Code: Select all

  C:\code\chromium_git\chromium\src\out\Debug_GN_x64\obj\base\base.lib : fatal error LNK1107: invalid or corrupt file: cannot read at 0x78C3EF0

  
  lib files are there and lib.exe is doing fine if the input is only one lib file, but I'd suspect it succeeds only because it just copies the input file to output instead of processing it. That's just a hunch though.
  

Obviously these are first drafts, I know that #pragma comment( lib, "*" ) additions are MSVC only stuff for example. I'll update as I chug along. Insights and feedback are welcome

microdee wrote:

• Making a distributable still fails when combining lib files for cef_sandbox.lib, lib.exe just fails on whichever lib file is the first in its arguments

I managed to overcome that with disabling LLD (LLVM linker) and LTO (Link Time Optimization) via GN arguments. So the GN arguments needed for this trick are

Code: Select all

use_allocator=none
use_allocator_shim=false
use_lld=false
use_thin_lto=false


And then I could make a distributable