New cef linux release or build instructions

[quirkey]

After reading around the forums I'm realizing that upgrading libcef itself on linux is not just a matter of dropping in the new headers and .so file, but that the build hosted here is different than the one provided by cefbuilds. Is it possible to upload a build of the new stable release? Or document the build process somewhere?

[cztomczak]

The Linux release was built from sources to disable tcmalloc memory allocator global hook. When CEF .so library is imported that hook will replace the default malloc implementation. As a precaution I've prepared a custom build for CEF2go to disable that, as I've had problems with tcmalloc in another project. In CEF Python when CEF was not the very first library imported then it caused random segmentation faults in app in unrelated places (eg. wx imported first and allocated memory using malloc, then cef library imported and hooked tcmalloc, if now wx tries to free its memory seg fault may occur).

If you can guarantee that CEF .so library is the first one loaded, then you don't need a custom build and could use one from cefbuilds.com. It might even not be an issue at all with Go, I don't know if that tcmalloc hook is going to cause issues in Go same as it did in Python.

You can download branch 1750 from here:
http://cefbuilds.com/#branch_1750

When updating you should compare include/capi/ directories from current cef2go binary (branch 1750 revision 1604) and the new binary (branch 1750 revision 1794). There might be some minor changes, like a new variable in one of client handlers callback was added. If so then you need to update headers in the cef2go/handlers/ directory. So basically when comparing include/capi/ directories, check any file that ends with "_handler_capi.h", whether it was modified. If it's referenced in cef2go/handlers/ then you you need to modify of what have changed. There are also a few non-handlers imported, these are: cef_base_capi.h, cef_client_capi.h and cef_app_capi.h - you should check modifications for these as well. I don't think that there would be any more changes, but if some basic function like cef_create_browser was modified (or one of the keys in cef_settings_t that are exposed by cef2go), then you would also need to make changes in src/cef/cef.go.

If you need to build from sources with tcmalloc disabled, then see here on how to disable it:
https://code.google.com/p/cefpython/wiki/BuildOnLinux#Disable_the_tcmalloc_memory_allocation_global_hook_(optional,_bu

[cztomczak]

Build instructions for CEF are here:
https://code.google.com/p/chromiumembedded/wiki/BranchesAndBuilding

You may as well use the instructions from CEF Python, but some sections that are cefpython specific should be ignored:
https://code.google.com/p/cefpython/wiki/BuildOnLinux

[cztomczak]

After a second thought, I don't think tcmalloc hoook needs to be disabled. In Python the CEF library is dynamically initialized/loaded during program execution. I don't think this is the case with Go, as it's a compiled language and I think CEF library is initialized before main program is executed. During that initialization of library the tcmalloc allocator is globally hooked. In C++ tcmalloc hook is not an issue, so it also shouldn't be an issue in Go. I think it should be safe to use builds from http://cefbuilds.com without need to compile Chromium from sources.

[quirkey]

@CzarekTomczak I was actually just updating this issue! I finally tried building with a cefbuilds version last week and with a little twiddling was able to get it to work. See: paperlesspost/cef2go@master...upgrade_to_2272

Besides some header and api related changes, the biggest change is that new CEF actually no longer relies on GTK for linux which makes booting and doing offscreen rendering like we are MUCH faster and easier and requires less dependencies. Unfortunately it didnt fix #8 and I'm still trying to debug and figure that out.

It also changed the way the path structure had to be laid out (a bunch of files are now hard-coded to have to be in the same dir as the application binaries), so theres some work to do in figuring out how to make that simpler.

[cztomczak]

I see that you use the --single-process flag. Know that this mode is not stable and is meant only to ease debugging.

When using the --disable-gpu flag you should probably also set the --disable-gpu-compositing. Not sure why, but both these flags seem to be inherent in examples provided by Marshall. See CEF Issue 1368 (https://code.google.com/p/chromiumembedded/issues/detail?id=1368).

[cztomczak]

See comment #13 in that issue that explains that flag and some other OSR issues: https://code.google.com/p/chromiumembedded/issues/detail?id=1368#c13

[quirkey]

Interesting - will definitely try those flags now.

RE: single-process, been going back and forth with this because when
registering JS callbacks they will happen in the child process and not the
parent process (which causes some difficult to work around communication).
We've been experimenting with both ways and other then #8 haven't seen any
other issues related to it (for our use case). I'm using it here because it
makes the testing easier - using single-process means that the main_linux
app will exit cleanly (0) with a success and (1) if boot fails. This makes
running that restart test much easier. I tested with both single-process on
and off and it didnt seem to actually affect the boot stability.

On Thu, Feb 12, 2015 at 3:43 PM, Czarek Tomczak notifications@github.com
wrote:

See comment #13 #13 that
explains that flag and some other OSR issues:
https://code.google.com/p/chromiumembedded/issues/detail?id=1368#c13

—
Reply to this email directly or view it on GitHub
#16 (comment).