<div dir="ltr"> We seem to have an issue on linux with both the CMakefiles from pathscale (lightly modified) and my recreation of the same approach in cmake. On darwin, my attached CMakelist.txt, when placed in openmp/runtime/src, has no problems compiling and linking libiomp5.dylib…<div>
<br></div><div>% cd openmp/runtime/src</div><div>% mkdir build</div><div>% cd build</div><div>% cmake ..</div><div>% make VERBOSE=1</div><div><br></div><div>However on x86_64, Fedora 15, with the clang set to use clang-omp (currently based on 3.4), I find the final linkage fails with…</div>
<div><br></div><div><div>Linking CXX shared library libiomp5.so</div><div>/usr/bin/cmake -E cmake_link_script CMakeFiles/iomp5.dir/link.txt --verbose=1</div><div>clang++ -fPIC -D USE_ITT_BUILD -D NDEBUG -D KMP_ARCH_STR="\"Intel(R) 64\"" -D _GNU_SOURCE -D _REENTRANT -D KMP_USE_ASSERT -D BUILD_I8 -D BUILD_TV -D KMP_LIBRARY_FILE=\"libiomp5.so\" -D KMP_VERSION_MAJOR=5 -D CACHE_LINE=64 -D KMP_ADJUST_BLOCKTIME=1 -D BUILD_PARALLEL_ORDERED -D KMP_ASM_INTRINS -D USE_LOAD_BALANCE -D USE_CBLKDATA -D GUIDEDLL_EXPORTS -D KMP_GOMP_COMPAT -D KMP_USE_ADAPTIVE_LOCKS=1 -D KMP_DEBUG_ADAPTIVE_LOCKS=0 -D OMP_50_ENABLED=0 -D OMP_41_ENABLED=0 -D OMP_40_ENABLED=1 -D OMP_30_ENABLED=1 -D USE_ITT_NOTIFY=1 -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_ -D KMP_TDATA_GTID -D _KMP_BUILD_TIME="\"2014-05-31 14:03:22 UTC\"" -fPIC -Wno-unused-value -Wno-switch -Wno-deprecated-register -fno-exceptions -shared -Wl,-soname,libiomp5.so -o libiomp5.so CMakeFiles/iomp5.dir/thirdparty/ittnotify/ittnotify_static.c.o CMakeFiles/iomp5.dir/kmp_affinity.cpp.o CMakeFiles/iomp5.dir/kmp_alloc.c.o CMakeFiles/iomp5.dir/kmp_atomic.c.o CMakeFiles/iomp5.dir/kmp_cancel.cpp.o CMakeFiles/iomp5.dir/kmp_csupport.c.o CMakeFiles/iomp5.dir/kmp_debug.c.o CMakeFiles/iomp5.dir/kmp_dispatch.cpp.o CMakeFiles/iomp5.dir/kmp_environment.c.o CMakeFiles/iomp5.dir/kmp_error.c.o CMakeFiles/iomp5.dir/kmp_ftn_cdecl.c.o CMakeFiles/iomp5.dir/kmp_ftn_extra.c.o CMakeFiles/iomp5.dir/kmp_global.c.o CMakeFiles/iomp5.dir/kmp_gsupport.c.o CMakeFiles/iomp5.dir/kmp_i18n.c.o CMakeFiles/iomp5.dir/kmp_io.c.o CMakeFiles/iomp5.dir/kmp_itt.c.o CMakeFiles/iomp5.dir/kmp_lock.cpp.o CMakeFiles/iomp5.dir/kmp_runtime.c.o CMakeFiles/iomp5.dir/kmp_sched.cpp.o CMakeFiles/iomp5.dir/kmp_settings.c.o CMakeFiles/iomp5.dir/kmp_str.c.o CMakeFiles/iomp5.dir/kmp_taskdeps.cpp.o CMakeFiles/iomp5.dir/kmp_tasking.c.o CMakeFiles/iomp5.dir/kmp_taskq.c.o CMakeFiles/iomp5.dir/kmp_threadprivate.c.o CMakeFiles/iomp5.dir/kmp_utility.c.o CMakeFiles/iomp5.dir/kmp_version.c.o CMakeFiles/iomp5.dir/z_Linux_util.c.o z_Linux_asm.o </div>
<div>/usr/bin/ld: libiomp5.so: version node not found for symbol omp_test_lock_@@VERSION</div><div>/usr/bin/ld: failed to set dynamic section sizes: Bad value</div><div>clang: error: linker command failed with exit code 1 (use -v to see invocation)</div>
<div>make[2]: *** [libiomp5.so] Error 1</div><div>make[2]: Leaving directory `/home/howarth/llvm-clang-omp/openmp/runtime/src/build'</div><div>make[1]: *** [CMakeFiles/iomp5.dir/all] Error 2</div><div>make[1]: Leaving directory `/home/howarth/llvm-clang-omp/openmp/runtime/src/build'</div>
<div>make: *** [all] Error 2</div></div><div><br></div><div>A careful comparison with the log from 'make compiler=clang' on x86_64 Fedora 15 reveals no substantial differences to the cmake build other than the details of how clang is invoked to do the linkage…</div>
<div><br></div><div><div>----- 1/1 --- unstripped/.dir -----</div><div>mkdir -p unstripped/</div><div>touch unstripped/.dir</div><div>----- 1/1 --- unstripped/libiomp5.so.lst -----</div><div>echo ittnotify_static.o kmp_affinity.o kmp_alloc.o kmp_atomic.o kmp_cancel.o kmp_csupport.o kmp_debug.o kmp_dispatch.o kmp_environment.o kmp_error.o kmp_ftn_cdecl.o kmp_ftn_extra.o kmp_global.o kmp_gsupport.o kmp_i18n.o kmp_io.o kmp_itt.o kmp_lock.o kmp_runtime.o kmp_sched.o kmp_settings.o kmp_str.o kmp_taskdeps.o kmp_tasking.o kmp_taskq.o kmp_threadprivate.o kmp_utility.o kmp_version.o z_Linux_asm.o z_Linux_util.o > unstripped/libiomp5.so.lst</div>
<div>----- 1/1 --- unstripped/libiomp5.so -----</div><div>clang -shared -Wl,-soname=libiomp5.so -Wl,--as-needed -Wl,-z,noexecstack -g -Wsign-compare -Wl,--warn-shared-textrel -Wl,-fini=__kmp_internal_end_fini -pthread -fPIC -Wl,--version-script=../../src/exports_so.txt -o unstripped/libiomp5.so $(cat unstripped/libiomp5.so.lst) -Wl,-ldl </div>
<div>----- 1/1 --- unstripped/libiomp5.dbg -----</div><div>objcopy --only-keep-debug unstripped/libiomp5.so unstripped/libiomp5.dbg </div><div>----- 1/1 --- libiomp5.dbg -----</div><div>cp -f unstripped/libiomp5.dbg libiomp5.dbg</div>
<div>----- 1/1 --- stripped/.dir -----</div><div>mkdir -p stripped/</div><div>touch stripped/.dir</div><div>----- 1/1 --- stripped/libiomp5.so -----</div><div>objcopy --strip-debug unstripped/libiomp5.so stripped/libiomp5.so.tmp</div>
<div>objcopy --add-gnu-debuglink=libiomp5.dbg stripped/libiomp5.so.tmp stripped/libiomp5.so</div><div>----- 1/1 --- libiomp5.so -----</div><div>cp -f stripped/libiomp5.so libiomp5.so</div><div>----- 1/1 --- test-touch-rt/.dir -----</div>
<div>mkdir -p test-touch-rt/</div><div>touch test-touch-rt/.dir</div><div>----- 1/1 --- test-touch-rt/.test -----</div><div>rm -f test-touch-rt/*</div><div>cc -pthread -o test-touch-rt/test-touch -m64 ../../src/test-touch.c libiomp5.so </div>
<div>rm -f test-touch-rt/test-touch</div><div>cc -pthread -o test-touch-rt/test-touch -m64 ../../src/test-touch.c libiomp5.so -Wl,--verbose > test-touch-rt/build.log 2>&1</div><div>LD_LIBRARY_PATH=".:/usr/lib64/alliance/lib:/usr/local/share/man:/usr/share/man:/usr/lib64/alliance/man" KMP_VERSION=1 test-touch-rt/test-touch</div>
</div><div><br></div><div>One difference between the cmake build and the 'make compiler=clang' build, is that CMakelist.txt doesn't pass all of the COMMON_FLAGS when assembling z_Linux_asm.s due to the compiler being invoked via perl which chokes on the quotes…</div>
<div><br></div><div><div>----- 1/1 --- z_Linux_asm.o -----</div><div>clang -I ./ -I ../../src/ -I ../../src/i18n/ -I ../../src/include/40/ -I ../../src/thirdparty/ittnotify/ -D USE_ITT_BUILD -D NDEBUG -D KMP_ARCH_STR="\"Intel(R) 64\"" -D _GNU_SOURCE -D _REENTRANT -D KMP_USE_ASSERT -D BUILD_I8 -D BUILD_TV -D KMP_LIBRARY_FILE=\"libiomp5.so\" -D KMP_VERSION_MAJOR=5 -D CACHE_LINE=64 -D KMP_ADJUST_BLOCKTIME=1 -D BUILD_PARALLEL_ORDERED -D KMP_ASM_INTRINS -D USE_LOAD_BALANCE -D USE_CBLKDATA -D GUIDEDLL_EXPORTS -D KMP_GOMP_COMPAT -D KMP_USE_ADAPTIVE_LOCKS=1 -D KMP_DEBUG_ADAPTIVE_LOCKS=0 -D OMP_50_ENABLED=0 -D OMP_41_ENABLED=0 -D OMP_40_ENABLED=1 -D OMP_30_ENABLED=1 -D USE_ITT_NOTIFY=1 -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_ -D KMP_TDATA_GTID -D _KMP_BUILD_TIME="\"2014-05-31 18:05:28 UTC\"" -D KMP_ARCH_X86_64 -c -x assembler-with-cpp -o z_Linux_asm.o ../../src/z_Linux_asm.s</div>
</div><div><br></div><div>in the <a href="http://build.pl">build.pl</a> based build vs the following for the cmake build…</div><div><br></div><div><div>[ 0%] Generating z_Linux_asm.o</div><div>clang++ -c -o z_Linux_asm.o -D KMP_ASM_INTRINS -D KMP_GOMP_COMPAT -D KMP_ARCH_X86_64 -x assembler-with-cpp /home/howarth/llvm-clang-omp/openmp/runtime/src/z_Linux_asm.s</div>
</div><div><br></div><div>A Google search suggests that folks running into this "version node not found for symbol " error normally solve it with --disable-symver in configure but it is unclear if a similar option exists in cmake or if it would even have the expected impact here.</div>
<div> Jack</div><div>ps The attached CMakefile.txt has the same behavior as the Pathscale ones (in emulating the <a href="http://build.pl">build.pl</a> build of openmp) with a couple corrections for openmp svn. On linux, -D KMP_TDATA_GTID is passed like in the 'make compiler=clang' build. When z_Linux_asm.s is compiled, the missing -D KMP_ASM_INTRINS was added into the command line to match the 'make compiler=clang' build on both Apple and Linux. </div>
<div><br></div><div>pps The actual failing linkage line (as emitted from clang++ with -v) is…</div><div><br></div><div><div> "/usr/bin/ld" --hash-style=gnu --no-add-needed --build-id --eh-frame-hdr -m elf_x86_64 -shared -o libiomp5.so /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.6.3/crtbeginS.o -L/usr/lib/gcc/x86_64-redhat-linux/4.6.3 -L/usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../.. -L/lib -L/usr/lib -soname libiomp5.so CMakeFiles/iomp5.dir/thirdparty/ittnotify/ittnotify_static.c.o CMakeFiles/iomp5.dir/kmp_affinity.cpp.o CMakeFiles/iomp5.dir/kmp_alloc.c.o CMakeFiles/iomp5.dir/kmp_atomic.c.o CMakeFiles/iomp5.dir/kmp_cancel.cpp.o CMakeFiles/iomp5.dir/kmp_csupport.c.o CMakeFiles/iomp5.dir/kmp_debug.c.o CMakeFiles/iomp5.dir/kmp_dispatch.cpp.o CMakeFiles/iomp5.dir/kmp_environment.c.o CMakeFiles/iomp5.dir/kmp_error.c.o CMakeFiles/iomp5.dir/kmp_ftn_cdecl.c.o CMakeFiles/iomp5.dir/kmp_ftn_extra.c.o CMakeFiles/iomp5.dir/kmp_global.c.o CMakeFiles/iomp5.dir/kmp_gsupport.c.o CMakeFiles/iomp5.dir/kmp_i18n.c.o CMakeFiles/iomp5.dir/kmp_io.c.o CMakeFiles/iomp5.dir/kmp_itt.c.o CMakeFiles/iomp5.dir/kmp_lock.cpp.o CMakeFiles/iomp5.dir/kmp_runtime.c.o CMakeFiles/iomp5.dir/kmp_sched.cpp.o CMakeFiles/iomp5.dir/kmp_settings.c.o CMakeFiles/iomp5.dir/kmp_str.c.o CMakeFiles/iomp5.dir/kmp_taskdeps.cpp.o CMakeFiles/iomp5.dir/kmp_tasking.c.o CMakeFiles/iomp5.dir/kmp_taskq.c.o CMakeFiles/iomp5.dir/kmp_threadprivate.c.o CMakeFiles/iomp5.dir/kmp_utility.c.o CMakeFiles/iomp5.dir/kmp_version.c.o CMakeFiles/iomp5.dir/z_Linux_util.c.o z_Linux_asm.o -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.6.3/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crtn.o</div>
<div>/usr/bin/ld: libiomp5.so: version node not found for symbol omp_test_lock_@@VERSION</div><div>/usr/bin/ld: failed to set dynamic section sizes: Bad value</div></div><div><br></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Sat, May 31, 2014 at 9:51 AM, Jack Howarth <span dir="ltr"><<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">C. Bergström,<br> My initial attempts are just to duplicate the behavior of 'make compiler=clang' as closely as possible to order to maintain continuity between the two build approaches. I have been pondering the usage of the external_symbols.lst file in the <a href="http://build.pl" target="_blank">build.pl</a> approach. It is unclear to me that this is really hiding any symbols. Shouldn't we just be passing -fvisibility=hidden to the c++ compiler and adding explicit instances of<br>
<br>__attribute__ ((visibility ("default")))<br><br>to the c++ source files for those symbols we want to export from libiomp?<span class="HOEnZb"><font color="#888888"><br> Jack</font></span></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 31, 2014 at 12:18 AM, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 05/31/14 11:13 AM, Alp Toker wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 31/05/2014 06:58, "C. Bergström" wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jack - you have permission to use/abuse the publicly available PathScale copyright portions of code in our github repo in accordance with the license they are published under. I wish there was less stupidity and red tape around this community, but c'est la vie.<br>
</blockquote>
<br>
Cool!<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/* Seriously, it's not a simple email "OK" is some binding contract which is like or can replace an actual contributor agreement. */<br>
<br>
Since I have no authority to review OMP related codes it's unlikely I'll reply or participate further in any of those topics.<br>
</blockquote>
<br>
Disagree. The authority is for all of us to share and nobody should have told you otherwise.<br>
</blockquote></div>
last reply - I really don't want to bring this up again or hi-jack the author's thread<br>
clarification - Hal and Chandler have said I'm not qualified to do binding review on clang OMP sema or other OMP related changes. As such, others would still have to review the changes and I just lost interest to participate</end><br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>