MinGW + libcef_dll_wrapper

[pkorzeniewski]

Hi,

I'm trying to compile a project which uses CEF with MinGW, but I'm getting "undefined reference to" errors on C++ classes. I have linked libcef and libcef_dll_wrapper (.lib versions). Anyone had any success with MinGW and C++ API?

[diegoarize]

Hi I am having the same issues. I am trying to compile a CEF application, however it is missing the libcef_dll_wrapper. Looking at the tutorial, I've seen that I need to build it first although I am having problems to get it on MinGW, does anyone has some experience on it? Thanks in advance!

[PolesApart]

I've successfully built libcef_dll on mingw-w64 (targetting win32) for cef 3.1750.1738 build.


there are some subtleties which may bite:

a) Code bloat. You'll probably need to carry along mingw stuff consisted of c and c++ runtimes and libgcc_s. The c runtime will be statically linked, but normally the c++ runtime isn't (but -static-libstdc++ is your friend).
b) Your mingw build may or may not have compatible threading support. This may impact how you pass data between your application and cef. Some deadlock may occur if you try to play mr smart guy on top of cef.
c) Don't try to use -flto. It'll work on recent gcc/binutils combo. But it'll introduce heisenbugs that'll bite you long on the development path.

I'll try to attach my relevant Makefile. Please note that it's used on Linux, I cross-compile it, so you'll probably need some fine tunings.

[PolesApart]

... and this patch (in annex) summarizes everything needed to be changed for compatibility w/ mingw. This targets v. 3.2171.1949

RE-EDIT: I broke the patch in two: the core mingw compatibility (revisited to stay more portable) and the cross-compile needed changes. The latter isn't portability-friendly.

[BlueMagnificent]

I've successfully built libcef_dll on mingw-w64 (targetting win32) for cef 3.1750.1738 build.


there are some subtleties which may bite:

a) Code bloat. You'll probably need to carry along mingw stuff consisted of c and c++ runtimes and libgcc_s. The c runtime will be statically linked, but normally the c++ runtime isn't (but -static-libstdc++ is your friend).
b) Your mingw build may or may not have compatible threading support. This may impact how you pass data between your application and cef. Some deadlock may occur if you try to play mr smart guy on top of cef.
c) Don't try to use -flto. It'll work on recent gcc/binutils combo. But it'll introduce heisenbugs that'll bite you long on the development path.

I'll try to attach my relevant Makefile. Please note that it's used on Linux, I cross-compile it, so you'll probably need some fine tunings.

Thanks a million for your clues ... After trying for weeks I was finally able to build libcef_dll_wrapper, cefclient and cefsimple using Mingw-w64 with cef 3.2339.1253 build. In addition to the code tweaking you posted I made some further mordifications specific to MinGW like adding

Code: Select all

#if defined(__MINGW32__)
#ifndef COMPILER_MINGW
#define COMPILER_MINGW 1
#endif


at the head of the compiler detection section of of CEF/include/base/cef_build.h . With that my CEF/include/internal/cef_export.h was modified to contain

Code: Select all

#ifndef CEF_INCLUDE_INTERNAL_CEF_EXPORT_H_
#define CEF_INCLUDE_INTERNAL_CEF_EXPORT_H_
#pragma once

#include "include/base/cef_build.h"

#if defined(COMPILER_MINGW)

#define CEF_EXPORT __attribute__ ((visibility("default")))
#define CEF_CALLBACK __stdcall

#endif  // CEF_INCLUDE_INTERNAL_CEF_EXPORT_H_
#endif


(you don't necessarily have to remove other compiler definitions)

For the import library, I actually had to generate a .DEF file for libcef.dll and then use dlltool to generate a MinGW based library

[PolesApart]

I'm glad it worked for you! In my case I didn't need the def file, as mingw64 supports linking from the DLL for the most common cases, so I just did that. It's probably a bit slower this way thought, as looking into the DLL to resolve the symbols probably involves more work than having a export library specially crafted for that purpose.

EDIT: also, I'm withdrawing my recommendation against linking using -flto (but I'm not advocating you should use it either, as it has link time costs and makes code harder to debug). The bugs I saw were caused by having mixed -flto -O2 and -fno-lto -O0 objects in the same build (I had an incorrect clean rule and separated production vs debug targets). That resulted in a successful link but crashes at runtime. Once I manage to correctly separate the debug and release builds, everything was fine for both targets.

Also, when updading cef, my original patch sometimes failed to apply on the rule that defined the CEF_CALLBACK case, which also leads to crashes as soon as cef callbacks into my code, so whenever it crashes I now double check those things before assuming it's a bug elsewhere.

As for using attribute visibility instead of __declspec(dllexport), there are some minor poorly documented caveats. the declspec case has the side effect that if you use it at least once in a project (or more exactly in a link unit), then only the symbols with explicit __declspec(dllexport) are exported, period. If you don't attach the attribute, it'll behave as it was attached to almost every symbol, in other words, almost symbol *is* exported.

As for attribute visibility, functions declared with the "extern" modifier are always exported even without visibility(default), unless they have a specific visibility hidden attribute attached to it's declaration. GCC man page says it's for compatibility with existing code. I think it was a bad call, but maybe that's just me.

Anyway, I recommend conditionally using __declspec(dllexport) on windows targets, for it'll most likely export only the required symbols, where visibility(default) and -fvisibility=hidden will most likely leak additional symbols. Your mileage may vary, as most libcef_dll declarations are automatically generated they probably lack the extern modifier anyway and the results should be compatible.

Also, the case for __declspec(dllimport) may save a bit of space (and some function calls on runtime) by eliminating an extra thunk function call for dll methods, you should consider using it too, but for using cef definitions you'd had to pass -DBUILDING_CEF_SHARED=1 or something *only* during libcef_dll build, and not when using it's includes in your program.

[Tux]

Hey Guys, I'm working on compiling the wrapper with mingw as well.
Did you tried (succeed ?) to link statically or dynamically with libcef_dll ?

[PolesApart]

It should work with the patches I posted (give or take a few adjustments). Someone exchanged private messages with me a while ago and had trouble with a compiler version, but swapped it and it worked.

A somewhat recent mingw64 (32 or 64 bits, they have both) should go fine.

I'm linking statically, because the libcef_dll is a (somewhat) thin wrapper around the C api exposed in libcef.dll and for me this would increase the (already high) number of dlls my project needs. libcef.dll (not libcef_dll) contains cef (and chromium and it's dependencies) and cannot be compiled with mingw (as of yet).

Also, you sort of lose the option of static linking against libstdc++ because as windows DLLs can't have unresolved symbols you'd have libstdc++ linked twice: once to libcef_dll and another to your executable, which would cause the binaries to get bigger, besides having possible side effects. If you keep the libcef_dll as a static library then you only link once to static libstdc++.

Anyway I opted to take the hit and have libstdc++ dynamically included in my project, because there are helper executables who depends on it and having them static would just waste space. YMMV.

[Tux]

Thanks for your patches, it helped me a lot and I finally managed to achieve the compilation with MinGW (4.8.1 32bits).

I'm currently working on a very simple project, integrating Cef with Qt 5.3.1 (compiled with MinGW, as you can guess). It will be available on GitHub asap, if it can help someone.

[navisrob]

Thanx Tux! Great work - it is very interesting project(I already found it on GH), as for me Qt more convenient way to design GUI. And I am wonder why there is no default mingw support.
Your project seems works perfect except of one thing: when closing app, I get error message with 80000003 code error in libcef.dll, and then one more with c000041d code (Windows 8 64-bit). I use all versions same as in readme.md. Do you have same issue?