Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-83274

Can't build QN bundled with qtwebengine using Clang

    XMLWordPrintable

Details

    • Bug
    • Resolution: Cannot Reproduce
    • Not Evaluated
    • None
    • 5.14.1
    • WebEngine
    • None
    • Gentoo Linux, clang-9.0.1, libc++ 9.0.1, gn-0.1463
    • Linux/X11

    Description

      UPDATE: It is definitely a Clang issue; I've successfully rebuilt everything with GCC/libstdc++. That means something in this environment:

      CC="clang"
      CXX="clang++"
      AR="llvm-ar"
      NM="llvm-nm"
      RANLIB="llvm-ranlib"

      CFLAGS="-march=bdver2 -O2 -pipe"
      CXXFLAGS="${CFLAGS} -stdlib=libc++"
      FFLAGS="${CFLAGS}"
      FCFLAGS="${FFLAGS}"

      doesn't work when this one does:

      CC="gcc"
      CXX="g++"
      AR="ar"
      NM="nm"
      RANLIB="ranlib"

      CFLAGS="-march=bdver2 -mprefer-avx128 -mvzeroupper -O2 -pipe"
      CXXFLAGS="${CFLAGS}"
      FFLAGS="${CFLAGS}"
      FCFLAGS="${FFLAGS}"

      And it's not the libc++ since I've tried Clang without it as well.

      I'll keep the description below for historical record, but I was kind of going off in the wrong direction with it.

       

       

      I'm going to admit right off the bat that some of this isn't going to be your issue.  Some of the workarounds I've tried are just throwing things at the wall, and hoping that they fix more than they break.  If something in an environment I've hacked out from the beaten trail is broken, I don't necessarily expect you to fix it.  However, that doesn't change the fact that, at the end of it all, I still can't build qtwebengine, and I hope that some of the excursions at least reveal areas that don't hold together as well with non-recommended tooling, and that some of those might be worthy of fixing.

      Also, since it quickly becomes obvious I do more to install things than most people, that I run Gentoo and therefore don't install from prebuilt binaries is probably required background; nonetheless everything has worked fine in the past.

       

      The initial issue started when I switched over to compiling my system with Clang and its libc+, rather than GCC and libstdc+.  At that point, qtwebengine stopped compiling early in the process due to link errors on dl_stack_flags, _dl_x86_cpu_features, and }}{{_dladdr. I eventually tracked that down to when it was trying to build GN. (The note on these instructions make me think it might be an issue with the static linking trying to pull in the wrong, GNU-developed library.)

      As an aside, I should note that switching back to GCC just for qtwebengine fails as well now, due to unrecognized command line options. Not sure why src/3rdparty/chromium/build/config/clang/BUILD.gn is getting called to generate the .ninja files, since GCC's the expected tooling, but maybe something's picking up that some of the dependencies are built with Clang? If so, I'm not going to revert my entire system just for this one package, but if that can be overridden or otherwise tracked down, I would accept building a small collection of packages with GCC as being a temporary solution, especially if it doesn't wind up being one of the libraries where dependencies and dependee have to be built with the same compiler. At the very least, it would be progress.

      Back to the Clang build, and noticing that the configure checked for and didn't find a system GN, I figured I'd see about installing it on its own, in case some of the options that directness would expose could fix the build; however, it was successful without any tweaking. So, GN provided, I went back to compiling qtwebengine – except it still didn't find it, tried to build its own, and failed just as before. I bit more digging turned up that src/buildtools/configure.json disables the detection, despite printing the line as if it did something.

      So, I wrote a quick and dirty patch to remove that disabling line (#470), and restarted the build. This time, everything was properly checked, and qtwebengine realized it didn't have to build GN after all. Except, a few files later in trying to build convert_dict, GN complained about create_pri_file never being used after being assigned. No idea why that's worthy of a build-stopping error instead of just a warning, but I guess that's (at least part of) why the packaged GN was being forced instead. Still, isn't there some option to simply disable the check, or has the packaged GN been forked beyond backwards compatability?

      This is where things begin to really get unsupported. I knew that that assignment would be there for a reason, but just to see what failed next, I tried removing that line (#28). And then the line generating them (#177) in mkspecs/features/gn_generator.prf since that was the first thing I found to "fix" the same issue in src/core/something/release/BUILD.gn (I've forgotten what the path was exactly). Surprisingly, that proved to be enough to get the whole thing compiled. Less surprisingly, the linker still failed with a lot of errors against qtcore symbols.

      I've attached build logs and my patchfile in case any of them help clarify anything.

      Attachments

        1. qtwebengine_par1.log
          30 kB
        2. qtwebengine_par2.log
          54 kB
        3. qtwebengine_par4.log
          21 kB
        4. qtwebengine_par5.log
          1.25 MB
        5. qtwebengine-5.14.1-detect-system-gn.patch
          1 kB
        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            qt_webengine_team Qt WebEngine Team
            ag.eitilt Samuel May
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes