Linux Support

[GoogleCodeExporter]

Google Chrome on Linux has hit the dev channel. I would like to know for my 
own evaluation where linux support might fall on the roadmap.

Thanks!

Original issue reported on code.google.com by mark.ren...@gmail.com on 2 Jul 2009 at 4:20

[GoogleCodeExporter]

@comment#50: Thanks, fixed in revision 380.

Original comment by magreenb...@gmail.com on 16 Nov 2011 at 10:07

[GoogleCodeExporter]

Haven't tested these on Windows/Mac yet, but on my Linux r406 Release build:

1. The "Test DragDrop" test does not seem to work at all
2. The "DOM Access" test does not repaint after button is pressed (repaint can 
be forced by resizing the window)
3. Segmentation fault reproducible by performing "Popup Test" multiple times

Original comment by axton.ma...@gmail.com on 8 Dec 2011 at 1:22

[GoogleCodeExporter]

Attaching 3 patches
0004) Adds Drag and Drop support for linux
0003)  fixes gtk client to properly shutdown on CTRL+c
0002) Allow project re-generation even when there is no .svn folder available 
(ie, when you are using git-svn)

Original comment by p...@spotify.com on 5 Jan 2012 at 5:34

Attachments:

• 0002-tools-Make-it-easier-to-use-git-svn.patch
• 0003-cefclient_gtk-Properly-shut-down-from-signal-handler.patch
• 0004-linux-Add-Drag-and-Drop-support.patch

[GoogleCodeExporter]

There is still this lingering issue, when calling the libcef.so from a host 
process not located inside the lib's directory for instance when calling from a 
ruby, mono or python application.
The chrome.pak will be assumed to be located inside the host dir (aka 
/usr/bin/) which is obviously wrong. I would suggest adding a path member to 
the CefSettings class that makes it possible to specify the pak location.

In addition I would like to suggest removing the #if(WINDOWS) ... # endif 
statement from the cef_settings_t struct, since it alters the c api interface 
on windows which makes explicitly hard for runtime aware frameworks, as in mono 
to bootstrap on multiple platforms without the need for platform creating 
platform specific binaries.

Original comment by krasshir...@googlemail.com on 6 Jan 2012 at 1:30

[GoogleCodeExporter]

It is not only problem with chrome.pak! Any additional dynamic libraries (mpeg) 
also will be loaded from host application directory, that of course invalid. 
LD_LIBRARY_PATH also is useless. I hope it will be enough to override "base 
path" directory in PathService, or provide own PathService implementation.

Original comment by fdd...@gmail.com on 6 Jan 2012 at 1:48

[GoogleCodeExporter]

For some reason, every revision since revision 426 has crashed on startup with 
the following output, any ideas?:

$ ./cefclient

#
# Fatal error in v8/src/serialize.cc, line 1063
# unreachable code
#

==== Stack trace is not available ==========================

==== Isolate for the thread is not initialized =============

Aborted

Original comment by axton.ma...@gmail.com on 6 Jan 2012 at 10:45

[GoogleCodeExporter]

@comment#53:

0004+0003) Thanks, drag&drop support committed in revision 475 with style 
changes. Please use the check_style tool in the future to check for style 
problems.
0002) Already fixed in revision 458.

@comment#54:

Please add your chrome.pak comments to issue #236.
Please create a separate issue for your "removing the #if(WINDOWS)" request.

@comment#56:

I'm not seeing the serialize.cc problem on Ubuntu 11.10 64bit. What distro and 
version are you using?

Original comment by magreenb...@gmail.com on 23 Jan 2012 at 7:06

[GoogleCodeExporter]

@comment#55: Can you create a separate issue describing the PathService problem 
in detail with your proposed solution? Thanks.

Original comment by magreenb...@gmail.com on 23 Jan 2012 at 7:14

[GoogleCodeExporter]

Not sure where along it got fixed, but I can no longer reproduce comment#56 
using revision 475.  For future reference, I am testing CEF using Gentoo ~amd64 
distro.

Original comment by axton.ma...@gmail.com on 23 Jan 2012 at 10:34

[GoogleCodeExporter]

There's no support for off-screen rendering on linux, correct?

Original comment by george...@gmail.com on 26 Jan 2012 at 6:10

[GoogleCodeExporter]

@comment#60: correct.

Original comment by magreenb...@gmail.com on 26 Jan 2012 at 6:19

[GoogleCodeExporter]

a patch for src/cef@522 to reflect current chromium changes - built on linux, 
links and runs

Original comment by eviliss...@gmail.com on 9 Mar 2012 at 8:27

Attachments:

• cef.patch

[GoogleCodeExporter]

Would be nice if someone could upload a Linux binary. I myself have never seen 
any working Linux binary. The farthest I got was a linking issue somewhere 
between gold and ld linker around 80%. 

Additionally I was wondering if there's any 64bit version of chromium at all? 
Even Chrome is only 32bit on a 64bit environment. 

Original comment by Johannes...@gmail.com on 21 Mar 2012 at 2:44

[GoogleCodeExporter]

@comment#63: There are many Linux distros, it would be difficult for us to 
provide binaries that work for any significant percentage of users. CEF 
supports both 32bit and 64bit builds on Linux.

Original comment by magreenb...@gmail.com on 21 Mar 2012 at 2:59

[GoogleCodeExporter]

@comment#64: I've been regularly using chromium built for Ubuntu on Arch Linux, 
I don't see any reason why similar thing wouldn't work with CEF. As long as the 
major versions of ld and dynamically linked libraries match things should work 
quite well.

As for myself, I would appreciate Linux binary a lot, since I has never been 
able to compile CEF on Arch Linux. (The reason being probably python3, even 
though I tried really hard to use python2 in all the build scripts...)

Original comment by dolik.rce on 21 Mar 2012 at 3:12

[GoogleCodeExporter]

Closing this bug because Linux support is in pretty good shape now. Please file 
new bugs for any future Linux issues.

Original comment by magreenb...@gmail.com on 29 Apr 2012 at 2:55

• Changed state: Done