Is it possible to build chrome Browser (windows specific) on linux ?

[Suraj Shaha]

Hello,

I have downloaded and sync up the code from google server(chromium.org),but It is taking too much to build on windows (Which is frustrating coz it may take 4 hours).

Is it possible to build windows code on linux ? (would it be faster version in terms of compilation time).

Regards,

Suraj

[Torne (Richard Coles)]

No. We only support using each platform's native toolchain.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Suraj Shaha]

Hello,

I sort of rookie on this project and just started off on this project so just would like to know about:

1.Does it require to build whole chain (all the components) to build Chrome Browser ?

2. Which version is faster in terms of building time linux or windows ?

Thanks for the help.

Regards,

Suraj

[Torne (Richard Coles)]

Please keep the list as a recipient so other people can find this in the archives :)

On 9 August 2013 10:49, Suraj Shaha <suraj....@gmail.com> wrote:

Thanks for the quick response.

Just want to know that Which version is faster linux(native) or winodws(native) ?

The linux build is much faster.

 

Regards,

Suraj

[Torne (Richard Coles)]

Again, please keep the list as a recipient. We don't answer these questions solely for a single person's benefit.

On 9 August 2013 11:09, Suraj Shaha <suraj....@gmail.com> wrote:

Does it require to build whole chain (all the components such as android,iphone,mac) to build Chrome Browser ?

Android, iphone and mac are not components of Chrome, they are the different platforms we support. When you build for a given OS it only builds code for that OS, but it builds *every* component of Chrome used by that OS.

 

[rod.d...@gmail.com]

When you say that it builds every component of Chrome used by that OS, you mean Chrome application specific components and not the supporting libraries?  For example, it doesn't build the Freetype library or the GLibc library.  To that end, I wonder what the point of the third-party directory is in the source tree, as it does contain a Freetype entry.  Is there a way to have the build compile that Freetype and use the result as opposed to picking one up from the system you are compiling on? 

Thanks,

Rodney

  

[Torne (Richard Coles)]

On 20 September 2013 12:32, rod.d...@gmail.com <rod.d...@gmail.com> wrote:

When you say that it builds every component of Chrome used by that OS, you mean Chrome application specific components and not the supporting libraries?  For example, it doesn't build the Freetype library or the GLibc library.  To that end, I wonder what the point of the third-party directory is in the source tree, as it does contain a Freetype entry.  Is there a way to have the build compile that Freetype and use the result as opposed to picking one up from the system you are compiling on? 

The copy of freetype in third_party/freetype is statically linked into Chrome on Android, and isn't used at all on other OSes.

The copy in third_party/freetype2 appears to be for content_shell and isn't used by Chrome itself on any OS.

We only use the system libraries that we can rely on being there and up to date, and that we don't need to make changes to. Everything else gets built from third_party and statically linked into the binary. Exactly which libraries are built depends what platform and build settings you use. There are various gyp flags called use_system_* which switch to using the system version of a given library, but they all typically default to off.

[Dirk Pranke]

As Richard says, the version of Freetype in particular is used for testing purposes by content_shell, so that we can get the same text rendering on linux for tests regardless of what is installed in the O/S.

The line between what is checked into third_party and what we install (or expect to be installed) is a little fuzzy on Linux, as you can see from looking at the long list of things we expect to be installed by install-build-deps.sh.

-- Dirk

[rod.d...@gmail.com]

Thanks for the information.  So I realize that you do not support building for one OS on an OS that is different (i.e. Building for Linux on Windows).  If someone wanted to build Chrome for a platform that you do not currently support, where do you start to put in your OS defines for the build.  It looks to me like the gyp application grabs the OS from the Python environment.  Is there a way to override that or does gyp itself need to be modified?  Also, does this entail that every gyp and gypi file needs to be updated to include a reference to that new platform?  I guess what I am asking is, how to you go about setting up a build for a platform that you can't actually build on, and is completely separate from your build host.  Android is somewhat of an example, but it still sort of boils down to a "Building on Linux, for Linux (with some android caveats)" 

Thanks,

Rodney

[Torne (Richard Coles)]

You can set OS to anything you like with GYP_DEFINES or -D, it's just a gyp variable. The *default* value is determined by gyp testing python's idea of what platform it's on, but you can override it, and this is how the Android/iOS builds work.

Yes, you will have to modify every gyp file that needs platform-specific changes for your new platform to include references to the sources/defines/libraries/etc that are correct for that platform, and also provide the sources to match.

The makefiles/ninja files generated by gyp don't really currently support crosscompiling for a platform that doesn't have a broadly compatible toolchain; it assumes that the same kinds of linker arguments/etc apply to both. This is one of the reasons why you can't currently build the Android version of Chromium on Mac OS X - it assumes that the host linker takes GNU options that Apple's ld does not support, and fails to link any host binaries. I've looked at fixing this several different ways but haven't found an approach I particularly like and it's not a use case we are in a big rush to do anything about.

There aren't really any instructions on how to do this. You will, probably, have to modify gyp as well if your host/target toolchains aren't basically the same thing, though you might get by without doing this and still be able to compile some easy targets like base_unittests (until you start building parts like protoc and v8 that need host binaries). You will have to modify lots of the Chromium sources and gyp files. The only "documentation" on how to do this is, as you have seen, the existing Android/iOS ports.

The people porting Chromium to other OSes (BSD, etc) are not generally crosscompiling and so don't have many of these problems, and it's much easier.

What OS are you targeting? Is it broadly POSIX-compatible? Does it have a standard gcc/binutils based toolchain?

[rod.d...@gmail.com]

We are targeting a couple of different OS's.  One is QNX, which should be fairly straightforward.  It's pretty compatible with the Linux model.  When I had originally started looking at the port, I thought it would be possible to just have the build system build everything that I needed, but I ran in to problems setting up the include paths and telling the build that I wanted to build stuff out of the third_party repository.  Also I found I was hacking and slashing through the gyp files to the point where it was not maintainable so I decided to take a step back and see about approaching it the right way by setting up an OS target for QNX.  It has a standard set of gcc/binutils based toolchain, but some of the options are different.  I created a QNX make generator for gyp just to change how some of the compiler flags are passed through because the order is important with the QNX compiler.  I was going to look in to writing a ninjaqnx generator because ninja is just soooooo much faster to build with.  I would be doing this on a Linux system.  Is this an okay approach, creating your own generator for a target?

I don't necessarily have to cross compile in the QNX case, but I am not sure if all the support libraries and binaries are available for the QNX x86 platform.  Plus builds would be slow as it would be in a VMWare session.

This is good info to have.  I did not realize that there was a bootstrapping part to the build process where you are building host tools to run some commands.  What are the host binary needs in the case of something like v8?  Are they needed even in cases of where you are compiling something like CEF?  Why are the host binaries not built ahead of time and checked in to depot tools for a particular revision?  

Also, one more question on dependencies.  I noticed that CEF for example on Linux has a dependency for cairo.  Is cairo used to take the output from the skia generated rendering and place it on the screen?  In other words, Cairo is used to render on the OS, but SKIA is used by Chrome to render it's components in to a buffer, and then that buffer is converted to something Cairo can recognize and then Cairo renders that to the screen? 

  

[Torne (Richard Coles)]

On 25 September 2013 17:10, rod.d...@gmail.com <rod.d...@gmail.com> wrote:

We are targeting a couple of different OS's.  One is QNX, which should be fairly straightforward.  It's pretty compatible with the Linux model.  When I had originally started looking at the port, I thought it would be possible to just have the build system build everything that I needed, but I ran in to problems setting up the include paths and telling the build that I wanted to build stuff out of the third_party repository.  Also I found I was hacking and slashing through the gyp files to the point where it was not maintainable so I decided to take a step back and see about approaching it the right way by setting up an OS target for QNX.  It has a standard set of gcc/binutils based toolchain, but some of the options are different.  I created a QNX make generator for gyp just to change how some of the compiler flags are passed through because the order is important with the QNX compiler.  I was going to look in to writing a ninjaqnx generator because ninja is just soooooo much faster to build with.  I would be doing this on a Linux system.  Is this an okay approach, creating your own generator for a target?

The generator will fall out of sync as gyp changes are made. If you need generator changes (e.g. to pass different linker command lines) you should make these upstream in gyp. The make and ninja generators both have OS-specific parts already, the gyp maintainers will accept patches that add another OS as long as your patches are reasonable and ideally have some test coverage.

 

I don't necessarily have to cross compile in the QNX case, but I am not sure if all the support libraries and binaries are available for the QNX x86 platform.  Plus builds would be slow as it would be in a VMWare session.

This is good info to have.  I did not realize that there was a bootstrapping part to the build process where you are building host tools to run some commands.  What are the host binary needs in the case of something like v8?  Are they needed even in cases of where you are compiling something like CEF?  Why are the host binaries not built ahead of time and checked in to depot tools for a particular revision?

The whole of V8 is built for the host, and used to generate a precompiled snapshot of the initial javascript state, which is compiled into the target's V8 to save it needing to bring up the VM from scratch every time. You need this no matter what you are building and the host and target V8 must exactly match for this to work (same source code, same gyp flags). There are other host tools as well, I don't know all of them; they aren't all required to build something simple like content_shell but they are pretty much all needed to build the full chrome target. We don't precompile host tools, because 1) we'd have to recompile them constantly as the code changes and 2) we'd have to compile them for a bunch of different platforms which is logistically a pain. Our supported platforms have no problems building host and target tools separately when needed so we are unlikely to change anything about this.

 

Also, one more question on dependencies.  I noticed that CEF for example on Linux has a dependency for cairo.  Is cairo used to take the output from the skia generated rendering and place it on the screen?  In other words, Cairo is used to render on the OS, but SKIA is used by Chrome to render it's components in to a buffer, and then that buffer is converted to something Cairo can recognize and then Cairo renders that to the screen? 

Currently the Linux version uses GTK to draw widgets, and so can't avoid depending on Cairo (it also uses Cairo directly in some cases just to throw the pixels Skia has rendered into X as you guessed). The Aura version of the UI that's being worked on doesn't use GTK; I don't think we use Cairo either in this configuration but I'm not sure. Aura on Linux is not finished yet, though.

[rod.d...@gmail.com]

The whole of V8 is built for the host, and used to generate a precompiled snapshot of the initial javascript state, which is compiled into the target's V8 to save it needing to bring up the VM from scratch every time. You need this no matter what you are building and the host and target V8 must exactly match for this to work (same source code, same gyp flags). There are other host tools as well, I don't know all of them; they aren't all required to build something simple like content_shell but they are pretty much all needed to build the full chrome target. We don't precompile host tools, because 1) we'd have to recompile them constantly as the code changes and 2) we'd have to compile them for a bunch of different platforms which is logistically a pain. Our supported platforms have no problems building host and target tools separately when needed so we are unlikely to change anything about this.

Interesting.  Is this one of the reasons why there isn't a PPC version of V8.  I would have to think that this approach would fail in the case where endianness changes.  So can this step be notched out if need be? Can the target library be brought up from a 0 config state?

[Torne (Richard Coles)]

On 25 September 2013 18:26, rod.d...@gmail.com <rod.d...@gmail.com> wrote:

The whole of V8 is built for the host, and used to generate a precompiled snapshot of the initial javascript state, which is compiled into the target's V8 to save it needing to bring up the VM from scratch every time. You need this no matter what you are building and the host and target V8 must exactly match for this to work (same source code, same gyp flags). There are other host tools as well, I don't know all of them; they aren't all required to build something simple like content_shell but they are pretty much all needed to build the full chrome target. We don't precompile host tools, because 1) we'd have to recompile them constantly as the code changes and 2) we'd have to compile them for a bunch of different platforms which is logistically a pain. Our supported platforms have no problems building host and target tools separately when needed so we are unlikely to change anything about this.

Interesting.  Is this one of the reasons why there isn't a PPC version of V8.

No, there isn't a PPC version of V8 because nobody has done the work to write a PPC code generator and keep it in sync with the latest V8. V8 already handles host and target being different architectures just fine, we build V8 for x86, amd64, arm and mips all from any host platform.

 

I would have to think that this approach would fail in the case where endianness changes.

I don't think so, but I'm not sure. I know it doesn't work (or at least didn't the last time I checked) if the size of the integer types is different: you have to use a 32-bit host V8 to generate a 32-bit target V8's snapshot (but this isn't a real problem in practise since amd64 can run x86 binaries, so you just build with -m32).

 

 So can this step be notched out if need be? Can the target library be brought up from a 0 config state?

Possibly, but I don't think there's any existing configuration option for this. I don't think you will get far by trying to eliminate building host binaries, though; there are quite a few. If you can get *any* host binaries to build at all, then all host binaries should build; there shouldn't be anything specific to V8 about it.

[rod.d...@gmail.com]

Possibly, but I don't think there's any existing configuration option for this. I don't think you will get far by trying to eliminate building host binaries, though; there are quite a few. If you can get *any* host binaries to build at all, then all host binaries should build; there shouldn't be anything specific to V8 about it.

I am not so much worried about building the host binaries.  I am more concerned about the effect of running a Linux host binary and generating a VM dump for a QNX target library.  I would worry that there would be some subtle difference in memory layout or something along those lines that would make the library unstable when running on the target.  I suppose though that if you are generating an Android target V8 library from a bunch of different host Linux OS's (Ubuntu, Arch, Fedora) then it isn't that much of a stretch that you can go from one OS to another.  The only thing with that is that the Android OS is based on a Linux OS so they are at least in the same family tree. 

Anyways, this is more of a "I'll have to try it to see what happens" sort of thing.  Thanks again for the information.  You've given me more than enough to get started. 

Take care,

Rodney

[Torne (Richard Coles)]

I believe the VM snapshot is constructed such that the memory map doesn't matter, but I'm not an expert on V8 internals (but I maintain parts of the Android build so am familiar with the build process). I doubt it depends on any fixed memory locations as this would be a security risk.

[Milan Thapa]

Hey, little late for the show, I wonder if you found some trickery to build the binaries using linux. or any ways to speed up the build process using the windows :(

[Nico Weber]

Building chrome/win on linux isn't supported. It kind of works with lots of local hacks, https://codereview.chromium.org/1183633003/ is a sketch. Eventually it might be easier.

The biggest speedup for (incremental) builds is probably to set is_component_build=true. Also only build the binary you need, not all of them -- say `ninja -C out/gn chrome` instead of `ninja -C out/gn` for example. content_shell builds faster than chrome, so if you work on the renderer part, maybe you can build that instead of chrome.

--