Can't Compile in Ubuntu 20.10
pwndumb opened this issue · 57 comments
NAME="Ubuntu"
VERSION="20.10 (Groovy Gorilla)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.10"
VERSION_ID="20.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy
I already installed all dependencies with apt install like wiki tell us to do:
sudo apt-get install \
cmake \
build-essential \
libboost-dev \
libqt5xmlpatterns5-dev \
qtbase5-dev \
qt5-default \
libqt5svg5-dev \
libgraphviz-dev \
libcapstone-dev \
pkg-config
But when I try compile with make I get this error and I unable to fix them:
[ 29%] Building CXX object src/CMakeFiles/edb.dir/FloatX.cpp.o
/home/pwndumb/Tools/edb-debugger/src/FloatX.cpp: In instantiation of ‘QString format_float(Float) [with Float = edb::detail::value_type80]’:
/home/pwndumb/Tools/edb-debugger/src/FloatX.cpp:531:68: required from here
/home/pwndumb/Tools/edb-debugger/src/FloatX.cpp:480:16: error: ‘gdtoa_g_xfmt’ was not declared in this scope
480 | gdtoa_g_xfmt(buffer, &value, -1, sizeof buffer);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/edb.dir/build.make:481: src/CMakeFiles/edb.dir/FloatX.cpp.o] Error 1
make[2]: Leaving directory '/home/pwndumb/Tools/edb-debugger/build'
make[1]: *** [CMakeFiles/Makefile2:706: src/CMakeFiles/edb.dir/all] Error 2
make[1]: Leaving directory '/home/pwndumb/Tools/edb-debugger/build'
make: *** [Makefile:141: all] Error 2
Have you fetched the submodules?
@pwndumb specifically, did you do a clone with --recursive ? Or have done a git submodule update --init --recursive?
Though the cmake command should have warned you if you didn't.
I am about to run the build in a 20.10 docker container to see if I can replicate the issue.
OK, the following commands produced a clean build:
$ docker run -it ubuntu:20.10
root@481506ea94e8:/# apt-get -y update
root@481506ea94e8:/# apt-get -y install \
cmake \
build-essential \
libboost-dev \
libqt5xmlpatterns5-dev \
qtbase5-dev \
qt5-default \
libqt5svg5-dev \
libgraphviz-dev \
libcapstone-dev \
pkg-config \
git
root@481506ea94e8:/# git clone --recursive https://github.com/eteran/edb-debugger.git
root@481506ea94e8:/# cd edb-debugger/
root@481506ea94e8:/edb-debugger# mkdir build
root@481506ea94e8:/edb-debugger# cd build/
root@481506ea94e8:/edb-debugger/build# cmake ..
root@481506ea94e8:/edb-debugger/build# make -j12
So I'm not sure how to reproduce this issue locally :-/
@pwndumb I had the same problem:
[ 31%] Building CXX object src/CMakeFiles/edb.dir/FloatX.cpp.o
/opt/edb-debugger/src/FloatX.cpp: In instantiation of ‘QString format_float(Float) [with Float = edb::detail::value_type80]’:
/opt/edb-debugger/src/FloatX.cpp:531:68: required from here
/opt/edb-debugger/src/FloatX.cpp:480:16: **error: ‘gdtoa_g_xfmt’ was not declared in this scope**
480 | gdtoa_g_xfmt(buffer, &value, -1, sizeof buffer);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/edb.dir/build.make:500: src/CMakeFiles/edb.dir/FloatX.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:725: src/CMakeFiles/edb.dir/all] Error 2
make: *** [Makefile:160: all] Error 2
Ours is an issue with gdtoa. Check this:
mkdir ~/tmp && cd ~/tmpgit clone https://github.com/10110111/gdtoa-desktop.git && cd gdtoa-desktopmkdir build && cd buildcmake ..makesudo make install
After that try again with edb as previously. This time should go fine:
...
[ 11%] Building CXX object src/CMakeFiles/edb.dir/FixedFontSelector.cpp.o
[ 12%] Building CXX object src/CMakeFiles/edb.dir/FloatX.cpp.o
[ 12%] Building CXX object src/CMakeFiles/edb.dir/Font.cpp.o
...
[ 97%] Built target HardwareBreakpoints
Scanning dependencies of target HeapAnalyzer_autogen
[ 98%] Automatic MOC and UIC for target HeapAnalyzer
[ 98%] Built target HeapAnalyzer_autogen
Scanning dependencies of target HeapAnalyzer
[ 99%] Building CXX object plugins/HeapAnalyzer/CMakeFiles/HeapAnalyzer.dir/HeapAnalyzer_autogen/mocs_compilation.cpp.o
[ 99%] Building CXX object plugins/HeapAnalyzer/CMakeFiles/HeapAnalyzer.dir/DialogHeap.cpp.o
[100%] Building CXX object plugins/HeapAnalyzer/CMakeFiles/HeapAnalyzer.dir/HeapAnalyzer.cpp.o
[100%] Building CXX object plugins/HeapAnalyzer/CMakeFiles/HeapAnalyzer.dir/ResultViewModel.cpp.o
[100%] Linking CXX shared library ../../libHeapAnalyzer.so
[100%] Built target HeapAnalyzer
If you just git pulled and got this problem, then the proper fix should be not to manually build gdtoa-desktop, but rather to do
git submodule update --init
and resume building EDB.
@0x108391c Please keep in mind that the instruction says that it is mandatory to either do a recursive clone or do a git submodule update --init before doing cmake
@pwndumb and/or @0x108391c
Could you paste the output you had for your cmake command? If gdtoa-desktop was missing due to a non-recursive clone, you should have gotten an error preventing you from even running make.
Did either of you perhaps have an old clone, did an update or something and then tried to do a make?
@eteran
I think CMakeLists.txt should try harder to detect missing submodules: it should check on every make that everything is present (but not insist on up-to-dateness though). Otherwise it'll be fooled by a git pull that introduces new submodules.
@10110111 I agree and think that's what's happened here. I think they must have had a successful make, did a git pull which had a failed cmake, but the old Makefile was still around.
I have some ideas to make this a harder error.
@eteran I indeed did a recursive clone. As I guess @pwndumb did. It's a matter of c&p. I didn't try a git submodule update --init so I can't say, but if the logic behind this is OR (...to either do a recursive clone or do a git submodule update --init before doing cmake...) I didn't notice any error or warning before cmake.
The only reason I posted my first comment was because:
- I had the same issue
- You couldn't reproduce it
- The issue was still open
- For me worked
May be my suggestion was not technically the best but for me worked and I only wanted to give some help.
@0x108391c No worries! I appreciate your help :-)
Just trying to get to the bottom of the issue because as you saw above, when I run in a fresh Ubuntu 20 environment, it "just works".
Were you doing a build after a git pull to update to the latest perhaps? We did very recently add a new submodule, which I suspect is the issue.
I've improved the error handling in FloatX.cpp slightly so now the user should see something like this if their submodule is missing at build time:
[ 20%] Building CXX object src/CMakeFiles/edb.dir/FloatX.cpp.o
/home/eteran/projects/edb-debugger/src/FloatX.cpp:35:2: error: #error "gdtoa-desktop not found! Please make sure your submodules are up to date by running: git submodule update --init --recursive"
35 | #error "gdtoa-desktop not found! Please make sure your submodules are up to date by running: git submodule update --init --recursive"
| ^~~~~
make[2]: *** [src/CMakeFiles/edb.dir/build.make:501: src/CMakeFiles/edb.dir/FloatX.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:726: src/CMakeFiles/edb.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
Which hopefully will quickly steer them to the solution.
@eteran At least in my case, I didn't git pulled as it was a fresh creation of the local repo.
@0x108391c OK... well that IS fascinating and kinda breaks my current theory...
@0x108391c Would you be willing to do an experiment and help debug this issue?
What I'd like to try is the following:
-
uninstall the system wide gdtoa-desktop that you installed. If you still have
~/tmp/gdtoa-desktopyou may be able to just do amake uninstall? Maybe? If not, I can find out the files that are installed and explain a manual removal process -
Do a fresh recursive clone of master into a new directory
-
see if we can replicate the problem, and if so, report the entire
cmake+makeoutput?
If this is more effort than it is worth it to you, that's ok, but if you're able to help, that would be awesome :-).
Sure. But now I've to go. I'll try to get back to you.
I've improved the error handling in FloatX.cpp slightly so now the user should see something like this if their submodule is missing at build time
This is better than it was, but it's not the "right way". It's much better to have a CMake error at configuration stage, rather than to have configuration succeed giving false sense of correctness, and then get a failure in the middle of compilation.
@10110111 we already have cmake giving a hard error though.
if(NOT EXISTS "${PROJECT_SOURCE_DIR}/src/qhexview/.git" OR NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/gdtoa-desktop/.git")
message(SEND_ERROR "The git submodules are not available. Please run:\ngit submodule update --init --recursive")
endif()
Perhaps this needs to be upgraded a FATAL_ERROR?
It's strange if this doesn't generate an error after a git pull with a new submodule. No, I don't think we should use FATAL_ERROR here.
In fact, it does generate an error after a git pull without git submodule update --init. And FATAL_ERROR is no good here, since the user would only get errors one by one, without knowing how many still remain to be fixed, which is bad UX.
I suppose the real problem in this thread is not related to git pull at all.
LOL, reverting the push that made it fatal ;-).
Yea, I agree that it's unclear what the problem is. Hopefully, once 0x108391c is available again, they'll be able to shed some light on what causes this.
I still see this line in FloatX.cpp:
#if defined(HAVE_GDTOA)
It shouldn't be there any more with the submodules. Additionally, it adds to the confusion everyone has in this thread.
You are right that technically that #if can be removed, but I'm not sure it's harming anything. In fact, I actually leveraged it in my last push to make the error more concise.
My push undefines HAVE_GDTOA so that you only get the main error and it isn't hidden by following errors related to gdtoa not being found.
Ah, I was under the impression that it was no longer used elsewhere. OK, then the confusion was only mine :)
@0x108391c Thanks for your help!
It seems that your removal of gdtoa was not complete though, in the logs I see this:
-- Found gdtoa-desktop, version 0.1.20180730
Which means it found it installed system wide.
Could you please give me the instructions to remove it completely and I'll try again?
Sure thing :-)
If you installed using the method listed here: #798 (comment)
then it installed the following files (according to my logs):
-- Installing: /usr/local/lib/libgdtoa-desktop.so
-- Installing: /usr/local/include/gdtoa-desktop/arith.h
-- Installing: /usr/local/lib/pkgconfig/gdtoa-desktop.pc
-- Installing: /usr/local/include/gdtoa-desktop/gdtoa-desktop.h
So you can try running:
rm -rf /usr/local/lib/libgdtoa-desktop.so \
/usr/local/include/gdtoa-desktop/ \
/usr/local/lib/pkgconfig/gdtoa-desktop.pc
I think that'll do the trick.
OK, this will be helpful. Thanks :-)
OK, that is super odd, for some reason, even though it BUILT the gdtoa, it is not finding it! I'll have to investigate a bit and see what the story is. 👍🏻
Meanwhile, I mean, would you mind If I install it the nasty way? I'd like to see how performs edb under some tasks. Feel free to ask me whatever test you need.
Oh, of course do what you need to do to get things working!
But sadly, I can't reproduce locally, so I'll be asking you to uninstall/reinstall to do tests :-(. I wish there was an easier way...
For now, could you please just upload the output of:
tree build
While in the edb repo directory after a failed build? I'm curious if there is a file missing somehow.
Tree build: tree_build.log
I think we need the logs of make VERBOSE=1 instead of simply make. Otherwise CMake hides lots of debug information.
@10110111 I agree, though I'm pretty certain I see the problem :-).
For some reason, it is not generated the gdtoa-functions-renamed.h as it is missing from his source tree!
@0x108391c perhaps the contents of build/CMakeCache.txt?
It SEEMS like somehow GDTOA_RENAME_FUNCTION is being set to OFF, but I don't know how or why that would happen...
CMakeCache.txt CMakeCache.txt
GDTOA_RENAME_FUNCTIONS:BOOL=ON well, that's not it..
What if you try doing make -k multiple (say, 3) times? Does it finally succeed? I suspect this may be a race condition with parallel build vs the gdtoa_h target.
yea, I think at this point a make VERBOSE=1 is the next logical step.
@10110111 I think that cmake emits dependencies such that parallel make shouldn't be racey... but it's worth testing for sure.
I can say that I don't see anything in the CMakeLists.txt depending on gdtoa_h, so maybe we just need to add that explicitly?
make VERBOSE=1ormake -kmultiple (say, 3) times?
Neither, thanks. I've found the reproduction scenario.
@10110111 and @0x108391c
If we add add_dependencies(gdtoa-desktop gdtoa_h) on line 207 of lib/gdtoa-desktop/CMakeLists.txt (right aftet the add_custom_target) does that solve the problem?
I think edb should depend on gdtoa_h.
Though... I'm not actually sure. From the gdtoa-desktop package POV, it doesn't need this dependency. OTOH, the dep wouldn't actually harm, just maybe raise some questions for a future reader. What do you think?
Well for starters, does that fix the build? Once we know that, sure the simplest solution is to make edb depend on that (though I'd argue that if the build requested a build with rename functions, the build should produce that header...)
@eteran Yes, it indeed fixes the issue.
tree build tree_build.log
make VERBOSE=1 make_verbose.log
@0x108391c hotness.
OK, @10110111 I can push either a PR to make edb depend on that target or make gdtoa-desktop depend on that target. I don't have a STRONG opinion. But like I said, if we are renaming functions, my gut says to "just make the header then"
Your call though.
OK, I think libgdtoa-desktop.{so,a} doesn't really depend on any of the headers that are installed with it. So I propose the following fix for edb-debugger:
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 500612a3..4a138738 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -252,6 +252,7 @@ if(UNIX AND TARGET_ARCH_FAMILY_X86)
target_link_libraries(edb
gdtoa-desktop
)
+ add_dependencies(edb gdtoa_h)
endif()
endif()
easy peasy
Done. @0x108391c can you clone master (ideally in a fresh directory) and verify that it fixes it for you? If so, I'm going to happily close this mystery :-)
...
[ 19%] Built target gdtoa-desktop
Scanning dependencies of target gdtoa_h
[ 20%] Generating gdtoa-functions-renamed.h
[ 20%] Built target gdtoa_h
...
Fantastic! Thanks for your help in resolving this issue!