Page 1 of 1

Dynamically linking 'libcef.dll' to the CRTs.

PostPosted: Thu Feb 05, 2015 10:10 am
by tgbrub
Hi all, i'm trying to use libCEF to build a web based launcher for a game. Everything is working fine for the moment on winxp and win7. Unfortunately, for licensing reasons i can't ship anything that is statically linked to the MS C runtimes as the binary distribution of 'libcef.dll' currently is.

We've been trying to get 'libcef.dll' building from source here, but it's taking ages and we're running into a bunch of issues all over the place. Has anyone tried this yet or had any success with it (dynamically linking to the CRTs that is)? If it's somewhat easy to do, would it be possible for someone to create a binary new distribution of CEF3 that has also has a versions of 'libcef.dll' that are dynamically linked to the C runtime libraries (ie: built with the "/MD" (release) or "/MDd" (debug) compile options)?

thanks in advance! :D

Re: Dynamically linking 'libcef.dll' to the CRTs.

PostPosted: Thu Feb 05, 2015 1:32 pm
by magreenblatt
tgbrub wrote:Unfortunately, for licensing reasons i can't ship anything that is statically linked to the MS C runtimes as the binary distribution of 'libcef.dll' currently is.

What licensing reasons?

Re: Dynamically linking 'libcef.dll' to the CRTs.

PostPosted: Fri Feb 06, 2015 11:19 am
by tgbrub
MS's redistributable license prevents their CRT code from being used on non-microsoft platforms. One of our target platforms is a non-MS platform so we provide our own binary compatible implementation of the CRT.

For the moment however, we only support up to CRT100 (Visual Studio 2010).

Re: Dynamically linking 'libcef.dll' to the CRTs.

PostPosted: Fri Feb 06, 2015 12:37 pm
by magreenblatt
tgbrub wrote:MS's redistributable license prevents their CRT code from being used on non-microsoft platforms. One of our target platforms is a non-MS platform so we provide our own binary compatible implementation of the CRT.

For the moment however, we only support up to CRT100 (Visual Studio 2010).

What you're trying to do is unsupported as you probably know. You'll likely run into at least the following problems:

1. By default Chromium only uses /MD when building with component=="shared_library" (meaning each component is it's own DLL). CEF does not build currently with component=="shared_library", and that's probably not what you want in any case (you want all components in libcef.dll). You can try changing the win_debug_RuntimeLibrary and win_release_RuntimeLibrary values and see what happens. Here are the relevant parts of common.gypi:

https://code.google.com/p/chromium/code ... ypi&l=1246
https://code.google.com/p/chromium/code ... ypi&l=2470

# Although base/allocator lets you select a heap library via an
# environment variable, the libcmt shim it uses sometimes gets in
# the way. To disable it entirely, and switch to normal msvcrt, do e.g.
# 'win_use_allocator_shim': 0,
# 'win_release_RuntimeLibrary': 2
# to ~/.gyp/include.gypi, gclient runhooks --force, and do a release build.


2. VS2013 has been required since 1916 branch, so if you're trying to build that branch or newer you will may get build errors with an older CRT. See https://code.google.com/p/chromiumembed ... ndBuilding for build requirements.