Closed siedentop closed 5 years ago
Notes & Updates:
src/models/ld.cc
it will also complain about -plugin-opt
, --sysroot
, --eh-frame-hdr
. Patching all these lead to stat()
errors.cmake
as gg infer cmake ...
seems to help. This still leaves this:
[ 16%] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/OptParserEmitter.cpp.o
terminate called after throwing an instance of 'unix_error'
what(): stat: No such file or directory
/home/ubuntu/gg/src/models/wrappers/ld: line 2: 32432 Aborted (core dumped) model-ld "$@"
collect2: error: ld returned 134 exit status
utils/PerfectShuffle/CMakeFiles/llvm-PerfectShuffle.dir/build.make:94: recipe for target 'bin/llvm-PerfectShuffle' failed
make[2]: *** [bin/llvm-PerfectShuffle] Error 1
CMakeFiles/Makefile2:19614: recipe for target 'utils/PerfectShuffle/CMakeFiles/llvm-PerfectShuffle.dir/all' failed
make[1]: *** [utils/PerfectShuffle/CMakeFiles/llvm-PerfectShuffle.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
@siedentop have you try to build llvm
without any flags?
git clone https://github.com/llvm/llvm-project.git
cd llvm-project
mkdir build_gg && cd build_gg
gg init
gg infer cmake ./../llvm
gg infer cmake --build .
Btw, I'm not sure that gg
will be ok with llvm
due to cmake. But currently, the build process is reaching > 23% completion and still working (it is running on my laptop, so it's not so fast).
Thanks, @ssnickolay for taking a look.
I had tried gg init; gg infer cmake ... ; gg infer make ...
before, but now tried your variant. I only get to 8%.
It compiles fine past the 8% building locally, so it's not a dependency which is missing.
188 git clone https://github.com/llvm/llvm-project
189 cd llvm-project/
190 mkdir build_gg
191 cd build_gg
192 gg init
193 gg infer cmake ./../llvm
194 source ~/src/gg/environment.sh
195 gg infer cmake ./../llvm
196 gg infer cmake --build .
The build step fails with the following.
...
Scanning dependencies of target llvm-tblgen
[ 8%] Linking CXX executable ../../bin/llvm-tblgen
╭╼ generating model for g++
├─ linked: TYgQkWjMxZQiDlekeM6Vk_FyaNImIejV4MbvTshfSM4Y000028b5
╰╼ output: ../../bin/llvm-tblgen
[ 8%] Built target llvm-tblgen
Scanning dependencies of target AttributeCompatFuncTableGen
[ 8%] Building AttributesCompatFunc.inc...
→ Loading the thunks... done (52 ms).
In file included from /home/ubuntu/llvm-project/llvm/lib/Support/Process.cpp:93:0:
/home/ubuntu/llvm-project/llvm/lib/Support/Unix/Process.inc: In static member function 'static unsigned int llvm::sys::Process::GetRandomNumber()':
/home/ubuntu/llvm-project/llvm/lib/Support/Unix/Process.inc:454:10: error: 'arc4random' was not declared in this scope
/home/ubuntu/llvm-project/llvm/lib/Support/Unix/Process.inc:454:10: note: suggested alternative: 'srandom'
rmdir /tmp/thunk-execute.V3u3PY: Directory not empty
std::exception
`T242qEgXj1ATQwnyXqbhLjZYFs7gWbVFVuZNvJVaoX5E000003dd': process exited with failure status 1
gg-force: `T242qEgXj1ATQwnyXqbhLjZYFs7gWbVFVuZNvJVaoX5E000003dd': process exited with failure status 5
gg-force-and-run: `gg-force': process exited with failure status 1
lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/build.make:93: recipe for target 'lib/IR/AttributesCompatFunc.inc' failed
make[2]: *** [lib/IR/AttributesCompatFunc.inc] Error 1
CMakeFiles/Makefile2:1710: recipe for target 'lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/all' failed
make[1]: *** [lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2
Hi @siedentop and @ssnickolay,
Thank you for opening this issue, and of course for trying out gg
!
One important concept in using gg
for compilation is the separation between generating the dependency graph for the build (the part done with gg infer
) and doing the actual work (the part done with gg force
). LLVM build system is a bit complicated for gg
for two reasons:
gcc
in the Makefile
s and that makes it a bit troublesome for gg
to do the inference (which relies on manipulating the PATH
). One workaround is to run cmake
as follows:gg init
CXX="g++" CC="gcc" GG_BYPASS=1 gg infer cmake <SRC-PATH>
This will generate the Makefile
s that can be used to do the inference later.
To compile the binary, after step (1), run the following commands:
gg infer make -j`nproc` llvm-tblgen
gg force --jobs 1200 --engine lambda bin/llvm-tblgen
And now, you can infer the whole thing:
gg infer make -j`nproc`
If you look at the build/bin/
folder, you can see the target binaries. To compile, for example llvm-ar
, run:
gg force --jobs 2000 --engine lambda bin/llvm-ar
Thanks again for giving gg
a try. We understand that this is far from perfect and we're thinking of ways to make gg
easier to use with more peculiar build systems. If you have any suggestions or comments, please let us know!
--Sadjad
@sadjad first of all, thanks for the great work and excellent explanation of our mistakes.
I have tried your instruction and everything works fine except one little thing: you should pass gg's (aka patched) g++\gcc
to cmake
command because CXX="g++" CC="gcc"
just takes your original g++\gcc
(and builds target bin without gg
), so:
echo $GG_MODELPATH
# => path to gg's wrappers (see more in README)
CXX="$GG_MODELPATH/g++" CC="$GG_MODELPATH/gcc" GG_BYPASS=1 gg infer cmake <SRC-PATH>
...
And after that, everything works as it should:
We understand that this is far from perfect and we're thinking of ways to make gg easier to use with more peculiar build systems.
As far as I understand, passing CXX\CC
to CMake
should be a common workaround and maybe add an example to README
or to examples
folder? Moreover, we have a ready-made example for this above. I can take care of this if you want :)
@ssnickolay, I just created and pushed a small wrapper for CMake. Now, the user can just run gg infer cmake ../src/
, and it will be handled properly.
It would still be very nice if we could have an example of using CMake in the README
:)
I just created and pushed a small wrapper for CMake
Ah, it is so simple, I love it!
It would still be very nice if we could have an example of using CMake in the README :)
Actually, I thought about something more reproducible. What do you think if I cover current examples via Docker
? People who have not (or don't like) Docker
could still run examples on local machines. But other users (who have not Ubuntu
, like me) could run examples via Docker
.
I thought about it because I spent a couple of hours to run the excamera
example yesterday. And I still working on running viddec
examples because as far as I understand part of related files contains in tools/python_sdk/examples/viddec-example
folder (I mean fetch-deps.sh
).
tl;dr I want to actualize examples (and add example of using CMake
) and do it more comfortable to reproduce If you okay with it :)
Small update: Here is a screen cast: https://asciinema.org/a/262982 for LLVM.
@ssnickolay , I'd like to know how you got the excamera
example to run?
@siedentop I'll write instructions in the coming days and mention you ;)
It looks like the
-plugin
switch is not understood bywrappers/ld
and hence crashes gg.I was trying to build LLVM with gg.
From opening the core dump with gdb:
Core was generated by
model-ld -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/'. `Question 1: How do I enable debug symbols for gg, such that the core dump is actually helpful?
Here is what
man ld
has to say about-plugin
:Note, LTO was disabled in the CMake config for LLVM by default and has stayed like that.
My Bash history (from a fresh Ubuntu 18.04 EC2 instance):
Removed non-relevant lines