Re: [chromium-dev] Faster linking for chromium on ubuntu
On Thu, Dec 31, 2009 at 7:24 PM, n179911 n179...@gmail.com wrote:
On Thu, Dec 31, 2009 at 3:17 PM, Dan Kegel d...@kegel.com wrote:
On Thu, Dec 31, 2009 at 3:14 PM, n179911 n179...@gmail.com wrote:
And I have put 'shared' library in my include gypi file
$ more ~/.gyp/include.gpyi
{'variables': {
'library': 'shared_library',
}}
How can I make sure that it is building in shared library and using
the gold linker?
I find linking chromium is still take a long time (~ 10 minutes) on my
machine.
Is it definitely the chrome link command that is taking 10 minutes, or
linking in general? Some of the shared libs, especially in debug
build, are very large, so will still take a while to link. The main
benefit is that the actual executables, like chrome, test_shell, etc.,
will no longer duplicate that shared lib code, so collectively they
should be much smaller and link much faster.
Did you rerun gyp, e.g. with the command
glient runhooks --force
after changing ~/.gyp/include.gypi ?
Yes, I did run 'glient runhooks --force' before I run 'make
out/Debug/chrome' again.
When I build chromium as a shared library, will the result binary(ies)
be different, is there something I can check to make sure the chromium
I built is 'shared library'?
Do you have a lib.target directory full of .so files in your build
output? Does 'ldd chrome | grep libv8' match anything? If so, you have
a proper shared library build.
Michael
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] [Linux] New build deps (jpeg, xslt)
This is back in. XSLT is no longer required (though it doesn't hurt to have it), and it seems some machines are also missing bzip2 headers, so for Hardy, the new command to install the deps is: sudo apt-get install -y libbz2-dev libjpeg62-dev After you update your packages and sync your sources, you may also need to clobber your build in order to switch to the system headers. Michael On Wed, Dec 9, 2009 at 5:33 PM, Michael Nordman micha...@google.com wrote: There were several crashing layout tests on linux when loading .xml files shortly after this (and a little later, a webkit roll) was landed. We've reverted both this change and the webkit roll, but i'm thinking the xslt changes may have more to do with the crashes then the webkit roll? The try servers were happy with the roll, things just went awry once it got landed on the trunk. On Wed, Dec 9, 2009 at 3:57 PM, Michael Moss mm...@chromium.org wrote: A recent change to use more system libs (http://src.chromium.org/viewvc/chrome?view=revrevision=34195) might break Linux builds. If you see messages about missing jpeg or xslt headers, please install the relevant -dev packages. For instance, on Hardy you would run: sudo apt-get install -y libxslt1-dev libjpeg62-dev Michael PS - Due to other issues, libxslt might change back to being a static lib, but it shouldn't hurt to install the -dev package either way. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [Linux] New build deps (jpeg, xslt)
A recent change to use more system libs (http://src.chromium.org/viewvc/chrome?view=revrevision=34195) might break Linux builds. If you see messages about missing jpeg or xslt headers, please install the relevant -dev packages. For instance, on Hardy you would run: sudo apt-get install -y libxslt1-dev libjpeg62-dev Michael PS - Due to other issues, libxslt might change back to being a static lib, but it shouldn't hurt to install the -dev package either way. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Symbolized backtrace on Linux chromium?
On Mon, Nov 30, 2009 at 9:58 AM, Evan Martin e...@chromium.org wrote: On Mon, Nov 30, 2009 at 9:37 AM, Chris Bentzel cbent...@google.com wrote: When DCHECK's trigger on my debug chromium build, I get an unsymbolized stacktrace like [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: !request_. [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: !request_. Backtrace: out/Debug/chrome [0x8d7d9bc] out/Debug/chrome [0x8d99838] out/Debug/chrome [0x8fba726] [...] Is there a reason I'm not getting symbols to display here? We have a test covering this: ./out/Debug/base_unittests --gtest_filter=StackTrace* Running it locally reveals that it is broken -- but the bots still work? It looks like there isn't a debug builder that runs base_unittests. It's the release build that passes. Michael -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Link error when compiling chromium on ubuntu 9.10
You could also try adding swap. It isn't ideal, but it might at least let you build until you can add more RAM. It can take about 4GB to link a debug build. Another option is to build in release mode, which should require less RAM. Michael On Mon, Nov 23, 2009 at 12:12 AM, Craig Schlenter craig.schlen...@gmail.com wrote: On Mon, Nov 23, 2009 at 9:59 AM, hap 497 hap...@gmail.com wrote: Hi, I am tying to compile chromium on ubuntu 9.10. I think the compilation went fine. I just get an error in linking. $ make -j5 chrome LINK(target) out/Debug/chrome collect2: ld terminated with signal 9 [Killed] make: *** [out/Debug/chrome] Error 1 $ make out/Debug/chrome LINK(target) out/Debug/chrome collect2: ld terminated with signal 9 [Killed] make: *** [out/Debug/chrome] Error 1 and i don't think i have a disk space problem since i check the df output: You probably need more RAM or you should just use the gold linker (see the wiki). --Craig $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 14784680 10044024 3989620 72% / udev 383892 216 383676 1% /dev none 383892 360 383532 1% /dev/shm none 383892 92 383800 1% /var/run none 383892 0 383892 0% /var/lock none 383892 0 383892 0% /lib/init/rw Thanks for any tip. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [Linux] 'make' build maintenance
If you don't build with 'make', you can ignore this message.
Recent gyp changes have rearranged the 'obj' output directory for make
builds. This shouldn't affect how you build, but it will result in a
bunch of orphaned object files from previous builds, which might be
confusing, and will definitely waste space ('obj' can be several GBs
for a debug build). You may want to clobber your build directory as a
precaution.
Michael
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: How can we kill scons?
To follow up on this thread, for people who didn't see the related gyp-developer discussion, I submitted the last make fix for the gyp tests today. This was my minimum sanity check before switching any buildbots over to make. I might start with some FYI bots this weekend, then do the main bots next week, though I'll probably wait on that until I have a chance to check on Evan's compile twice issue and get a test case for it. Michael On Thu, Oct 29, 2009 at 2:55 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: I've updated the LinuxBuildInstructions, and moved the old instructions to LinuxSconsBuild which parallels LinuxMakeBuild. I also made a quick attempt at searching for scons in both the Wiki and the Sites pages and updated whatever looked appropriate. Step #1 down. -Albert On Wed, Oct 28, 2009 at 1:47 PM, Antoine Labour pi...@google.com wrote: On Wed, Oct 28, 2009 at 1:37 PM, Evan Martin e...@chromium.org wrote: On Wed, Oct 28, 2009 at 1:23 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: I actually got some weird warnings on the make build a while back when I specified the same file in two sources entries...something about circular dependencies and make ignore one. But don't remember the exact scenario. I betcha it isn't a problem in chrome cause it'd only trigger a bug if the file was compiled with different flags that modified behavior. Since our defines and compiler options are so stable (especially within one target), building once probably doesn't break stuff... Currently, as far as I know, no files in Chrome require this compile twice behavior. I am skeptical of the utility of gyp features that are unused by Chrome. But this may be the magic bullet to make -fPIC on 64-bit work. I think I still see situations where the generated strings aren't properly rebuilt in the make build. You have to run it twice. At this point, given the number of people hammering on it, I suspect the gyp rules are wrong and that the make build parallelizes too aggressively, but that is likely just wishful thinking and there's a subtle bug in there. :( That means for the build bots to switch, they need to always run make twice to be sure everything was built. (PS: currently every time you run make it rebuilds some NACL stuff too. I am so tired of NACL busting my build that I just turned it off locally.) That was a regression that I think I fixed. Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] how to work around nacl errors in 64-bit build
To update, the issue will probably be resolved in gyp. Nacl has a bit of an unusual build configuration, but it should probably be supported. There is a discussion on the gyp developers list looking into the best way to accommodate it. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Change to default build architecture
http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Change to default build architecture
On Thu, Oct 15, 2009 at 8:59 PM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES=target_arch=ia32, of course. I haven't looked into it yet, but NaCl apparently has it's own notion of target_arch. For now, the best bet is probably explicitly setting GYP_DEFINES as you're doing. Michael On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss mm...@chromium.org wrote: http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: buildbot bisect script
I'm making this generic, in case anyone else was planning on tackling it. On Thu, Sep 3, 2009 at 4:29 PM, Evan Martine...@chromium.org wrote: Robert Sesek nicely checked his in at build/build-bisect.py. It's mac-specific for now, but the next time you need to bisect builds on another platform I suggest improving it. On Thu, Sep 3, 2009 at 10:30 AM, Evan Martine...@chromium.org wrote: I feel a couple of people have written scripts to bisect builds pulled from http://build.chromium.org/buildbot/continuous/ . Can we check one of those in? I can review. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux startup regression
Should we be archiving perf tests so we can backtrack these regressions more easily? For instance, Windows archives some tests (e.g. http://build.chromium.org/buildbot/continuous/LATEST/chrome-win32.test/), though startup isn't one of them. Michael On Thu, Sep 3, 2009 at 9:47 AM, Michael Mossmm...@chromium.org wrote: The bot that builds and runs these tests is a dedicated 32-bit machine. On Thu, Sep 3, 2009 at 9:38 AM, Evan Martine...@chromium.org wrote: On Thu, Sep 3, 2009 at 9:33 AM, Brett Wilsonbre...@chromium.org wrote: On Thu, Sep 3, 2009 at 9:26 AM, Evan Martine...@chromium.org wrote: Ok, I'll mark that I own this here and unassign it if I can't figure it out: http://code.google.com/p/chromium/issues/detail?id=20991 On Thu, Sep 3, 2009 at 2:41 AM, Dean McNameede...@chromium.org wrote: Ug, I can't reproduce this on my desktop. If I had to take a guess, I would guess Brett's gfx::Font change. It could be my font change. It does measure some extra text on startup. But I would have thought this was nothing compared to the text we already measure. Random idea: did someone switch our builders to build 64-bit binaries now? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: buildbot bisect script
Yeah, I don't know what the purge policy is, but currently we have complete build snapshots going back about 2 months: http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/ On Thu, Sep 3, 2009 at 11:55 AM, Evan Martine...@chromium.org wrote: From IRC, nsylvain says we keep at least one green build a day forever. So the archive *should* go back far enough, but with less resolution in ancient history. PS: I also learned that among buildbot archives, snapshot = every build, while continuous = every *green* build. On Thu, Sep 3, 2009 at 11:52 AM, Lei Zhangthes...@chromium.org wrote: I've heard a few complains of I cannot bisect because the archive does not go that far back. Are we tight on storage? It would be nice if we can keep more of the continuous builds around. On Thu, Sep 3, 2009 at 10:30 AM, Evan Martine...@chromium.org wrote: I feel a couple of people have written scripts to bisect builds pulled from http://build.chromium.org/buildbot/continuous/ . Can we check one of those in? I can review. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
Awesome! I'll work on the buildbot, then start marking all the ia32-libs bugs invalid :) On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
Anybody working on 64-bit breakpad yet? src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code has not been ported to your platform yet I guess worst case, I can turn this off for official 64-bit builds right now. Michael On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
I haven't sent it yet because it's broken on the Mac due to that gyp regex bug we talked about this morning. I'm currently hacking at gyp to see how best to rewrite that regex. You can preview the Chrome change at http://codereview.chromium.org/149781. Michael On Fri, Jul 17, 2009 at 1:12 PM, Mark Mentovaim...@chromium.org wrote: I don't think I've seen it. Is it gonna work on the Mac? Evan Martin wrote: On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
I agree. I thought we wanted to avoid that kind of bloat, which is why I went the helper script route instead of pestering for loops. If we add too many features, pretty soon we'll just have scons-NG (not that there's anything wrong with that, but I don't understand that to be the goal of gyp). Michael On Fri, Jul 17, 2009 at 1:14 PM, Bradley Nelsonbradnel...@google.com wrote: Yeah I feel like loops take things to a bad bad place If we can avoid adding it, that would be ideal. -BradN On Fri, Jul 17, 2009 at 1:10 PM, Evan Martin e...@chromium.org wrote: On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Help with linux build error
BTW, the mac script has the same thing (I added the -nt on Mark's suggestion), but maybe on mac it behaves differently so it's OK. Do we have a mac builder that's running dump_app_syms? Michael On Wed, Jun 17, 2009 at 2:59 PM, Adam Langleya...@chromium.org wrote: On Wed, Jun 17, 2009 at 2:41 PM, Adam Langleya...@chromium.org wrote: On Wed, Jun 17, 2009 at 2:33 PM, Mark Larson (Google)m...@chromium.org wrote: This is happening on a new Google Chrome Linux builder on the 'experimental' waterfall: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Google+Chrome+XPbuilder=Google+Chrome+Linuxreload=60 The linux compile fails here: I think this is mmoss, or maybe thestig. It's a symbol dumping process which is failing. I think there's a bug in the script, -nt doesn't work when the output doesn't exist. I'll fix it now. I may, or may not have, fixed this in r18659. I'll wait for the builder to cycle round. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Help with linux build error
On closer inspection, it looks like it's a bash vs. dash issue. Our Linux official builder (gHardy) is using bash (probably the Mac is too), so the original syntax works. This experimental bot (regular Hardy) is using dash, so '-nt' fails when the file doesn't exist. Adam's fix should make both happy. Michael On Wed, Jun 17, 2009 at 3:12 PM, Mark Larson (Google)m...@chromium.org wrote: Thanks, for the fix Adam. On Wed, Jun 17, 2009 at 15:04, Michael Moss mm...@chromium.org wrote: BTW, the mac script has the same thing (I added the -nt on Mark's suggestion), but maybe on mac it behaves differently so it's OK. Do we have a mac builder that's running dump_app_syms? I'd guess only the official release builder is running that, and it succeeded yesterday. We don't have a continuous Google Chrome builder on Mac, yet. Michael On Wed, Jun 17, 2009 at 2:59 PM, Adam Langleya...@chromium.org wrote: On Wed, Jun 17, 2009 at 2:41 PM, Adam Langleya...@chromium.org wrote: On Wed, Jun 17, 2009 at 2:33 PM, Mark Larson (Google)m...@chromium.org wrote: This is happening on a new Google Chrome Linux builder on the 'experimental' waterfall: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Google+Chrome+XPbuilder=Google+Chrome+Linuxreload=60 The linux compile fails here: I think this is mmoss, or maybe thestig. It's a symbol dumping process which is failing. I think there's a bug in the script, -nt doesn't work when the output doesn't exist. I'll fix it now. I may, or may not have, fixed this in r18659. I'll wait for the builder to cycle round. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
By the way, since this apparently hasn't been discussed as widely as I had thought, here's a little background on this new nss/nspr stuff. We currently build Linux Chromium with the system nss and nspr libraries. This works fine for most 32-bit distros, since these are standard packages, and that allows us to leverage the distro for critical security updates. This functionality is not going away; it will still be possible to build against the system versions of these libs, and this is how we expect distro maintainers will build their packages. However, our own target platform of 64-bit Ubuntu Hardy doesn't provide these libraries in 32-bit form, so Chromium won't run on an unmodified version of that distro (note the hoops our Linux development instructions jump through to setup a build machine). To support dogfooding on our target platform, and to provide a compatibility option for 64-bit distros in general, we decided to include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Michael On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten thoma...@chromium.org wrote: Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
This would certainly make things a lot easier. One issue I can think of is that we currently bundle a modified sqlite, and nss uses sqlite. Part of the plan was for our bundled nss to use our sqlite (since that's another 32-bit lib which is missing on Hardy). We can still do this with borrowed .so's, but I'm not sure if our changes to sqlite would have any implications for nss compiled against a different version (someone more familiar with our sqlite changes might know if this is an issue or not). Michael On Thu, Feb 26, 2009 at 9:48 AM, Dean McNamee de...@chromium.org wrote: I don't understand why we need to import all of this code just so we can build an .so. Why don't we just take the .so's from the 32-bit package we're already using, and stick them into our .deb? We can check them into svn if don't want developers to have to have it, but that problem is already solved by the install script. Tracking third_party source (security updates, etc) is a huge pain, and has caused a lot of problems in the past. Also, having to build it seems pointless. On Thu, Feb 26, 2009 at 6:42 PM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 9:26 AM, Michael Moss mm...@chromium.org wrote: include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Also note that, for the people using git, it's all in the history now anyway so it doesn't matter to us if it ever gets removed. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
On Thu, Feb 26, 2009 at 10:03 AM, Wan-Teh Chang w...@google.com wrote: On Thu, Feb 26, 2009 at 9:48 AM, Dean McNamee de...@chromium.org wrote: I don't understand why we need to import all of this code just so we can build an .so. Why don't we just take the .so's from the 32-bit package we're already using, and stick them into our .deb? We can check them into svn if don't want developers to have to have it, but that problem is already solved by the install script. Tracking third_party source (security updates, etc) is a huge pain, and has caused a lot of problems in the past. Also, having to build it seems pointless. This idea also occurred to me. Chromium only needs the NSS/NSPR headers and the .so's for Linux. The only issue is that the NSS/NSPR .so's we check into the source tree need to work on all x86 Linux distributions that we support. I don't know the state of binary compatibility across Linux distributions today. Perhaps it works -- I believe that's how Adobe distributes its Flash plugins. Another idea is to work harder with Ubuntu to provide the ia32 NSPR/NSS libs for x86_64 in Ubuntu 8.04 LTS. That'd be the best solution but require a lot of red tape. For those who haven't been following this whole saga, note that there is an Ubuntu bug for this, and so far they have been unwilling to backport it to Hardy. They applied a fix (unfortunately broken) to Intrepid, but don't seem inclined to muck with Hardy unless it's a security fix. At this point, any new requests would be targeted to Jaunty by default. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
On Thu, Feb 26, 2009 at 10:14 AM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:10 AM, Michael Moss mm...@chromium.org wrote: For those who haven't been following this whole saga, note that there is an Ubuntu bug for this, and so far they have been unwilling to backport it to Hardy. They applied a fix (unfortunately broken) to Intrepid, but don't seem inclined to muck with Hardy unless it's a security fix. At this point, any new requests would be targeted to Jaunty by default. As I understand it, NSS must be built as a .so, at least in part. Since we cannot statically link NSS, I don't believe it should be in our tree. Since we're already going to provide packages for 32-bit systems, we can also provide a libnss-32 (or whatever) package and make chromium-browser depend on that. The main problem with that is that it might conflict with distros that already have some or all of the 32-bit stuff (e.g. Intrepid). If we depend on lib32nss2, to get /usr/lib32/libnss3.so, but the distro supplies that in ia32-libs (as it normally would), then our dependency will conflict with ia32-libs and chromium-browser won't install. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
On Thu, Feb 26, 2009 at 10:29 AM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:27 AM, Michael Moss mm...@chromium.org wrote: The main problem with that is that it might conflict with distros that already have some or all of the 32-bit stuff (e.g. Intrepid). If we depend on lib32nss2, to get /usr/lib32/libnss3.so, but the distro supplies that in ia32-libs (as it normally would), then our dependency will conflict with ia32-libs and chromium-browser won't install. We'll have different repos for each different supported release and distribution anyway, so I don't believe this is a problem. Actually, right now, we don't. Our other app packages are universal (within the realm of our supported platforms). Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
On Thu, Feb 26, 2009 at 10:54 AM, Michael Moss mm...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:40 AM, Dean McNamee de...@chromium.org wrote: We don't need to stick the .so's in /usr/lib32 then do we? We can stick them in our own directory if that's the concern. I don't understand have this relates to building our own .so's or reusing someone elses, since either way you have the problem of us shipping one, and someone might already have one. I think we're in agreement here, but I was more just arguing against the separate package dependency. If it's installing to our directory, it might as well not be a separate package. Spoke to soon. One instance where a separate package in our directory would make sense is if ia32-libs eventually adds the needed libs. The chromium-browser package would depend on either our lib32nss3 OR ia32-libs = whatever the known good version is. This would avoid installing our lib32nss3 on systems we know don't need it, while not conflicting with ia32-libs that provide some of the necessary libs. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
On Thu, Feb 26, 2009 at 10:40 AM, Dean McNamee de...@chromium.org wrote: We don't need to stick the .so's in /usr/lib32 then do we? We can stick them in our own directory if that's the concern. I don't understand have this relates to building our own .so's or reusing someone elses, since either way you have the problem of us shipping one, and someone might already have one. I think we're in agreement here, but I was more just arguing against the separate package dependency. If it's installing to our directory, it might as well not be a separate package. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
OK, I'm planning to go with the borrowed 32-bit Ubuntu libs for nss, nspr, and sqlite. These libs won't go in our source tree, but will magically appear from somewhere at packaging time (in reality, probably just pulled from the build host, since that's already configured properly). This will add a bit more than 1MB to the download, at least the first time. When installed, they'll live in the chromium directory and be invoked through a chromium wrapper script with LD_LIBRARY_PATH. This is subject to change with something more elegant/robust, but that should be good enough to start dogfooding. Please let me know if there are any objections. Michael On Thu, Feb 26, 2009 at 10:54 AM, Michael Moss mm...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:40 AM, Dean McNamee de...@chromium.org wrote: We don't need to stick the .so's in /usr/lib32 then do we? We can stick them in our own directory if that's the concern. I don't understand have this relates to building our own .so's or reusing someone elses, since either way you have the problem of us shipping one, and someone might already have one. I think we're in agreement here, but I was more just arguing against the separate package dependency. If it's installing to our directory, it might as well not be a separate package. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten thoma...@chromium.org wrote: Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. By my calculations (du) it's only about 44M, but point taken. I can move it to deps once I figure out how. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
There are actually both nss and nspr under base, but only a handful of files, not the whole trees. I plan to clean those up as appropriate, once this is all in and working. Michael On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang thes...@chromium.org wrote: BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten thoma...@chromium.org wrote: Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux: tabs on top
2) Give up, and just make the tabs flush with the top of the window we have. This is probably ugly in the general case (since there will be an edge between the title bar and tabs), but will work in all situations. I'm not sure I understand what this ugly edge is. Do you mean the line/bevel that window managers typically draw under the title bar? Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux: tabs on top
On Wed, Jan 28, 2009 at 1:32 PM, Amanda Walker ama...@chromium.org wrote: On Wed, Jan 28, 2009 at 2:56 PM, Evan Martin e...@chromium.org wrote: Two options: 1) Set the hint that turns off window frame drawing, and render something that looks like the Windows one. This would mean implementing window dragging via the title bar, etc. manually. (Ben's magic browzr work was undoing code like this on Windows, because it's endless pain. It may be endless pain, but isn't it what we still do in XP, for similar reasons? And in Cole's prototypes of Mac window frames and tabs, we're also overriding OS window frame drawing in order to provide Chromium-style tab and window styling (it's designed to blend with native Mac windows, but it's not using the default window appearance). I'm a casual linux-desktop user at best (mostly I ssh to Linux boxen), but a Chromium-XP style window frame doesn't strike me as too out of place on, say, an Ubuntu desktop as long as the color could be changed away from bright blue... Yeah, and if the smooth tab/title bar is a big part of Chrome's recognizability (to echo Ben), then it's probably worth going the custom drawn route. I'd be inclined to start there, rather than put it off, since I think a basic implementation shouldn't be too hard. And by basic, I'm thinking mostly drag and resize support on, say, Hardy Gnome and KDE (if a right-click doesn't bring up the window manager menu, is anyone really going to miss it?). On a related note, would dialogs use a similar custom border (it looks like they do on Windows), or the regular WM border? Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux: tabs on top
On Wed, Jan 28, 2009 at 2:24 PM, Evan Martin e...@chromium.org wrote: On Wed, Jan 28, 2009 at 2:19 PM, Michael Moss mm...@chromium.org wrote: On Wed, Jan 28, 2009 at 1:32 PM, Amanda Walker ama...@chromium.org wrote: I'm a casual linux-desktop user at best (mostly I ssh to Linux boxen), but a Chromium-XP style window frame doesn't strike me as too out of place on, say, an Ubuntu desktop as long as the color could be changed away from bright blue... Yeah, and if the smooth tab/title bar is a big part of Chrome's recognizability (to echo Ben), then it's probably worth going the custom drawn route. I'd be inclined to start there, rather than put it off, since I think a basic implementation shouldn't be too hard. And by basic, I'm thinking mostly drag and resize support on, say, Hardy Gnome and KDE (if a right-click doesn't bring up the window manager menu, is anyone really going to miss it?). On a related note, would dialogs use a similar custom border (it looks like they do on Windows), or the regular WM border? If we're going to do some of it, may as well do all of it, I guess? Yeah. The system dialogs (e.g. save as) won't match, but it looks like the Windows port doesn't care about that either. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux layout tests status
We're now down to 37 failures and 62 unexpected passes, after some manual work on truly failing tests as well as some computer-assisted work on those that just needed fuzzy diffing. Since we're down to a much smaller list now, can everyone either chime in on what tests they're looking at, or add it http://code.google.com/p/chromium/wiki/LinuxAttackPlan? Since I previously claimed pattern/gradient/background issues, I'lll tackle fast/backgrounds/svg-as-background-1.html if nobody else is on it. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: linux layout tests status
On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin e...@chromium.org wrote: Just so everyone's on the same page: As far as I know we're as close to Windows font metrics as we're gonna get. Using the Windows render tree baselines we're only 0.4% behind Windows. Most of that delta is probably stuff that we have that's really broken, and the font-related ones are likely stuff like italics small-caps helvetica (I think I really did see that test). The WebKit Linux builder on the buildbot is only running render tree tests. However, many of our image expected outputs need to be regenerated, because the font antialiasing is slightly different. Tony set up a temporary pixel builder on his desktop, which Googlers can access at go/chrome_linuxpixel ; hopefully that'll only be up during the current period where we're trying to get the Linux pixel tests matching the non-pixel Linux tests. Currently we have 1554 failing. So what we should be able to get done quickly is rebaseline only tests where we're actually passing. 1) Find some tests that are failing on the linux pixel builder. 2) Run them locally. 3) Verify that they are actually passing by comparing against the Windows baseline. Please be very careful! Many tests matter down to the pixel. 4) Rebaseline passing tests by running them with --new-baseline ; mark tests that are failing in the pixel world by adding to tests_fixable (and be sure to comment as to what the problem is). Adam wrote a nifty fuzzy image differ that can highlight meaningful diffs between images. It's in third_party/fuzzymatch and maybe he can comment on how he uses it. SMO folks: any requests on how we can avoid collisions on this? I typically grab something from the middle (e.g. tables/mozilla/marvin) and just hope I don't conflict. I'm already working on an issue related to pattern drawing which I think may affect a bunch of tests with pattern, gradient, or background in the names, so for now I'll claim those. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: ssl_client_socket Windows Security API Vs NSS
On Wed, Sep 10, 2008 at 8:28 AM, Ibrar Ahmed [EMAIL PROTECTED] wrote: Thanks for your reply, BTW I am not in urgency to delete Windows code and then implement again using NSS ;), I have started the Linux development using NSS. I am glade to hear that other people are also working on that module, its really help if they keep this discussion going on. I am waiting for the replies specialy from Michael Moss as you mentioned he worked on this module. I'm not working on ssl_client_socket right now. My only involvement so far was to bring NSS into the build system, which is done, so you should be able to write and build NSS-based code now (assuming you have the rest of the prerequisites mentioned on the Linux build page, since we're using the system-provided NSS). Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Complied Chrome fort Fedora Linux 9, according to instruction? How do I open the browser on my Laptop now?
On Sep 4, 3:43 pm, Ian Fette [EMAIL PROTECTED] wrote: There is no working Linux version yet. The coding is still in process - what we have right now in terms of executables are unit tests, mostly. The only specific instructions I've been able to find for Linux are how to check out and start a complete build. How do we run the unit tests? I'm afraid I'm a Perl geek, and SConscript is quite alien to me. The Linux build instructions have been updated with a Next Steps section. The linked development page is still being fleshed out, but it will at least point you in the right direction. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
