Add -DLOMP_SHARED_LIB=[on|off] to create static library of LOMP

[mjklemm]

@JimCownie This was rather easy. Please have look.

LOMP is now built as a static library if -DLOMP_SHARED_LIB=off is passed to CMake. One thing that I cannot seem to get rid of easily is that LOMP still links against shared libraries:

$ ldd ../build-${ARCH}/examples/hello_world
        linux-vdso.so.1 (0x00007fff952e3000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbaeb99b000)
        libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007fbaeb98e000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbaeb7ac000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbaeb65d000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbaeb642000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbaeb450000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fbaeb9e7000)

[jj16791]

A few issues whilst trying to build.

1. Had to add -DLOMP_ARM64_ARCHITECTURE=armv8.1-a to my build command as armv8.1a in root CMakeLists.txt file wasn't recognised
2. Had to encase the active case starting microBM/loadsStores.cc:586 in {...}, the root of the error being the way in which the variable elapsed is initialised within the said case (I believe it's an issue of scope)
3. Unable to fully build due to the error:

   FAILED: microBM/locks
   : && /opt/cray/pe/craype/2.6.2/bin/CC  -O3 -DNDEBUG  -fopenmp microBM/CMakeFiles/locks.dir/locks.cc.o microBM/CMakeFiles/locks.dir/__/src/stats-timing.cc.o microBM/CMakeFiles/locks.dir/__/src/util.cc.o  -o microBM/locks   && :
   /usr/bin/ld: microBM/CMakeFiles/locks.dir/locks.cc.o: in function `openMPLock::create(unsigned long)':
   locks.cc:(.text._ZN10openMPLock6createEm[_ZN10openMPLock6createEm]+0x50): undefined reference to `omp_init_lock_with_hint'
   collect2: error: ld returned 1 exit status

   Which I'm not sure how to solve

[mjklemm]

Thanks for testing!

I guess you're using GCC, right?

Re 1: I think we still have issues with properly setting the ARM arch string for the compiler used. @JimCownie Maybe you can have another look at this to see if we are supplying the right thing for GCC and clang.

Re 2: I will have a look at this. It's a bit strange, as I haven't seen any issue with my x86 clang that I'm using mostly.

Re 3: If you are not interested in using the microBM suite that we have in LOMP, then you can turn it off and compile LOMP without it. The flag for that is -DLOMP_BUILD_MICROBM=off.

[jj16791]

Thanks for testing!

I guess you're using GCC, right?

I'm using gcc version 9.3.0 20200312 (Cray Inc.) (GCC).

Re 1: I think we still have issues with properly setting the ARM arch string for the compiler used. @JimCownie Maybe you can have another look at this to see if we are supplying the right thing for GCC and clang.

Re 2: I will have a look at this. It's a bit strange, as I haven't seen any issue with my x86 clang that I'm using mostly.

Re 3: If you are not interested in using the microBM suite that we have in LOMP, then you can turn it off and compile LOMP without it. The flag for that is -DLOMP_BUILD_MICROBM=off.

Whilst Re 3 fixed that issue, another issue revolving around undefined references in the test files has occurred. I've attached a file instead of a copied printout due to the length of the issue.

LOMPBuildErrors.txt

[mjklemm]

Whilst Re 3 fixed that issue, another issue revolving around undefined references in the test files has occurred. I've attached a file instead of a copied printout due to the length of the issue.

Do you have a way to switch to clang instead of GCC? Problem we have with GCC at the moment is that we do not fully support it's entrypoints. We do support the ones that the error log is listing for clang. though.

[JimCownie]

On 26 Oct 2021, at 16:24, Michael Klemm @.***> wrote:

Thanks for testing!

I guess you're using GCC, right?

Re 1: I think we still have issues with properly setting the ARM arch string for the compiler used. @JimCownie https://github.com/JimCownie Maybe you can have another look at this to see if we are supplying the right thing for GCC and clang.

The architecture selection works OK for me on xcli01 when using GCC 9.3.0 (though the missing entrypoints are still a problem :-)) @.:~/lomp/build_aarch64_GCC> cat ../JimConfigGCC.sh cmake -DCMAKE_C_COMPILER=which gcc \ -DCMAKE_CXX_COMPILER=which g++ \ .. @.:~/lomp/build_aarch64_GCC> gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc/9.3.0/bin/../snos/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc/9.3.0/snos/libexec/gcc/aarch64-unknown-linux-gnu/9.3.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: ../cray-gcc-9.3.0-202003310324.b29d417121fbe/configure --prefix=/opt/gcc/9.3.0/snos --disable-nls --li\ bdir=/opt/gcc/9.3.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/9.3.0/snos/include/g++ --\ with-slibdir=/opt/gcc/9.3.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --build=aarch64-unknown-l\ inux-gnu --with-ppl --with-cloog --disable-multilib Thread model: posix gcc version 9.3.0 20200312 (Cray Inc.) (GCC) @.:~/lomp/build_aarch64_GCC> sh ../JimConfigGCC.sh -- The C compiler identification is GNU 9.3.0 -- The CXX compiler identification is GNU 9.3.0 -- Check for working C compiler: /opt/gcc/9.3.0/bin/gcc -- Check for working C compiler: /opt/gcc/9.3.0/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /opt/gcc/9.3.0/bin/g++ -- Check for working CXX compiler: /opt/gcc/9.3.0/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Build type set to: Release -- Found Git: /usr/bin/git (found version "2.26.2") -- Target system: Linux -- Architecture: aarch64 -- LOMP_ARM64_ARCHITECTURE=armv8.1-a => -march=armv8.1-a -- Found clang-format. Enabling "format" target. -- LOMP build with Git commit ID: 8bd1877 -- Use LOMP for micro-benchmarks (LOMP_MICROBM_WITH_LOMP): OFF -- Warn about missing API entry points (LOMP_WARN_API_STUBS): ON -- Warn about missing implementations for arch features (LOMP_WARN_ARCH_FEATURES): ON -- Build example programs: ON -- Build micro-benchmarks: ON -- Shared-library extension: .so -- Found libatomic: /usr/lib64/libatomic.so.1 -- Found libnuma: /usr/lib64/libnuma.so -- Found OpenMP_C: -fopenmp (found version "4.5") -- Found OpenMP_CXX: -fopenmp (found version "4.5") -- Found OpenMP: TRUE (found version "4.5") -- Found OpenMP_C: -fopenmp -- Found OpenMP_CXX: -fopenmp -- Found OpenMP: TRUE -- Found Python3: /usr/bin/python3.6 (found version "3.6.12") found components: Interpreter -- Configuring done -- Generating done -- Build files have been written to: /home/br-jcownie/lomp/build_aarch64_GCC @.:~/lomp/build_aarch64_GCC> make Scanning dependencies of target omp [ 1%] Building CXX object src/CMakeFiles/omp.dir/atomics.cc.o [ 2%] Building CXX object src/CMakeFiles/omp.dir/barrier_impl.cc.o [ 2%] Building CXX object src/CMakeFiles/omp.dir/entrypoints.cc.o [ 3%] Building CXX object src/CMakeFiles/omp.dir/environment.cc.o [ 4%] Building CXX object src/CMakeFiles/omp.dir/globals.cc.o [ 4%] Building CXX object src/CMakeFiles/omp.dir/locks.cc.o [ 5%] Building CXX object src/CMakeFiles/omp.dir/loops.cc.o [ 6%] Building CXX object src/CMakeFiles/omp.dir/numa_support.cc.o

BUT I seem to be on a different branch @.***:~/lomp/build_aarch64_GCC> git status On branch GCCsupport Your branch is up to date with 'origin/GCCsupport'.

So, I think we likely need to merge this back into main.

Re 2: I will have a look at this. It's a bit strange, as I haven't seen any issue with my x86 clang that I'm using mostly.

Re 3: If you are not interested in using the microBM suite that we have in LOMP, then you can turn it off and compile LOMP without it. The flag for that is -DLOMP_BUILD_MICROBM=off.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/parallel-runtimes/lomp/pull/42#issuecomment-952051441, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALY7TVAVWW2IZHN3CU2FQ2TUI3I4JANCNFSM5GXVZQTQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Jim James Cownie @.***> Mob: +44 780 637 7146

[mjklemm]

I'd propose to merge this PR into main and then update your GCC branch for further testing. Once done let's move the GCCSupport branch over to the main branch.

[JimCownie]

Go ahead, I don't have any changes in the GCC branch that aren't checked in there. (And have grandchildren staying until the weekend, so won't be making changes).

-- Jim +44 780 637 7146

On Wed, 27 Oct 2021, 14:07 Michael Klemm, @.***> wrote:

I'd propose to merge this PR into main and then update your GCC branch for further testing. Once done let's move the GCCSupport branch over to the main branch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/parallel-runtimes/lomp/pull/42#issuecomment-952909100, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALY7TVG7OJK3DKQXYZCISCTUJABQZANCNFSM5GXVZQTQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.