Building didn't work due to wrong versions

[vecortez]

Hello, I have been struggling for a day or so with building the code using LLVM. The ninja command for building autofdo showed the following: class llvm::Expected<const char*>’ has no member named ‘getValue’ and: glog/glog/logging.h:654:9: error: ambiguous overload for ‘operator<<’ (operand types are ‘std::ostream’ {aka ‘std::basic_ostream<char>’} and ‘std::nullptr_t’)

I realized that in order to make it work llvm needs to be version 10 as newer versions won't work, I found that changes needed to be done in other repos that experienced the same issue as the LLVM code was changed. And glog need to be version 0.5 as the issue is fixed on PR 646, which is merged only on that version.

The way the instructions are written right now doesn't work.

[shenhanc78]

Hello, thanks for reporting. I've pushed a version that should fix this bug, please have a try.

[DressInWhite]

Hello, Is the version problem solved? I had the same problem with the newest verison. third_party/glog/glog/logging.h:654:9: error: ambiguous overload for ‘operator<<’ (operand types are ‘std::ostream’ {aka ‘std::basic_ostream’} and ‘std::nullptr_t’) (*os) << v;

[vecortez]

No, the problem wasn’t fixed.

---

De: DressInWhite @.> Enviado: Thursday, April 28, 2022 3:22:00 AM Para: google/autofdo @.> CC: Cortez Gutierrez, Valeria @.>; Author @.> Asunto: Re: [google/autofdo] Building didn't work due to wrong versions (Issue #132)

Hello, Is the version problem solved? I had the same problem with the newest verison. third_party/glog/glog/logging.h:654:9: error: ambiguous overload for ‘operator<<’ (operand types are ‘std::ostream’ {aka ‘std::basic_ostream’} and ‘std::nullptr_t’) (*os) << v;

— Reply to this email directly, view it on GitHubhttps://github.com/google/autofdo/issues/132#issuecomment-1111890990, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AWLQPMSVCUJJWWKZXITNG6TVHJDCRANCNFSM5NQAXSDQ. You are receiving this because you authored the thread.Message ID: @.***>

[DressInWhite]

Hello， Thank you for your answer. The problem is not seen when I update to glog-0.5.0. By the way, Can the tool convert gcc's gcov format to llvm profile? I want to optimizer my code with gcov file. I find the create_gcov.cc file in this project, but it seems that the input file is still perf data.

[shenhanc78]

Hi Valeria, sorry to hear the problem persists.

I just followed 2.1.1 and 2.2.2 and it was built smoothly.

I know you have a different setup. Are you using llvm-10.0? I'll try to see if I can reproduce this in llvm-10.0. If you could provide the details of your set up that would be very helpful. (We usually will have a fix for the bug if we reproduce it. Although in this case, the fix is straightforward.)

[Enna1]

Hi, I encounter the same issue, any update?

[shenhanc78]

Hello Enna1, are you referring to vecortez's commented on Feb 3? I've put a note on May 26, that I was not able to reproduce it. However I'll try to do it again today in a fresh installed linux system.

[shenhanc78]

I've just freshly installed a linux system and followed the steps in 1 (except I have to install cmake and ninja-build) , 2.1.1 & 2.1.2 and it is a success.

I used both system default gcc 11.3.0-5 as well as system clang 14.0.6-2.

I'm more than happy to help if a reproduce is available. Thank.

[jwbee]

With a scratch install of Ubuntu 22.04.1 LTS, which contains GCC 11.2.0, my build following instructions 2.2.1 stops with:

[82/241] Building CXX object third_party/abseil/absl/debugging/CMakeFiles/absl_failure_signal_handler.dir/failure_signal_handler.cc.o
FAILED: third_party/abseil/absl/debugging/CMakeFiles/absl_failure_signal_handler.dir/failure_signal_handler.cc.o 
/usr/bin/c++  -I/home/jeff.baker/autofdo/third_party/abseil -O3 -DNDEBUG -Wall -Wextra -Wcast-qual -Wconversion-null -Wformat-security -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wundef -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -DNOMINMAX -std=gnu++17 -MD -MT third_party/abseil/absl/debugging/CMakeFiles/absl_failure_signal_handler.dir/failure_signal_handler.cc.o -MF third_party/abseil/absl/debugging/CMakeFiles/absl_failure_signal_handler.dir/failure_signal_handler.cc.o.d -o third_party/abseil/absl/debugging/CMakeFiles/absl_failure_signal_handler.dir/failure_signal_handler.cc.o -c /home/jeff.baker/autofdo/third_party/abseil/absl/debugging/failure_signal_handler.cc
/home/jeff.baker/autofdo/third_party/abseil/absl/debugging/failure_signal_handler.cc: In function ‘bool absl::SetupAlternateStackOnce()’:
/home/jeff.baker/autofdo/third_party/abseil/absl/debugging/failure_signal_handler.cc:138:32: error: no matching function for call to ‘max(long int, int)’
  138 |   size_t stack_size = (std::max(SIGSTKSZ, 65536) + page_mask) & ~page_mask;
      |                        ~~~~~~~~^~~~~~~~~~~~~~~~~
[ etc ]

I get the exact same error if I follow steps 2.1.1 and 2.1.2, it just takes an hour longer to reach the same conclusion.

[jwbee]

If I update the abseil submodule to latest, it builds perfectly well. I am not sure why you are unable to repro this build failure. It seems necessarily true that with the checked-in submodule commit of abseil, nobody can build this with recent compilers.

[Enna1]

Hello Enna1, are you referring to vecortez's commented on Feb 3? I've put a note on May 26, that I was not able to reproduce it. However I'll try to do it again today in a fresh installed linux system.

Hi @shenhanc78 , I checkout glog to 0.5.0 as @DressInWhite mentioned, and it works! no more compile error.

[shenhanc78]

@jwbee thanks a lot for publishing the reproduce. I'll mimic your setups. @Enna1 I'll follow the reproduce steps, as soon as I reproduce, I'll upgrade glog to 0.5.0 as you and @DressInWhite suggested.

Thanks.

[shenhanc78]

After I freshly installed ubuntu 22.04.01 desktop edition on a new machine, I was finally able to see the errors. (I was not able to reproduce it even if I build GCC 11.2.0 on my workstation, my laptop, my google cloud instance and my google cloud instance express. I also contacted android build team this afternoon who uses this tool with external customers for performance experiment, and they have never seen any build problems (but they did report other bugs from time to time))

@Enna1 I updated the third_party/glog to v0.5.0 and I still saw the same error: this is what I did:

$ git clone --recursive https://github.com/google/autofdo.git
$ cd autofdo/third_party/glog
$ git checkout v0.5.0
Previous HEAD position was c8f8135 Merge pull request #502 from aesophor/encapsulate-log-cleaner
HEAD is now at 8f9ccfe Merge pull request #646 from sergiud/release-0.5
$ cd ../../ ; mkdir build
$ cd build
$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=. -DLLVM_PATH=/home/shenhan/autofdo-github/install-llvm/ ../
$ ninja

I still see the same build error.

/home/shenhan/autofdo-github/autofdo/third_party/abseil/absl/debugging/failure_signal_handler.cc:138:32: error: no matching function for call to ‘max(long int, int)’
  138 |   size_t stack_size = (std::max(SIGSTKSZ, 65536) + page_mask) & ~page_mask;
      |                        ~~~~~~~~^~~~~~~~~~~~~~~~~

@jwbee then I went on to update third_party/absil

$ cd third_party/abseil/
$ git fetch
$ git checkout origin/master
$ ... delete build and reconfigure and I got errors like:

CMake Error at CMakeLists.txt:464 (add_executable):
  Target "llvm_propeller_code_layout_test" links to target "absl::container"
  but the target was not found.  Perhaps a find_package() call is missing for
  an IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  CMakeLists.txt:536 (config_with_llvm)

CMake Error at CMakeLists.txt:233 (add_library):
  Target "symbol_map" links to target "absl::container" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  CMakeLists.txt:536 (config_with_llvm)

CMake Error at CMakeLists.txt:247 (add_library):
  Target "llvm_profile_writer" links to target "absl::container" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  CMakeLists.txt:536 (config_with_llvm)

Seems they have moved / renamed some of the targets, this should be easy to fix. I'll continue looking into it tomorrow.

Thanks!

[jwbee]

Those later build errors are caused by cmake, which is a fundamentally unsound build system. After updating abseil you must reset its state, most conveniently by just removing the build subdirectory. This process works for me:

git clone --recursive https://github.com/google/autofdo.git
cd autofdo
git submodule update --remote third_party/abseil/
mkdir build
cd build
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=. ../
ninja

[shenhanc78]

@jwbee thanks, your process work!

I've updated third_party/abseil to HEAD (as of today) and third_party/glog to 0.6 and pushed the changes.

Thanks again for help triaging and fixing this @jwbee @Enna1 @vecortez

I'll close this bug in 2 weeks if no further glog/abseil build errors.