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

Tue Jul 21 15:21:40 PDT 2015

----- Original Message -----
> From: "C Bergström" <cbergstrom at pathscale.com>
> To: "Hans Wennborg" <hans at chromium.org>
> Cc: openmp-commits at dcs-maillist2.engr.illinois.edu, openmp-dev at dcs-maillist2.engr.illinois.edu
> Sent: Tuesday, July 21, 2015 3:33:51 PM
> Subject: Re: [Openmp-commits] [Openmp-dev] Large Refactor of CMake build	system
> 
> 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.

I don't believe that your problem is imaginary, but we also need to be able to reproduce it, or have a patch fixing it with some explanation of what's going on. Regardless, it is really important for the LLVM community to move forward with the new build system. We certainly have a release-candidate process, and the purpose of this process is to isolate and correct bugs. In that sense, the system is working as intended. The new CMake build system is in line with LLVM's general best practices, and the community has demanded that as a prerequisite for moving forward with integration with Clang. As a result, we really do need to get user feedback on this build system as opposed to any other.

 -Hal

> -----------
> 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.
> 
> _______________________________________________
> Openmp-commits mailing list
> Openmp-commits at dcs-maillist2.engr.illinois.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory