Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1464983003:
Use sysroot by default for all linux builds (Closed)
DescriptionUse sysroot by default for all linux builds
Using a sysroot was already the default for official
build and when cross compiling (e.g. arm, mips, x86-32).
This change makes it the default in all cases.
The old behavior of building against local
system libraries can still be achieved by
setting use_sysroot=0
BUG=504446
Committed: https://crrev.com/a931efd5dc8d8783ce73a64fc641627866b6869d
Cr-Commit-Position: refs/heads/master@{#361197}
Patch Set 1 #Patch Set 2 : #Patch Set 3 : #Patch Set 4 : #Patch Set 5 : #
Total comments: 4
Patch Set 6 : #
Total comments: 2
Patch Set 7 : #
Messages
Total messages: 40 (15 generated)
The CQ bit was checked by sbc@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1464983003/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1464983003/60001
Description was changed from ========== Use sysroot by default for all linux builds Using a sysroot was already the default for cross compiling (e.g. arm, mips, x86-32). The changes makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ========== to ========== Use sysroot by default for all linux builds Using a sysroot was already the default for cross compiling (e.g. arm, mips, x86-32). The changes makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ==========
sbc@chromium.org changed reviewers: + dpranke@chromium.org
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by sbc@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1464983003/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1464983003/80001
lgtm w/ typos fixed. We should probably wait until monday to land this and send out a PSA to chromium-dev at the same time. https://codereview.chromium.org/1464983003/diff/80001/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/1464983003/diff/80001/build/common.gypi#newco... build/common.gypi:92: # depending of the packages installed on the local machine. Set this s/depending of/depending on/ https://codereview.chromium.org/1464983003/diff/80001/build/common.gypi#newco... build/common.gypi:93: # to 0 to build against locally install headers and libraries (e.g. s/locally install/locally installed/
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
thestig@chromium.org changed reviewers: + thestig@chromium.org
We also should give chromium-packagers a heads up regarding this change. https://codereview.chromium.org/1464983003/diff/100001/build/config/sysroot.gni File build/config/sysroot.gni (right): https://codereview.chromium.org/1464983003/diff/100001/build/config/sysroot.g... build/config/sysroot.gni:37: # For official builds, use the sysroot checked into the internal source repo Update comment.
https://codereview.chromium.org/1464983003/diff/80001/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/1464983003/diff/80001/build/common.gypi#newco... build/common.gypi:92: # depending of the packages installed on the local machine. Set this On 2015/11/21 23:30:15, Dirk Pranke wrote: > s/depending of/depending on/ Done. https://codereview.chromium.org/1464983003/diff/80001/build/common.gypi#newco... build/common.gypi:93: # to 0 to build against locally install headers and libraries (e.g. On 2015/11/21 23:30:15, Dirk Pranke wrote: > s/locally install/locally installed/ Done. https://codereview.chromium.org/1464983003/diff/100001/build/config/sysroot.gni File build/config/sysroot.gni (right): https://codereview.chromium.org/1464983003/diff/100001/build/config/sysroot.g... build/config/sysroot.gni:37: # For official builds, use the sysroot checked into the internal source repo On 2015/11/22 23:15:24, Lei Zhang wrote: > Update comment. Done.
Description was changed from ========== Use sysroot by default for all linux builds Using a sysroot was already the default for cross compiling (e.g. arm, mips, x86-32). The changes makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ========== to ========== Use sysroot by default for all linux builds Using a sysroot was already the default for offial build and when cross compiling (e.g. arm, mips, x86-32). The changes makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ==========
Description was changed from ========== Use sysroot by default for all linux builds Using a sysroot was already the default for offial build and when cross compiling (e.g. arm, mips, x86-32). The changes makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ========== to ========== Use sysroot by default for all linux builds Using a sysroot was already the default for official build and when cross compiling (e.g. arm, mips, x86-32). This change makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ==========
Description was changed from ========== Use sysroot by default for all linux builds Using a sysroot was already the default for official build and when cross compiling (e.g. arm, mips, x86-32). This change makes it the default in all cases. The old behaviour of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ========== to ========== Use sysroot by default for all linux builds Using a sysroot was already the default for official build and when cross compiling (e.g. arm, mips, x86-32). This change makes it the default in all cases. The old behavior of building against local system libraries can still be achieved by setting use_sysroot=0 BUG=504446 ==========
thakis@chromium.org changed reviewers: + thakis@chromium.org
Does this mean devs no longer need to run build/install-build-deps.sh? And if someone adds something to it, we need to make a new sysroot which is downloaded automatically instead of having to tell each dev to rerun that script? Is the process for updating sysroots documented anywhere? Since sysroots are pretty large, I guess we think they won't change super often (let's say less often than once every 2 months or something in that ballpark)?
On 2015/11/23 17:26:06, Nico wrote: > Does this mean devs no longer need to run build/install-build-deps.sh? Partially. At least it means that all the '-dev' packages can be removed from install-build-deps.sh. Sadly it can't be removed completely as it is used to install a lot of misc host tools as well as -dev packages. At least we can simply it significantly. > And if > someone adds something to it, we need to make a new sysroot which is downloaded > automatically instead of having to tell each dev to rerun that script? Yes. There would be no need to re-run the script when -dev dependencies change. Adding a new dependency requires rebuilding the image and updating the pinned version. e.g.: https://codereview.chromium.org/1466383002. This is already true even before this change (see the bug referenced by this CL for a recent breakage where libffi was added to install-build-deps but the image was not updated). > > Is the process for updating sysroots documented anywhere? Since sysroots are > pretty large, I guess we think they won't change super often (let's say less > often than once every 2 months or something in that ballpark)? Yes, there is a need to improve the docs on updating the image. There are not actually very large (34mb - 45Mb depending on the platform), and they change very rarely (something like once a year i would guess).
This all sounds fantastic, thanks! (I'm just asking things out of curiosity, don't consider my questions as blocking cq for this.) > Adding a new dependency requires rebuilding the image and updating the pinned > version. e.g.: > https://codereview.chromium.org/1466383002. How is the rebuilding itself done? I suppose there's some script somewhere that does this and outputs the hash mentioned in that CL?
On 2015/11/23 17:36:00, Sam Clegg wrote: > There are not actually very large (34mb - 45Mb depending on the platform), and > they change very rarely (something like once a year i would guess). I actually thought they were closer to 120MB (uncompressed), at least for x64 and x32. We definitely need to update the docs for this. And yes, 1-2 times a year looks about right.
On 2015/11/23 17:40:51, Nico wrote: > This all sounds fantastic, thanks! (I'm just asking things out of curiosity, > don't consider my questions as blocking cq for this.) > > > Adding a new dependency requires rebuilding the image and updating the pinned > > version. e.g.: > > https://codereview.chromium.org/1466383002. > > How is the rebuilding itself done? I suppose there's some script somewhere that > does this and outputs the hash mentioned in that CL? There are currently 4 phases to updating: 1. Update to the package listing from Debian archive (optional): $ build/linux/sysroot_scripts/sysroot-creator-wheezy.sh UpdatePackageListsAll 2. Build the images themselves: $ build/linux/sysroot_scripts/sysroot-creator-wheezy.sh BuildSysrootAll 3. Upload the new images to GCS (requires write access to chrome-linux-sysroot the bucket) $ build/linux/sysroot_scripts/sysroot-creator-wheezy.sh UploadSysrootAll <revision> 4. Manually update hashes in build/linux/sysroot_scripts/install-sysroot.py Since this is only happening about once a year I'm not too bothered about the manual step 4 for now.
On 2015/11/23 17:41:36, Dirk Pranke wrote: > On 2015/11/23 17:36:00, Sam Clegg wrote: > > There are not actually very large (34mb - 45Mb depending on the platform), and > > they change very rarely (something like once a year i would guess). > > I actually thought they were closer to 120MB (uncompressed), at least for x64 > and x32. Yes, I was referring the download (compressed) size. > > We definitely need to update the docs for this. > > And yes, 1-2 times a year looks about right.
The CQ bit was checked by sbc@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1464983003/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1464983003/120001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by sbc@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dpranke@chromium.org Link to the patchset: https://codereview.chromium.org/1464983003/#ps120001 (title: " ")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1464983003/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1464983003/120001
Message was sent while issue was closed.
Committed patchset #7 (id:120001)
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/a931efd5dc8d8783ce73a64fc641627866b6869d Cr-Commit-Position: refs/heads/master@{#361197}
Message was sent while issue was closed.
A revert of this CL (patchset #7 id:120001) has been created in https://codereview.chromium.org/1468273003/ by holte@chromium.org. The reason for reverting is: https://crbug.com/560603 Suspect this breaks webview_licenses.
Message was sent while issue was closed.
On 2015/11/24 at 01:45:39, holte wrote: > A revert of this CL (patchset #7 id:120001) has been created in https://codereview.chromium.org/1468273003/ by holte@chromium.org. > > The reason for reverting is: https://crbug.com/560603 > > Suspect this breaks webview_licenses. Local component build of chrome is failing to run on my workstation after this change. The error is: chrome: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory looks like a libffi version problem as 'ldd ./out/Debug/chrome | grep libffi' output is: libffi.so.5 => not found libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007ff929783000) use_sysroot=0 still works fine
Message was sent while issue was closed.
On 2015/11/24 15:24:29, reveman wrote: > On 2015/11/24 at 01:45:39, holte wrote: > > A revert of this CL (patchset #7 id:120001) has been created in > https://codereview.chromium.org/1468273003/ by mailto:holte@chromium.org. > > > > The reason for reverting is: https://crbug.com/560603 > > > > Suspect this breaks webview_licenses. > > Local component build of chrome is failing to run on my workstation after this > change. The error is: > > chrome: error while loading shared libraries: libffi.so.5: cannot open shared > object file: No such file or directory > > looks like a libffi version problem as 'ldd ./out/Debug/chrome | grep libffi' > output is: > libffi.so.5 => not found > libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007ff929783000) > > use_sysroot=0 still works fine Local clean ToT build or local build with local changes?
Message was sent while issue was closed.
On 2015/11/24 15:32:34, Lei Zhang wrote: > On 2015/11/24 15:24:29, reveman wrote: > > On 2015/11/24 at 01:45:39, holte wrote: > > > A revert of this CL (patchset #7 id:120001) has been created in > > https://codereview.chromium.org/1468273003/ by mailto:holte@chromium.org. > > > > > > The reason for reverting is: https://crbug.com/560603 > > > > > > Suspect this breaks webview_licenses. > > > > Local component build of chrome is failing to run on my workstation after this > > change. The error is: > > > > chrome: error while loading shared libraries: libffi.so.5: cannot open shared > > object file: No such file or directory > > > > looks like a libffi version problem as 'ldd ./out/Debug/chrome | grep libffi' > > output is: > > libffi.so.5 => not found > > libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007ff929783000) > > > > use_sysroot=0 still works fine > > Local clean ToT build or local build with local changes? Indeed, it looks like trusty contains only libffi6 whereas wheezy only contains libffi5. It seems like this issue is really with adding libffi as direct dependency: https://codereview.chromium.org/1426583009 The issue would be present on the official builders, since they have always beeing using the sysroot. Possible solutions would be to load libffi at runtime, or to change the minimum distro requirements (i.e. drop wheezy support). The later would be a pretty big change.
Message was sent while issue was closed.
This broke goma; just filed https://code.google.com/p/chromium/issues/detail?id=560973 I think we should revert until this is figured out.
Message was sent while issue was closed.
A revert of this CL (patchset #7 id:120001) has been created in https://codereview.chromium.org/1473363002/ by sbc@chromium.org. The reason for reverting is: Seems to have caused issues with goma: https://code.google.com/p/chromium/issues/detail?id=560973 . |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
