[Openmp-dev] [Openmp-commits] Large Refactor of CMake build system

[C Bergström]

My bad on including the autocrap output. We have cmake also building
binutils which does some autoconf stuff and its output ends up in our
cmake.log - (which detection is working correctly)
--------
Here's hopefully correct information
Summary - link.txt contains -static-libgcc

openmp-llvm/build-x86_32/src/CMakeFiles/omp.dir/link.txt
---------
/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/build/openmp-llvm/build-x86_32/src/CMakeFiles/omp.dir/link.txt:/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/build/Xcompiler/bin/pathcc
 -fPIC -g -O0 -Wl,--warn-shared-textrel -Wl,--as-needed
-Wl,--version-script=/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/src/enzo-suite/ekopath/openmp-llvm/runtime/src/exports_so.txt
-static-libgcc -Wl,-z,noexecstack -Wl,-fini=__kmp_internal_end_fini
-L/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/build/Xcompiler/lib/6.0.26/x8664/32
-msse2 -shared -Wl,-soname,libomp.so -o libomp.so
CMakeFiles/omp.dir/kmp_alloc.c.o CMakeFiles/omp.dir/kmp_atomic.c.o
CMakeFiles/omp.dir/kmp_csupport.c.o CMakeFiles/omp.dir/kmp_debug.c.o
CMakeFiles/omp.dir/kmp_itt.c.o CMakeFiles/omp.dir/kmp_environment.c.o
CMakeFiles/omp.dir/kmp_error.c.o CMakeFiles/omp.dir/kmp_global.c.o
CMakeFiles/omp.dir/kmp_i18n.c.o CMakeFiles/omp.dir/kmp_io.c.o
CMakeFiles/omp.dir/kmp_runtime.c.o CMakeFiles/omp.dir/kmp_settings.c.o
CMakeFiles/omp.dir/kmp_str.c.o CMakeFiles/omp.dir/kmp_tasking.c.o
CMakeFiles/omp.dir/kmp_taskq.c.o
CMakeFiles/omp.dir/kmp_threadprivate.c.o
CMakeFiles/omp.dir/kmp_utility.c.o CMakeFiles/omp.dir/z_Linux_util.c.o
CMakeFiles/omp.dir/kmp_gsupport.c.o
CMakeFiles/omp.dir/thirdparty/ittnotify/ittnotify_static.c.o
CMakeFiles/omp.dir/kmp_ftn_cdecl.c.o
CMakeFiles/omp.dir/kmp_ftn_extra.c.o
CMakeFiles/omp.dir/kmp_version.c.o
CMakeFiles/omp.dir/kmp_barrier.cpp.o
CMakeFiles/omp.dir/kmp_wait_release.cpp.o
CMakeFiles/omp.dir/kmp_affinity.cpp.o
CMakeFiles/omp.dir/kmp_dispatch.cpp.o
CMakeFiles/omp.dir/kmp_lock.cpp.o CMakeFiles/omp.dir/kmp_sched.cpp.o
CMakeFiles/omp.dir/kmp_taskdeps.cpp.o
CMakeFiles/omp.dir/kmp_cancel.cpp.o CMakeFiles/omp.dir/z_Linux_asm.s.o
-lpthread -ldl
/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/build/openmp-llvm/build-x86_64/src/CMakeFiles/omp.dir/link.txt:/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/build/Xcompiler/bin/pathcc
 -fPIC -g -O0 -Wl,--warn-shared-textrel -Wl,--as-needed
-Wl,--version-script=/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/src/enzo-suite/ekopath/openmp-llvm/runtime/src/exports_so.txt
-static-libgcc -Wl,-z,noexecstack -Wl,-fini=__kmp_internal_end_fini
-L/bamboo-agent-home/xml-data/build-dir/EKOPATH-EKOPATH6X8632-DEBUG/build/Xcompiler/lib/6.0.26/x8664/64
-msse2 -shared -Wl,-soname,libomp.so -o libomp.so
CMakeFiles/omp.dir/kmp_alloc.c.o CMakeFiles/omp.dir/kmp_atomic.c.o
CMakeFiles/omp.dir/kmp_csupport.c.o CMakeFiles/omp.dir/kmp_debug.c.o
CMakeFiles/omp.dir/kmp_itt.c.o CMakeFiles/omp.dir/kmp_environment.c.o
CMakeFiles/omp.dir/kmp_error.c.o CMakeFiles/omp.dir/kmp_global.c.o
CMakeFiles/omp.dir/kmp_i18n.c.o CMakeFiles/omp.dir/kmp_io.c.o
CMakeFiles/omp.dir/kmp_runtime.c.o CMakeFiles/omp.dir/kmp_settings.c.o
CMakeFiles/omp.dir/kmp_str.c.o CMakeFiles/omp.dir/kmp_tasking.c.o
CMakeFiles/omp.dir/kmp_taskq.c.o
CMakeFiles/omp.dir/kmp_threadprivate.c.o
CMakeFiles/omp.dir/kmp_utility.c.o CMakeFiles/omp.dir/z_Linux_util.c.o
CMakeFiles/omp.dir/kmp_gsupport.c.o
CMakeFiles/omp.dir/thirdparty/ittnotify/ittnotify_static.c.o
CMakeFiles/omp.dir/kmp_ftn_cdecl.c.o
CMakeFiles/omp.dir/kmp_ftn_extra.c.o
CMakeFiles/omp.dir/kmp_version.c.o
CMakeFiles/omp.dir/kmp_barrier.cpp.o
CMakeFiles/omp.dir/kmp_wait_release.cpp.o
CMakeFiles/omp.dir/kmp_affinity.cpp.o
CMakeFiles/omp.dir/kmp_dispatch.cpp.o
CMakeFiles/omp.dir/kmp_lock.cpp.o CMakeFiles/omp.dir/kmp_sched.cpp.o
CMakeFiles/omp.dir/kmp_taskdeps.cpp.o
CMakeFiles/omp.dir/kmp_cancel.cpp.o CMakeFiles/omp.dir/z_Linux_asm.s.o
-lpthread -ldl
--------
For clarification - by "unstable" I mean this does work on some hosts,
but not on others. I've tried to triage it down to specific versions
of cmake, but so far I can't find why it fails only on certain hosts.
(Yes this drives me crazy too)

We will probably open source some of these cmake wrappers in the near
future (1-2 months), but what they do is basically this

Top level cmake which just includes sub cmake directories. This allows
us to take a "just built" compiler and then build the necessary
runtime libraries. (we loop all specified targets - in the above
example that's 32 and 64bit x86)

So it's not a real "in-tree" llvm build, but it is "in-tree" in the
cmake sense. (I guess it would fall more on the side of standalone
build)

-j doesn't impact this. It's a configure time problem.

I really do appreciate the time others are taking on this. This isn't
an imaginary problem. Again - "works for me" isn't a good criteria to
merge stuff to a stable branch.
-----------
fwiw - the build dir in question in wiped every time. This isn't a
case of stale files or cmake cache.

On Wed, Jul 22, 2015 at 3:08 AM, Hans Wennborg <hans at chromium.org> wrote:
> On Tue, Jul 21, 2015 at 11:20 AM, C Bergström <cbergstrom at pathscale.com> wrote:
>> My observation is that it's not consistently working and that's why
>> I'm even more upset and nervous about this change.
>>
>> Further, "it works for me" is a very bad reason to go screw up a
>> stable branch and to continue to advocate that it so strongly.
>
> I've tried to reproduce the problem described here by hacking up a
> local clang that doesn't support the -static-libgcc flag. I verified
> that the cmake correctly identifies that the flag is not supported,
> that it's not used during the build, and doesn't show up in the build
> file (it would show in build/runtime/src/CMakeFiles/omp.dir/link.txt
> if supported). I also didn't see anything wrong in the cmake file.
>
> I'm sympathetic to your build issue, but I do think the onus is on you
> to show that something is broken here in a way that the community can
> reproduce or at least understand.
>

If I knew the exact root cause - I'd be the 1st person to send a
patch. So far I haven't had time to figure out *exactly* what or where
is the problem.

The "debug" patch does resolve the issue on the problem hosts.