(no subject)

Jack_Howarth · May 30, 2014, 10:28pm

Attached is a first pass at modifying the cmakefiles from https://github.com/pathscale/openmprtl/blob/master/itt/libomp_oss to build openmp. I noticed that the existing build.pl doesn’t actually build a fat shared library on darwin. The attached changes can does this in an indirect fashion with…

% cd runtime
% mkdir build_32
% cd build_32
% cmake -DARCH=“32” …
% make VERBOSE=1
% cd …
% mkdir build_32e
% cmake -DARCH=“32e” …
% make VERBOSE=1
% cd …
% lipo ./build_32/src/libiomp5.dylib ./build_32e/src/libiomp5.dylib -create -o libiomp5.dylib
% file libiomp5.dylib

libiomp5.dylib: Mach-O universal binary with 2 architectures
libiomp5.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
libiomp5.dylib (for architecture i386): Mach-O dynamically linked shared library i386

Normally we could do this in cmake by passing ‘-arch i386 -arch x86_64’ but use of assembly code in the build gums that up.

cmakefiles.diff (6.65 KB)

Finkel_Hal_J · May 30, 2014, 10:40pm

Jack,

Before you go too far with this, do we have Pathscale's explicit contribution of their build files? (I've cc'd C. Bergstrom so that he can comment directly).

Thanks,
Hal

Jack_Howarth · May 30, 2014, 11:10pm

Hal,
Even if that is problematic, starting over is fairly straight-forward. Their CMakelists.txt is simply a directly repetition of the commands emitted from the build as done by build.pl. So if they are difficult about it, just take a printout of the output for the current build with 'make compiler=clang" and code the Cmakelist.txt from that. If you look carefully, you will see that they are replicating this down to the exact order of the parameters on the compiler calls. It is very difficult to see how that could be intellectual property in any fashion since replicating the output of the build.pl currently in llvm.org’s openmp results in the same ordering. Note that their files are only a crude starting point and nowhere near what we will need for llvm.
Jack

Finkel_Hal_J · May 30, 2014, 11:18pm

From: "Jack Howarth" <howarth.mailing.lists@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: openmp-dev@dcs-maillist2.engr.illinois.edu, "C. Bergström" <cbergstrom@pathscale.com>
Sent: Friday, May 30, 2014 6:10:22 PM
Subject: Re: [Openmp-dev] (no subject)

Hal,
Even if that is problematic, starting over is fairly
straight-forward. Their CMakelists.txt is simply a directly
repetition of the commands emitted from the build as done by
build.pl . So if they are difficult about it, just take a printout
of the output for the current build with 'make compiler=clang" and
code the Cmakelist.txt from that. If you look carefully, you will
see that they are replicating this down to the exact order of the
parameters on the compiler calls. It is very difficult to see how
that could be intellectual property in any fashion since replicating
the output of the build.pl currently in llvm.org 's openmp results
in the same ordering. Note that their files are only a crude
starting point and nowhere near what we will need for llvm.

Yes, I understand. An C. has generally been forthcoming about this kind of thing. However, I'm not about to make an IP call here, and we have a policy. If he does not grant explicit permission soon, I recommend that you start over.

-Hal

Jack_Howarth · May 30, 2014, 11:21pm

Hal,
Also note that they are replicating the build from build.pl down to the exact order of source file compilation. So the question arises, to what degree is is it invalid to even glance at their Cmakelist.txt for overall ideas on how to do this. Considering that they are simply emitting the same build commands as build.pl (to which we already have license), I imagine we would have to code in a very similar manner even if done from scratch, i.e., use instances of add_custom_command to manually emit the same build.pl commands. There probably aren’t that many ways to code that in cmake.
Jack

Finkel_Hal_J · May 30, 2014, 11:30pm

From: "Jack Howarth" <howarth.mailing.lists@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: openmp-dev@dcs-maillist2.engr.illinois.edu, "C. Bergström" <cbergstrom@pathscale.com>
Sent: Friday, May 30, 2014 6:21:19 PM
Subject: Re: [Openmp-dev] (no subject)

Hal,
Also note that they are replicating the build from build.pl down to
the exact order of source file compilation. So the question arises,
to what degree is is it invalid to even glance at their
Cmakelist.txt for overall ideas on how to do this. Considering that
they are simply emitting the same build commands as build.pl (to
which we already have license), I imagine we would have to code in a
very similar manner even if done from scratch, i.e., use instances
of add_custom_command to manually emit the same build.pl commands.
There probably aren't that many ways to code that in cmake.
Jack

Yep, I understand. That's why what you did could be considered imprudent -- In any case, let's give C. a chance to solve this problem for you.

In case that does not work out and it makes things easier, I've attached another alternate makefile that I use to build this library. Converting this into cmake form is also not too hard.

-Hal

Makefile.bgq (2.5 KB)

Jack_Howarth · May 30, 2014, 11:34pm

In case it helps the process, below are the changes to their files for context…

— CMakeLists.txt.orig 2014-05-30 19:25:35.000000000 -0400
+++ CMakeLists.txt 2014-05-30 18:11:18.000000000 -0400
@@ -2,11 +2,8 @@

project(libiomp)

-enable_language(Fortran)
enable_language(C ASM)

Jack_Howarth · May 31, 2014, 12:04am

Hal,
Did you base your Makefile on the behavior of build.pl from ‘make compiler=gcc’? On darwin, I find that the exact build as replicated from the behavior of build.pl using ‘make compiler=clang’ produces a different object file list….

— Makefile.bgq 2014-05-30 19:59:16.000000000 -0400
+++ Makefile.jwh 2014-05-30 20:01:08.000000000 -0400
@@ -7,10 +7,10 @@

CPPFLAGS = ${FEATURE_FLAGS} -D__float128=‘long double’

-CC = powerpc64-bgq-linux-gcc
-CXX = powerpc64-bgq-linux-g++
+CC = clang
+CXX = clang++

-all: build/libiomp5.a build/libiomp5.so
+all: build/libiomp5.a build/libiomp5.dylib

build/.dir:
mkdir -p build
@@ -28,6 +28,7 @@
${CC} -x c++ -c ${CPPFLAGS} -g -O3 -Isrc -Ibuild -o $@ $<

OBJS = build/kmp_alloc.o \

build/kmp_affinity.o
build/kmp_atomic.o
build/kmp_cancel.o
build/kmp_csupport.o
@@ -37,8 +38,8 @@
build/kmp_error.o
build/kmp_ftn_cdecl.o
build/kmp_ftn_extra.o \

build/kmp_ftn_stdcall.o
build/kmp_global.o \

build/kmp_gsupport.o
build/kmp_i18n.o
build/kmp_io.o
build/kmp_itt.o
@@ -53,7 +54,8 @@
build/kmp_utility.o
build/kmp_version.o
build/kmp_lock.o \

build/z_Linux_util.o

build/z_Linux_util.o \
build/ittnotify_static.o

BGSYS_FLOOR=$(shell readlink /bgsys/drivers/ppcfloor)
build/libiomp5.so: $(OBJS)
[prrg4:~/llvm-svn/openmp-3.5.0/runtime] howarth%

Finkel_Hal_J · May 31, 2014, 12:13am

Jack,

No, I based my makefile on a manual examination of the various .mk files in the runtime/src directory (+ some trial and error). It is for a port of the library to a ppc64-based system, so you'll need to make some changes (like adding back the asm file) to make it work on Darwin.

-Hal

Jack_Howarth · May 31, 2014, 3:46am

Hal,
The attached Cmakefiles.txt, for placement in openmp/runtime/src, is as simple as I think the file can be and still reproduce the build obtained from build.pl with ‘make compiler=clang’.
Between the syntax required for the perl scripts in the tools subdirectory and the syntax requirements of cmake, I don’t see this changing much. Everything in there is essential to the build. For instance, if you drop….

set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)
set_source_files_properties(${ASM_SOURCES} PROPERTIES LANGUAGE CXX)

you will get compile time errors in clang for z_Linux_util.c on darwin which wants to use a c++ compiler here.
Jack

CMakeLists.txt (3.69 KB)

_C_Bergstrom · May 31, 2014, 3:58am

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.

/* Seriously, it's not a simple email "OK" is some binding contract which is like or can replace an actual contributor agreement. */

Since I have no authority to review OMP related codes it's unlikely I'll reply or participate further in any of those topics.

I hope it saves you at least a few minutes Jack.. good luck and thanks for taking this on.

Alp_Toker · May 31, 2014, 4:09am

Hal,
The attached Cmakefiles.txt, for placement in openmp/runtime/src, is as simple as I think the file can be and still reproduce the build obtained from build.pl <http://build.pl> with 'make compiler=clang'.
Between the syntax required for the perl scripts in the tools subdirectory and the syntax requirements of cmake, I don't see this changing much. Everything in there is essential to the build. For instance, if you drop….

set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)
set_source_files_properties(${ASM_SOURCES} PROPERTIES LANGUAGE CXX)

you will get compile time errors in clang for z_Linux_util.c on darwin which wants to use a c++ compiler here.

z_Linux_util.c uses C++ default arguments so it might as well be renamed to z_Linux_util.cpp, or alternatively just remove the C++ism. Either way would let you drop the line.

If you go and rewrite the CMake files or get a colleague to do so from a description it's inconsequential if the result is similar to something else -- don't worry too much about that, as long as it's not derived from the original (which presumably has issues, given the radio silence).

Personally I've done this before out of necessity and always ended up with something better -- keeping in mind that you're allowed to modify the source as in my aforementioned example, there's actually plenty of scope for improvement to make things engaging.

Alp.

Alp_Toker · May 31, 2014, 4:13am

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.

Cool!

/* Seriously, it's not a simple email "OK" is some binding contract which is like or can replace an actual contributor agreement. */

Since I have no authority to review OMP related codes it's unlikely I'll reply or participate further in any of those topics.

Disagree. The authority is for all of us to share and nobody should have told you otherwise.

Cheers
Alp.

_C_Bergstrom · May 31, 2014, 4:18am

last reply - I really don't want to bring this up again or hi-jack the author's thread
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>

Jack_Howarth · May 31, 2014, 4:18am

Hal,
Actually, this needs some additional work to truly mimic the 'make compiler=clang; build. We need additional add_custom_command’s to handle this bit…

----- 1/1 — kmp_dummy.c -----
echo “void __kmp_dummy() {}” > kmp_dummy.c
----- 1/1 — kmp_dummy.o -----
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.dylib" -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 -I/sw/include -c -fPIC -O2 -Wno-unused-value -Wno-switch -Wno-deprecated-register -fno-exceptions -x c++ -std=c++0x -o kmp_dummy.o kmp_dummy.c
----- 1/1 — external-objects.lst -----
perl …/…/tools/required-objects.pl --os=mac --arch=32e
–base 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 kmp_dummy.o --extra --print-extra > external-objects.lst.tmp
warning: nm: no name list
echo “kmp_dummy.o” >> external-objects.lst.tmp
mv external-objects.lst.tmp external-objects.lst
----- 1/1 — external-symbols.lst -----
nm -goj $(cat external-objects.lst) > external-symbols.lst.0.tmp
cut -f2 -d" " external-symbols.lst.0.tmp > external-symbols.lst.1.tmp
mv external-symbols.lst.1.tmp external-symbols.lst
----- 1/1 — iomp.o -----
ld -r -unexported_symbols_list external-symbols.lst
-non_global_symbols_strip_list external-symbols.lst
-filelist external-objects.lst
-o iomp.o 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
----- 1/1 — unstripped/.dir -----
mkdir -p unstripped/
touch unstripped/.dir
----- 1/1 — unstripped/libiomp5.dylib.lst -----
echo iomp.o > unstripped/libiomp5.dylib.lst

I’ll see if I can puzzle that out on darwin over the weekend.
Jack
ps IMHO, we should try to have the cmake build follow the same exact steps as the ‘make compiler=clang’ build to maintain continuity.

Jack_Howarth · May 31, 2014, 1:51pm

C. Bergström,
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 build.pl 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

attribute ((visibility (“default”)))

to the c++ source files for those symbols we want to export from libiomp?
Jack

Jack_Howarth · May 31, 2014, 6:41pm

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…

% cd openmp/runtime/src
% mkdir build
% cd build
% cmake …
% make VERBOSE=1

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…

Linking CXX shared library libiomp5.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/iomp5.dir/link.txt --verbose=1
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
/usr/bin/ld: libiomp5.so: version node not found for symbol omp_test_lock@@VERSION
/usr/bin/ld: failed to set dynamic section sizes: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libiomp5.so] Error 1
make[2]: Leaving directory /home/howarth/llvm-clang-omp/openmp/runtime/src/build' make[1]: *** [CMakeFiles/iomp5.dir/all] Error 2 make[1]: Leaving directory /home/howarth/llvm-clang-omp/openmp/runtime/src/build’
make: *** [all] Error 2

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…

----- 1/1 — unstripped/.dir -----
mkdir -p unstripped/
touch unstripped/.dir
----- 1/1 — unstripped/libiomp5.so.lst -----
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
----- 1/1 — unstripped/libiomp5.so -----
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
----- 1/1 — unstripped/libiomp5.dbg -----
objcopy --only-keep-debug unstripped/libiomp5.so unstripped/libiomp5.dbg
----- 1/1 — libiomp5.dbg -----
cp -f unstripped/libiomp5.dbg libiomp5.dbg
----- 1/1 — stripped/.dir -----
mkdir -p stripped/
touch stripped/.dir
----- 1/1 — stripped/libiomp5.so -----
objcopy --strip-debug unstripped/libiomp5.so stripped/libiomp5.so.tmp
objcopy --add-gnu-debuglink=libiomp5.dbg stripped/libiomp5.so.tmp stripped/libiomp5.so
----- 1/1 — libiomp5.so -----
cp -f stripped/libiomp5.so libiomp5.so
----- 1/1 — test-touch-rt/.dir -----
mkdir -p test-touch-rt/
touch test-touch-rt/.dir
----- 1/1 — test-touch-rt/.test -----
rm -f test-touch-rt/*
cc -pthread -o test-touch-rt/test-touch -m64 …/…/src/test-touch.c libiomp5.so
rm -f test-touch-rt/test-touch
cc -pthread -o test-touch-rt/test-touch -m64 …/…/src/test-touch.c libiomp5.so -Wl,–verbose > test-touch-rt/build.log 2>&1
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

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…

----- 1/1 — z_Linux_asm.o -----
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

in the build.pl based build vs the following for the cmake build…

[ 0%] Generating z_Linux_asm.o
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

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.
Jack
ps The attached CMakefile.txt has the same behavior as the Pathscale ones (in emulating the build.pl 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.

pps The actual failing linkage line (as emitted from clang++ with -v) is…

“/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
/usr/bin/ld: libiomp5.so: version node not found for symbol omp_test_lock_@@VERSION
/usr/bin/ld: failed to set dynamic section sizes: Bad value

CMakeLists.txt (5.04 KB)