LLVM sources added to tarballs

[Tom Anderson]

As of the chromium-65.0.3325.0 tarball pushed out today, the LLVM sources needed for building clang and lld have been added in third_party/llvm.

Not only is it recommeded that you build with clang, it's also recommended to build with the exact version of clang (usually close to ToT) pulled in by the Chromium sources.

To build clang, you need to run

tools/clang/scripts/update.py --force-local-build --without-android --use-system-cmake --if-needed --gcc-toolchain=/usr --skip-checkout

There should be no files that get pulled down from the net.

To build Chromium with the clang/lld that you just built, set is_clang=true in your args.gn.

[Mike Gilbert]

I appreciate the effort to get the necessary code into the tarball, so thanks for that.

However, I must say that it is really quite annoying to be forced into using a bleeding-edge toolchain to build chromium because of the weird C++ code some Chromium devs write. I really wish you would set up some build bots running more stable toolchains (gcc and stable clang), and force people to make their code more compatible.

[Tom Callaway]

This. A thousand times this.

~tom

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packagers+unsub...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/c4b04fc8-81eb-4452-8643-ce95ca977f41%40chromium.org.

[Lei Zhang]

Chromium developers probably aren't writing weird C++ code. They just
want to use C++11 and C++14 language features.

The latest stable Clang will likely build Chromium with a little bit
of work. The Chromium build may be passing in compiler flags that
require a bleeding edge Clang. Maybe we can do a better job of
separating though out in the build files, so it easier to disable them
if one wishes to build with stable Clang.

> --
> You received this message because you are subscribed to the Google Groups
> "chromium-packagers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to chromium-packag...@chromium.org.

[Mike Gilbert]

By "weird" code, I really mean code that triggers edge-cases / obscure bugs in GCC and Clang.

To share an example, I recently tried to build 65.0.3325.18 using clang-5.0.1, and got the following error. I assume this is probably some bug in clang, but I'm not enough of an expert on C++ to tell for sure or to be able to submit a patch to work around it.

When I attempt to build with GCC 6.4.0, i get a different error in a different file, but nothing related to compiler options.

I will probably submit bug reports later, but those are never guaranteed to be looked at or fixed.

FAILED: obj/device/u2f/u2f/u2f_ble_transaction.o
clang++ -MMD -MF obj/device/u2f/u2f/u2f_ble_transaction.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DCR_CLANG_REVISION=\"321529-2\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DENABLE_IPC_FUZZER -I../.. -Igen -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Igen/shim_headers/zlib_shim -Igen/shim_headers/re2_shim -Igen/shim_headers/libpng_shim -Igen/shim_headers/libjpeg_shim -Igen/shim_headers/libdrm_shim -I../../third_party/boringssl/src/include -I../../third_party/protobuf/src -Igen/protoc_out -I../../third_party/protobuf/src -I/usr/include/nss -I/usr/include/nspr -I../../third_party/ced/src -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -fcolor-diagnostics -no-canonical-prefixes -m64 -march=x86-64 -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wno-unused-lambda-capture -Wno-user-defined-warnings -Wno-enum-compare-switch -Wno-tautological-unsigned-zero-compare -Wno-null-pointer-arithmetic -Wno-tautological-constant-compare -Wtautological-constant-out-of-range-compare -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wno-header-guard -std=gnu++14 -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -O2 -pipe -march=amdfam10 -c ../../device/u2f/u2f_ble_transaction.cc -o obj/device/u2f/u2f/u2f_ble_transaction.o
warning: unknown warning option '-Wno-enum-compare-switch'; did you mean '-Wno-enum-compare'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-tautological-unsigned-zero-compare' [-Wunknown-warning-option]
warning: unknown warning option '-Wno-null-pointer-arithmetic'; did you mean '-Wno-null-arithmetic'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-tautological-constant-compare'; did you mean '-Wno-tautological-pointer-compare'? [-Wunknown-warning-option]
../../device/u2f/u2f_ble_transaction.cc:134:27: error: no viable overloaded '='
  request_cont_fragments_ = {};
  ~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_queue.h:96:11: note: candidate function (the implicit move assignment operator) not viable: cannot convert initializer list argument to 'std::queue<device::U2fBleFrameContinuationFragment, base::circular_deque<device::U2fBleFrameContinuationFragment> >'
    class queue
          ^
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_queue.h:96:11: note: candidate function (the implicit copy assignment operator) not viable: cannot convert initializer list argument to 'const std::queue<device::U2fBleFrameContinuationFragment, base::circular_deque<device::U2fBleFrameContinuationFragment> >'
4 warnings and 1 error generated.

[Saikrishna Arcot]

I hit that error as well, but only on older versions of clang. I had to replace {} with base::queue<U2fBleFrameContinuationFragment>(). This is using Ubuntu's version of clang/libc.

Additionally, in gpu/command_buffer/service/texture_manager.cc, I had to replace all the tuple creations with std::make_tuple calls for the older clang versions.

--

You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/ba579aaa-955a-43ec-af7f-27c6d0e9d588%40chromium.org.

-- 
Saikrishna Arcot

[Tom Anderson]

On Mon, Jan 29, 2018 at 9:40 PM, Saikrishna Arcot <saiar...@gmail.com> wrote:

I hit that error as well, but only on older versions of clang. I had to replace {} with base::queue<U2fBleFrameContinuationFragment>(). This is using Ubuntu's version of clang/libc. 

Additionally, in gpu/command_buffer/service/texture_manager.cc, I had to replace all the tuple creations with std::make_tuple calls for the older clang versions.

If you submit a patch to chromium-review.googlesource.com, we would gladly accept it.  

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packagers+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/ba579aaa-955a-43ec-af7f-27c6d0e9d588%40chromium.org.

-- 
Saikrishna Arcot

[Eric Hameleers]

I simply reverted https://chromium.googlesource.com/chromium/src.git/+/3b68383d8ef085a2e47124a6c46f791d6e86271f to fix the compilation error related to the tuple creation.

To compile M65 successfully I had to write or borrow several patches that were not needed for the M64 compilation. What seems to happen a lot is that explicit or implicit inclusion of <math.h> draws in my Slackware OS's gcc-5.5.0 includes and/or clashes with the OS version of clang and glibc.

I try to compile Chromium using a clang compiler built from its own included clang sources and I am not happy to see that I can not contain the process.

Op dinsdag 30 januari 2018 19:51:48 UTC+1 schreef Tom Anderson:

[Tom Anderson]

On Wed, Mar 14, 2018 at 7:03 AM, Eric Hameleers <al...@slackware.com> wrote:

I simply reverted https://chromium.googlesource.com/chromium/src.git/+/3b68383d8ef085a2e47124a6c46f791d6e86271f to fix the compilation error related to the tuple creation.

To compile M65 successfully I had to write or borrow several patches that were not needed for the M64 compilation. What seems to happen a lot is that explicit or implicit inclusion of <math.h> draws in my Slackware OS's gcc-5.5.0 includes and/or clashes with the OS version of clang and glibc.

I try to compile Chromium using a clang compiler built from its own included clang sources and I am not happy to see that I can not contain the process.

That's likely not caused by the compiler, but by libstdc++.  I'm guessing you're compiling with use_custom_libcxx=false ?  If so, try setting it to true to see if it fixes the issue.  If it does, I'll see if we can remove the <math.h> include from libc++ to match libstdc++ so we don't see this type of regression any more (there have been quite a few recently).

[Eric Hameleers]

Op woensdag 14 maart 2018 17:18:48 UTC+1 schreef Tom Anderson:

On Wed, Mar 14, 2018 at 7:03 AM, Eric Hameleers <al...@slackware.com> wrote:

I simply reverted https://chromium.googlesource.com/chromium/src.git/+/3b68383d8ef085a2e47124a6c46f791d6e86271f to fix the compilation error related to the tuple creation.

To compile M65 successfully I had to write or borrow several patches that were not needed for the M64 compilation. What seems to happen a lot is that explicit or implicit inclusion of <math.h> draws in my Slackware OS's gcc-5.5.0 includes and/or clashes with the OS version of clang and glibc.

I try to compile Chromium using a clang compiler built from its own included clang sources and I am not happy to see that I can not contain the process.

That's likely not caused by the compiler, but by libstdc++.  I'm guessing you're compiling with use_custom_libcxx=false ?  If so, try setting it to true to see if it fixes the issue.  If it does, I'll see if we can remove the <math.h> include from libc++ to match libstdc++ so we don't see this type of regression any more (there have been quite a few recently).

Hi Tom

Indeed. When I switched to 'use_custom_libcxx=true' I no longer needed any of the clang/gcc/glibc compatibility patches.

This is my commit for the Slackware chromium package where I made the change:

https://git.slackware.nl/asb/commit/?id=99a3f0ee172fe2dfd60c3b05841938da6cf3d796

These are the six patches I could get rid of:

http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_math.h-r0.patch

http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_stdint.patch

http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_gcc_round_fix.patch

http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_revert_tuple.patch

http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_clang-r3.patch

http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_gcc5_2.patch

I hope you can do something useful with this information and address the recent regressions in the Chromium source code that mandated these patches (I would like to revert back to 'use_custom_libcxx=false')

Cheers, Eric 

[Raphael Kubo da Costa]

Eric Hameleers <al...@slackware.com> writes:

> Op woensdag 14 maart 2018 17:18:48 UTC+1 schreef Tom Anderson:
>
> On Wed, Mar 14, 2018 at 7:03 AM, Eric Hameleers <al...@slackware.com> wrote:
>
> I simply reverted https://chromium.googlesource.com/chromium/src.git/+/3b68383d8ef085a2e47124a6c46f791d6e86271f to fix the compilation error
> related to the tuple creation.
>
> To compile M65 successfully I had to write or borrow several patches that were not needed for the M64 compilation. What seems to happen a lot
> is that explicit or implicit inclusion of <math.h> draws in my Slackware OS's gcc-5.5.0 includes and/or clashes with the OS version of clang
> and glibc.
> I try to compile Chromium using a clang compiler built from its own included clang sources and I am not happy to see that I can not contain
> the process.
>
> That's likely not caused by the compiler, but by libstdc++. I'm guessing you're compiling with use_custom_libcxx=false ? If so, try setting it
> to true to see if it fixes the issue. If it does, I'll see if we can remove the <math.h> include from libc++ to match libstdc++ so we don't see
> this type of regression any more (there have been quite a few recently).
>
> Hi Tom
>
> Indeed. When I switched to 'use_custom_libcxx=true' I no longer needed any of the clang/gcc/glibc compatibility patches.
> This is my commit for the Slackware chromium package where I made the change:
> https://git.slackware.nl/asb/commit/?id=99a3f0ee172fe2dfd60c3b05841938da6cf3d796
>
> These are the six patches I could get rid of:
>
> http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_math.h-r0.patch

https://chromium-review.googlesource.com/890059
(libstdc++ 5.x does need cmath instead, but it's been fixed in newer releases)

> http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_stdint.patch
https://chromium-review.googlesource.com/895583

> http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_gcc_round_fix.patch
I added the <math.h> include myself in
https://webrtc-review.googlesource.com/9384, and I didn't have any
issues with it. I'm interested in the actual error you're having.

> http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_revert_tuple.patch
Not sure there's much to fix upstream here; you basically need a more
recent libstdc++ for things to work.

> http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_clang-r3.patch
This works fine with GCC7+, so I felt like there was no need to change
any code upstream.

> http://www.slackware.com/~alien/slackbuilds/chromium/build/patches/chromium_gcc5_2.patch
Also not sure about anything to upstream here; this is only broken with
libstdc++ 5.x.

> I hope you can do something useful with this information and address
> the recent regressions in the Chromium source code that mandated these
> patches (I would like to revert back to 'use_custom_libcxx=false')

FWIW, José Dapena, myself and a few others have been landing build fixes
for GCC and/or libstdc++ lately, and master is in much better shape than
the M65 branch (at least when it comes to more recent GCC versions such
as 7.x). Personally, I've been trying to get at least the "chrome" and
"blink_tests" target building at all times with my system's
GCC/libstdc++.

Maintaining support for GCC 5 specifically is an increasingly uphill
battle though, and essentially boils down to working around compiler and
STL bugs or lack of features that are present in more recent versions.

Lastly, I maintain a Chromium recipe for Yocto here

https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium

which uses the system's GCC and libstdc++, and I've tested GCC 5, 6 and
7. You might want to keep an eye on it for useful patches for Slackware.
I know I'll keep testing GCC 5 on M65, but I'm still undecided about
newer milestones.