[Openmp-dev] [PATCH] [Revised] Initial cmake support

Jack Howarth howarth.mailing.lists at gmail.com
Sun Jun 1 04:32:36 PDT 2014


On further reflection, I guess ${SOVERSION} can be avoided entirely by just
bumping the compatibility version on each major llvm/clang/openmp release.
Was the soversioning meant to be achieved through through the shared
library name? That is, when we have an ABI change in openmp which normally
requires a soverson bump, the shared library name would be changed instead
(e.g. libiomp5 to libiomp6)? In any case, we still have to consider the
installation location of libomp5.${OMP_SHLIBEXT} and how relates to having
multiple llvm/clang/openmp releases being installed simultaneously on the
same machine.


On Sat, May 31, 2014 at 10:51 PM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

> Below is what I had in mind for the installation commands of
> CMakelists.txt once we have the cmake build
> of openmp hooked up to the llvm bootstrap…
>
> install(
>   FILES omp.h
>   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
>   DESTINATION lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}/include
> )
> install(
>   FILES libiomp5.${OMP_SHLIBEXT}
>   PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE
>  WORLD_READ WORLD_EXECUTE
>   DESTINATION lib${LLVM_LIBDIR_SUFFIX}
> )
>
> This mimics what we have been doing in fink. Placing the omp.h header in
>  lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}/include automatically
> allows the compiler to find it. In fink, we have been installing
>  libiomp5.${OMP_SHLIBEXT} in lib${LLVM_LIBDIR_SUFFIX} and using a patch…
>
> --- cfe-3.4.1.src/lib/Driver/Tools.cpp.orig     2014-05-20
> 16:54:39.000000000 -0400
> +++ cfe-3.4.1.src/lib/Driver/Tools.cpp  2014-05-20 17:01:28.000000000 -0400
> @@ -5123,9 +5123,12 @@
>
>    Args.AddAllArgs(CmdArgs, options::OPT_L);
>
> -  if (Args.hasArg(options::OPT_fopenmp))
> +  if (Args.hasArg(options::OPT_fopenmp)) {
> +    // Help clang find libiomp5.dylib
> +    CmdArgs.push_back("-L at FINK_PREFIX@/opt/llvm-3.4/lib");
>      // This is more complicated in gcc...
>      CmdArgs.push_back("-liomp5");
> +  }
>
>    AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs);
>
> @@ -6690,7 +6693,9 @@
>
>        bool OpenMP = Args.hasArg(options::OPT_fopenmp);
>        if (OpenMP) {
> -        CmdArgs.push_back("-liomp5");
> +       // Help clang find libiomp5.dylib
> +       CmdArgs.push_back("-L at FINK_PREFIX@/opt/llvm-3.4/lib");
> +       CmdArgs.push_back("-liomp5");
>        }
>
>        AddLibgcc(ToolChain.getTriple(), D, CmdArgs, Args);
>
> to help clang find it there. So we would change @FINK_PREFIX@ to the
> complete path to the installed lib${LLVM_LIBDIR_SUFFIX}. The alternative
> would be to change the patch above to replace -liomp5 with a the full
> path to the installed  lib${LLVM_LIBDIR_SUFFIX}/libomp5.${OMP_SHLIBEXT}
> instead.
>
>  This brings up several questions…
>
> 1) Where do you intend to place libomp5.${OMP_SHLIBEXT}?
>
> 2) If it is installed outside of  lib${LLVM_LIBDIR_SUFFIX}, how do
>  you plan on handling having multiple versions of llvm/clang installed
>  on the same machine which will all claim to ownership of
> libomp5.${OMP_SHLIBEXT}?
>
>  My proposal for solving the issue of co-existing libomp5.${OMP_SHLIBEXT}
> would be…
>
>  Create  libomp5.${VERSION}.${SOVERSION}.${OMP_SHLIBEXT}, where SOVERSION
>  is set to the release number of the llvm/clang/openmp release and create
> a symlink
>  for  libomp5.${OMP_SHLIBEXT} pointing at
> libomp5.${VERSION}.${SOVERSION}.${OMP_SHLIBEXT}.
>  Install these two files in  lib${LLVM_LIBDIR_SUFFIX} and use additional
> symlinks to them
>  in an exposed directory like /usr/lib. These two symlinks in the exposed
> directory would be
>  swapped out when a particular releases of llvm/clang/openmp was
> designated as the system
>  one (i.e. they would end up in a conflicting  clang34-dev or clang35-dev
> packaging).
>
>  I think this would allow binaries to be compiled against a specific
> release of openmp and
>  insure that the resulting executables would find the original copy of
> libiomp5 for that
>  release of llvm/clang/openmp as installed in  lib${LLVM_LIBDIR_SUFFIX} as
>  libomp5.${VERSION}.${SOVERSION}.${OMP_SHLIBEXT}..
>
>  Sorry if that wasn't as clear as I intended but hopefully you will all
> get the idea.
>
>
>
> On Sat, May 31, 2014 at 9:41 PM, Jack Howarth <
> howarth.mailing.lists at gmail.com> wrote:
>
>>    Attached is the revised initial implementation of cmake support for
>> openmp in llvm.org with the following requested changes implemented.
>>
>> 1) Indentations normalized to 2 spaces.
>> 2) The test for APPLE moved above UNIX in setting OS_GEN and fatal error
>> condition added.
>> 3) Implemented used CMAKE_SHARED_LIBRARY_SUFFIX to set OMP_SHLIBEXT.
>> 4) Added comment explaining the rational for temporary forcing of…
>>
>> set(CMAKE_CXX_COMPILER "clang++")
>>
>> to insure that the build of 'make compiler=clang' is always used,
>> regardless of the actual system compiler, until the openmp build is wired
>> into the llvm bootstrap and can be certain to use its clang compilers. Also
>> note that the warnings added to the COMMON_FLAGS may be compiler-specific.
>> Tested as before on x86_64-apple-darwin12 against the clang compilers from
>> Xcode 5.1.1 and on x86_64 Fedora 15 using current clang-omp 3.4.
>>                    Jack
>> ps We also probably want to add a fatal error message for unsupported
>> arches but first I intend to adjust this file to support powerpc as soon as
>> my clang-omp bootstrap completes on ppc darwin9.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20140601/36e0eb82/attachment.html>


More information about the Openmp-dev mailing list