CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Jack Howarth
    I believe we have a gap in clang's library search path with the
enabling of the openmp support via the proposed patch at...

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html

Currently, in tree cmake builds of the openmp library using
-DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
subdirectory will place the libiomp5.dylib shared library in a
directory outside of the library search path used by clang...

% clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
clang version 3.7.0 (trunk)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
 "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name omp_getEnvInfo.c
-mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 242 -v -dwarf-column-info
-fno-unique-section-names -resource-dir
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
/Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
-fopenmp -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-x c omp_getEnvInfo.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
x86_64-apple-darwin14.4.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
-macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-lSystem
ld: library not found for -liomp5
clang-3.7: error: linker command failed with exit code 1 (use -v to
see invocation)

requiring an explicit path to passed to the compiler...

% clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo omp_getEnvInfo.c
% otool -L ./omp_getEnvInfo
./omp_getEnvInfo:
/sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)

Currently, all the other shared libraries linked by the clang
compilers (aside from libc++) are expected to be located in the
clang/3.7.0/lib/darwin subdirectory (such as
libclang_rt.asan_iossim_dynamic.dylib and
libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
cmake build to bury the llvm installation has no impact on the usage
of those two libraries with the -fsanitize flags but the current
search library search path doesn't do the same for the libiomp5
relocation in the same case.
            Jack
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chandler Carruth
I think that openmp should work much more like libc++ than like the sanitizers. It has a reasonably stable API and even supports the libgomp APIs and so it should be in the normal library tree just like libc++.

However, the CMake build of the openmp needs a lot of work. =/ It doesn't match the patterns and structures of any of our other runtime libraries.

I think openmp needs to much more closely model its CMake build on libc++'s before we do anything more. Currently I can't even reasonably include it in my builds because it clobbers un-prefixed variable names and doesn't re-use any of the LLVM CMake logic.

Also, I'll point out that the CMake build completely and universally uses the term 'iomp'. This trend really needs to reverse....

On Wed, May 13, 2015 at 8:32 AM Jack Howarth <[hidden email]> wrote:
    I believe we have a gap in clang's library search path with the
enabling of the openmp support via the proposed patch at...

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html

Currently, in tree cmake builds of the openmp library using
-DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
subdirectory will place the libiomp5.dylib shared library in a
directory outside of the library search path used by clang...

% clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
clang version 3.7.0 (trunk)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
 "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name omp_getEnvInfo.c
-mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 242 -v -dwarf-column-info
-fno-unique-section-names -resource-dir
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
/Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
-fopenmp -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-x c omp_getEnvInfo.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
x86_64-apple-darwin14.4.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
-macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-lSystem
ld: library not found for -liomp5
clang-3.7: error: linker command failed with exit code 1 (use -v to
see invocation)

requiring an explicit path to passed to the compiler...

% clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo omp_getEnvInfo.c
% otool -L ./omp_getEnvInfo
./omp_getEnvInfo:
/sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)

Currently, all the other shared libraries linked by the clang
compilers (aside from libc++) are expected to be located in the
clang/3.7.0/lib/darwin subdirectory (such as
libclang_rt.asan_iossim_dynamic.dylib and
libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
cmake build to bury the llvm installation has no impact on the usage
of those two libraries with the -fsanitize flags but the current
search library search path doesn't do the same for the libiomp5
relocation in the same case.
            Jack
_______________________________________________
Openmp-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Peyton, Jonathan L

We understand that iomp is undesirable.  What we don’t know is what name is desirable.

 

What name is desirable instead of iomp?  Do we want to link via…

-lllvmomp

-llvmomp

-lclomp

-lcomp

-lnotintelomp ( just kidding J )

… Some other name?  I get the feeling someone outside of Intel should make this choice.

 

-- Johnny

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chandler Carruth
Sent: Wednesday, May 13, 2015 10:59 AM
To: Jack Howarth; cfe-dev; [hidden email]
Subject: Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

 

I think that openmp should work much more like libc++ than like the sanitizers. It has a reasonably stable API and even supports the libgomp APIs and so it should be in the normal library tree just like libc++.

 

However, the CMake build of the openmp needs a lot of work. =/ It doesn't match the patterns and structures of any of our other runtime libraries.

 

I think openmp needs to much more closely model its CMake build on libc++'s before we do anything more. Currently I can't even reasonably include it in my builds because it clobbers un-prefixed variable names and doesn't re-use any of the LLVM CMake logic.

 

Also, I'll point out that the CMake build completely and universally uses the term 'iomp'. This trend really needs to reverse....

 

On Wed, May 13, 2015 at 8:32 AM Jack Howarth <[hidden email]> wrote:

    I believe we have a gap in clang's library search path with the
enabling of the openmp support via the proposed patch at...

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html

Currently, in tree cmake builds of the openmp library using
-DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
subdirectory will place the libiomp5.dylib shared library in a
directory outside of the library search path used by clang...

% clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
clang version 3.7.0 (trunk)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
 "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name omp_getEnvInfo.c
-mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 242 -v -dwarf-column-info
-fno-unique-section-names -resource-dir
/sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
/Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
-fopenmp -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-x c omp_getEnvInfo.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
x86_64-apple-darwin14.4.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
-macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
-lSystem
ld: library not found for -liomp5
clang-3.7: error: linker command failed with exit code 1 (use -v to
see invocation)

requiring an explicit path to passed to the compiler...

% clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo omp_getEnvInfo.c
% otool -L ./omp_getEnvInfo
./omp_getEnvInfo:
/sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)

Currently, all the other shared libraries linked by the clang
compilers (aside from libc++) are expected to be located in the
clang/3.7.0/lib/darwin subdirectory (such as
libclang_rt.asan_iossim_dynamic.dylib and
libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
cmake build to bury the llvm installation has no impact on the usage
of those two libraries with the -fsanitize flags but the current
search library search path doesn't do the same for the libiomp5
relocation in the same case.
            Jack
_______________________________________________
Openmp-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

David Chisnall-4
On 13 May 2015, at 17:29, Peyton, Jonathan L <[hidden email]> wrote:
>
> What name is desirable instead of iomp?  Do we want to link via…
> -lllvmomp
> -llvmomp
> -lclomp
> -lcomp
> -lnotintelomp ( just kidding J )
> … Some other name?  I get the feeling someone outside of Intel should make this choice.

[Joining in the bikeshed]
-llomp seems most consistent (first letter of LLVM + omp, consistent with first letter of GNU + omp, first letter of Intel + omp).

David


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chandler Carruth
My suggestion had been 'libllomp' which would be '-lllomp'. But I don't really care.

On Wed, May 13, 2015 at 10:32 AM David Chisnall <[hidden email]> wrote:
On 13 May 2015, at 17:29, Peyton, Jonathan L <[hidden email]> wrote:
>
> What name is desirable instead of iomp?  Do we want to link via…
> -lllvmomp
> -llvmomp
> -lclomp
> -lcomp
> -lnotintelomp ( just kidding J )
> … Some other name?  I get the feeling someone outside of Intel should make this choice.

[Joining in the bikeshed]
-llomp seems most consistent (first letter of LLVM + omp, consistent with first letter of GNU + omp, first letter of Intel + omp).

David


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Jack Howarth
In reply to this post by Chandler Carruth
On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <[hidden email]> wrote:
> I think that openmp should work much more like libc++ than like the
> sanitizers. It has a reasonably stable API and even supports the libgomp
> APIs and so it should be in the normal library tree just like libc++.
>

Chandler,
       Is linux able to find the installed libc++ shared library when
-DCMAKE_INSTALL_PREFIX=
is used in the cmake build? On x86_64 darwin, the built libc++ shared
library is installed
in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.
However, this isn't really
exercised on darwin as the system libc++ is always used by default.

> However, the CMake build of the openmp needs a lot of work. =/ It doesn't
> match the patterns and structures of any of our other runtime libraries.

Please do open bugzilla reports on those issues against the openmp cmake build.
             Jack

>
> I think openmp needs to much more closely model its CMake build on libc++'s
> before we do anything more. Currently I can't even reasonably include it in
> my builds because it clobbers un-prefixed variable names and doesn't re-use
> any of the LLVM CMake logic.
>
> Also, I'll point out that the CMake build completely and universally uses
> the term 'iomp'. This trend really needs to reverse....
>
> On Wed, May 13, 2015 at 8:32 AM Jack Howarth
> <[hidden email]> wrote:
>>
>>     I believe we have a gap in clang's library search path with the
>> enabling of the openmp support via the proposed patch at...
>>
>>
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html
>>
>> Currently, in tree cmake builds of the openmp library using
>> -DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
>> subdirectory will place the libiomp5.dylib shared library in a
>> directory outside of the library search path used by clang...
>>
>> % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
>> clang version 3.7.0 (trunk)
>> Target: x86_64-apple-darwin14.4.0
>> Thread model: posix
>>  "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
>> x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
>> -disable-llvm-verifier -main-file-name omp_getEnvInfo.c
>> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
>> -target-linker-version 242 -v -dwarf-column-info
>> -fno-unique-section-names -resource-dir
>> /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
>> /Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
>> -fopenmp -stack-protector 1 -mstackrealign -fblocks
>> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
>> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
>> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> -x c omp_getEnvInfo.c
>> clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
>> x86_64-apple-darwin14.4.0
>> ignoring nonexistent directory "/usr/local/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
>>  /usr/include
>>  /System/Library/Frameworks (framework directory)
>>  /Library/Frameworks (framework directory)
>> End of search list.
>>  "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
>> -macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
>> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> -lSystem
>> ld: library not found for -liomp5
>> clang-3.7: error: linker command failed with exit code 1 (use -v to
>> see invocation)
>>
>> requiring an explicit path to passed to the compiler...
>>
>> % clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo
>> omp_getEnvInfo.c
>> % otool -L ./omp_getEnvInfo
>> ./omp_getEnvInfo:
>> /sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
>> current version 5.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1213.0.0)
>>
>> Currently, all the other shared libraries linked by the clang
>> compilers (aside from libc++) are expected to be located in the
>> clang/3.7.0/lib/darwin subdirectory (such as
>> libclang_rt.asan_iossim_dynamic.dylib and
>> libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
>> cmake build to bury the llvm installation has no impact on the usage
>> of those two libraries with the -fsanitize flags but the current
>> search library search path doesn't do the same for the libiomp5
>> relocation in the same case.
>>             Jack
>> _______________________________________________
>> Openmp-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chandler Carruth
I already replied to the code review suggesting to enable it in the projects/ tree. I don't understand why a bug report is necessary.

On Wed, May 13, 2015 at 10:55 AM Jack Howarth <[hidden email]> wrote:
On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <[hidden email]> wrote:
> I think that openmp should work much more like libc++ than like the
> sanitizers. It has a reasonably stable API and even supports the libgomp
> APIs and so it should be in the normal library tree just like libc++.
>

Chandler,
       Is linux able to find the installed libc++ shared library when
-DCMAKE_INSTALL_PREFIX=
is used in the cmake build? On x86_64 darwin, the built libc++ shared
library is installed
in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.
However, this isn't really
exercised on darwin as the system libc++ is always used by default.

> However, the CMake build of the openmp needs a lot of work. =/ It doesn't
> match the patterns and structures of any of our other runtime libraries.

Please do open bugzilla reports on those issues against the openmp cmake build.
             Jack

>
> I think openmp needs to much more closely model its CMake build on libc++'s
> before we do anything more. Currently I can't even reasonably include it in
> my builds because it clobbers un-prefixed variable names and doesn't re-use
> any of the LLVM CMake logic.
>
> Also, I'll point out that the CMake build completely and universally uses
> the term 'iomp'. This trend really needs to reverse....
>
> On Wed, May 13, 2015 at 8:32 AM Jack Howarth
> <[hidden email]> wrote:
>>
>>     I believe we have a gap in clang's library search path with the
>> enabling of the openmp support via the proposed patch at...
>>
>>
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html
>>
>> Currently, in tree cmake builds of the openmp library using
>> -DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
>> subdirectory will place the libiomp5.dylib shared library in a
>> directory outside of the library search path used by clang...
>>
>> % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
>> clang version 3.7.0 (trunk)
>> Target: x86_64-apple-darwin14.4.0
>> Thread model: posix
>>  "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
>> x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
>> -disable-llvm-verifier -main-file-name omp_getEnvInfo.c
>> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
>> -target-linker-version 242 -v -dwarf-column-info
>> -fno-unique-section-names -resource-dir
>> /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
>> /Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
>> -fopenmp -stack-protector 1 -mstackrealign -fblocks
>> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
>> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
>> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> -x c omp_getEnvInfo.c
>> clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
>> x86_64-apple-darwin14.4.0
>> ignoring nonexistent directory "/usr/local/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
>>  /usr/include
>>  /System/Library/Frameworks (framework directory)
>>  /Library/Frameworks (framework directory)
>> End of search list.
>>  "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
>> -macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
>> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> -lSystem
>> ld: library not found for -liomp5
>> clang-3.7: error: linker command failed with exit code 1 (use -v to
>> see invocation)
>>
>> requiring an explicit path to passed to the compiler...
>>
>> % clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo
>> omp_getEnvInfo.c
>> % otool -L ./omp_getEnvInfo
>> ./omp_getEnvInfo:
>> /sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
>> current version 5.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1213.0.0)
>>
>> Currently, all the other shared libraries linked by the clang
>> compilers (aside from libc++) are expected to be located in the
>> clang/3.7.0/lib/darwin subdirectory (such as
>> libclang_rt.asan_iossim_dynamic.dylib and
>> libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
>> cmake build to bury the llvm installation has no impact on the usage
>> of those two libraries with the -fsanitize flags but the current
>> search library search path doesn't do the same for the libiomp5
>> relocation in the same case.
>>             Jack
>> _______________________________________________
>> Openmp-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Jack Howarth
On Wed, May 13, 2015 at 12:56 PM, Chandler Carruth <[hidden email]> wrote:
> I already replied to the code review suggesting to enable it in the
> projects/ tree. I don't understand why a bug report is necessary.

   I was referencing your objections that build of openmp doesn't
match the patterns and structures of the other runtime libraries (in
case you had any particular changes in mind to address those issues).
Have those particular issues been discussed in the openmp-dev mailing
list yet?

>
> On Wed, May 13, 2015 at 10:55 AM Jack Howarth
> <[hidden email]> wrote:
>>
>> On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <[hidden email]>
>> wrote:
>> > I think that openmp should work much more like libc++ than like the
>> > sanitizers. It has a reasonably stable API and even supports the libgomp
>> > APIs and so it should be in the normal library tree just like libc++.
>> >
>>
>> Chandler,
>>        Is linux able to find the installed libc++ shared library when
>> -DCMAKE_INSTALL_PREFIX=
>> is used in the cmake build? On x86_64 darwin, the built libc++ shared
>> library is installed
>> in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.
>> However, this isn't really
>> exercised on darwin as the system libc++ is always used by default.
>>
>> > However, the CMake build of the openmp needs a lot of work. =/ It
>> > doesn't
>> > match the patterns and structures of any of our other runtime libraries.
>>
>> Please do open bugzilla reports on those issues against the openmp cmake
>> build.
>>              Jack
>>
>> >
>> > I think openmp needs to much more closely model its CMake build on
>> > libc++'s
>> > before we do anything more. Currently I can't even reasonably include it
>> > in
>> > my builds because it clobbers un-prefixed variable names and doesn't
>> > re-use
>> > any of the LLVM CMake logic.
>> >
>> > Also, I'll point out that the CMake build completely and universally
>> > uses
>> > the term 'iomp'. This trend really needs to reverse....
>> >
>> > On Wed, May 13, 2015 at 8:32 AM Jack Howarth
>> > <[hidden email]> wrote:
>> >>
>> >>     I believe we have a gap in clang's library search path with the
>> >> enabling of the openmp support via the proposed patch at...
>> >>
>> >>
>> >>
>> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html
>> >>
>> >> Currently, in tree cmake builds of the openmp library using
>> >> -DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
>> >> subdirectory will place the libiomp5.dylib shared library in a
>> >> directory outside of the library search path used by clang...
>> >>
>> >> % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
>> >> clang version 3.7.0 (trunk)
>> >> Target: x86_64-apple-darwin14.4.0
>> >> Thread model: posix
>> >>  "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
>> >> x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
>> >> -disable-llvm-verifier -main-file-name omp_getEnvInfo.c
>> >> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> >> -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
>> >> -target-linker-version 242 -v -dwarf-column-info
>> >> -fno-unique-section-names -resource-dir
>> >> /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
>> >> /Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
>> >> -fopenmp -stack-protector 1 -mstackrealign -fblocks
>> >> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
>> >> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
>> >>
>> >> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> >> -x c omp_getEnvInfo.c
>> >> clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
>> >> x86_64-apple-darwin14.4.0
>> >> ignoring nonexistent directory "/usr/local/include"
>> >> #include "..." search starts here:
>> >> #include <...> search starts here:
>> >>  /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
>> >>  /usr/include
>> >>  /System/Library/Frameworks (framework directory)
>> >>  /Library/Frameworks (framework directory)
>> >> End of search list.
>> >>  "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
>> >> -macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
>> >>
>> >> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> >> -lSystem
>> >> ld: library not found for -liomp5
>> >> clang-3.7: error: linker command failed with exit code 1 (use -v to
>> >> see invocation)
>> >>
>> >> requiring an explicit path to passed to the compiler...
>> >>
>> >> % clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo
>> >> omp_getEnvInfo.c
>> >> % otool -L ./omp_getEnvInfo
>> >> ./omp_getEnvInfo:
>> >> /sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
>> >> current version 5.0.0)
>> >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> >> version 1213.0.0)
>> >>
>> >> Currently, all the other shared libraries linked by the clang
>> >> compilers (aside from libc++) are expected to be located in the
>> >> clang/3.7.0/lib/darwin subdirectory (such as
>> >> libclang_rt.asan_iossim_dynamic.dylib and
>> >> libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
>> >> cmake build to bury the llvm installation has no impact on the usage
>> >> of those two libraries with the -fsanitize flags but the current
>> >> search library search path doesn't do the same for the libiomp5
>> >> relocation in the same case.
>> >>             Jack
>> >> _______________________________________________
>> >> Openmp-dev mailing list
>> >> [hidden email]
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chandler Carruth
On Wed, May 13, 2015 at 11:16 AM Jack Howarth <[hidden email]> wrote:
On Wed, May 13, 2015 at 12:56 PM, Chandler Carruth <[hidden email]> wrote:
> I already replied to the code review suggesting to enable it in the
> projects/ tree. I don't understand why a bug report is necessary.

   I was referencing your objections that build of openmp doesn't
match the patterns and structures of the other runtime libraries (in
case you had any particular changes in mind to address those issues).

Yes.
 
Have those particular issues been discussed in the openmp-dev mailing
list yet?

openmp-commits and llvm-commits.

Not sure how much more is needed. 

>
> On Wed, May 13, 2015 at 10:55 AM Jack Howarth
> <[hidden email]> wrote:
>>
>> On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth <[hidden email]>
>> wrote:
>> > I think that openmp should work much more like libc++ than like the
>> > sanitizers. It has a reasonably stable API and even supports the libgomp
>> > APIs and so it should be in the normal library tree just like libc++.
>> >
>>
>> Chandler,
>>        Is linux able to find the installed libc++ shared library when
>> -DCMAKE_INSTALL_PREFIX=
>> is used in the cmake build? On x86_64 darwin, the built libc++ shared
>> library is installed
>> in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.
>> However, this isn't really
>> exercised on darwin as the system libc++ is always used by default.
>>
>> > However, the CMake build of the openmp needs a lot of work. =/ It
>> > doesn't
>> > match the patterns and structures of any of our other runtime libraries.
>>
>> Please do open bugzilla reports on those issues against the openmp cmake
>> build.
>>              Jack
>>
>> >
>> > I think openmp needs to much more closely model its CMake build on
>> > libc++'s
>> > before we do anything more. Currently I can't even reasonably include it
>> > in
>> > my builds because it clobbers un-prefixed variable names and doesn't
>> > re-use
>> > any of the LLVM CMake logic.
>> >
>> > Also, I'll point out that the CMake build completely and universally
>> > uses
>> > the term 'iomp'. This trend really needs to reverse....
>> >
>> > On Wed, May 13, 2015 at 8:32 AM Jack Howarth
>> > <[hidden email]> wrote:
>> >>
>> >>     I believe we have a gap in clang's library search path with the
>> >> enabling of the openmp support via the proposed patch at...
>> >>
>> >>
>> >>
>> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html
>> >>
>> >> Currently, in tree cmake builds of the openmp library using
>> >> -DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
>> >> subdirectory will place the libiomp5.dylib shared library in a
>> >> directory outside of the library search path used by clang...
>> >>
>> >> % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
>> >> clang version 3.7.0 (trunk)
>> >> Target: x86_64-apple-darwin14.4.0
>> >> Thread model: posix
>> >>  "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
>> >> x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
>> >> -disable-llvm-verifier -main-file-name omp_getEnvInfo.c
>> >> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> >> -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
>> >> -target-linker-version 242 -v -dwarf-column-info
>> >> -fno-unique-section-names -resource-dir
>> >> /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
>> >> /Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
>> >> -fopenmp -stack-protector 1 -mstackrealign -fblocks
>> >> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
>> >> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
>> >>
>> >> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> >> -x c omp_getEnvInfo.c
>> >> clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
>> >> x86_64-apple-darwin14.4.0
>> >> ignoring nonexistent directory "/usr/local/include"
>> >> #include "..." search starts here:
>> >> #include <...> search starts here:
>> >>  /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
>> >>  /usr/include
>> >>  /System/Library/Frameworks (framework directory)
>> >>  /Library/Frameworks (framework directory)
>> >> End of search list.
>> >>  "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
>> >> -macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
>> >>
>> >> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> >> -lSystem
>> >> ld: library not found for -liomp5
>> >> clang-3.7: error: linker command failed with exit code 1 (use -v to
>> >> see invocation)
>> >>
>> >> requiring an explicit path to passed to the compiler...
>> >>
>> >> % clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo
>> >> omp_getEnvInfo.c
>> >> % otool -L ./omp_getEnvInfo
>> >> ./omp_getEnvInfo:
>> >> /sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
>> >> current version 5.0.0)
>> >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> >> version 1213.0.0)
>> >>
>> >> Currently, all the other shared libraries linked by the clang
>> >> compilers (aside from libc++) are expected to be located in the
>> >> clang/3.7.0/lib/darwin subdirectory (such as
>> >> libclang_rt.asan_iossim_dynamic.dylib and
>> >> libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in the
>> >> cmake build to bury the llvm installation has no impact on the usage
>> >> of those two libraries with the -fsanitize flags but the current
>> >> search library search path doesn't do the same for the libiomp5
>> >> relocation in the same case.
>> >>             Jack
>> >> _______________________________________________
>> >> Openmp-dev mailing list
>> >> [hidden email]
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Jack Howarth
On Wed, May 13, 2015 at 1:24 PM, Chandler Carruth <[hidden email]> wrote:

> On Wed, May 13, 2015 at 11:16 AM Jack Howarth
> <[hidden email]> wrote:
>>
>> On Wed, May 13, 2015 at 12:56 PM, Chandler Carruth <[hidden email]>
>> wrote:
>> > I already replied to the code review suggesting to enable it in the
>> > projects/ tree. I don't understand why a bug report is necessary.
>>
>>    I was referencing your objections that build of openmp doesn't
>> match the patterns and structures of the other runtime libraries (in
>> case you had any particular changes in mind to address those issues).
>
>
> Yes.
>
>>
>> Have those particular issues been discussed in the openmp-dev mailing
>> list yet?
>
>
> openmp-commits and llvm-commits.

When I pinged the same proposed change from
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-May/000255.html
in the openmp-dev mailing list...

http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-May/000522.html

Jonathan seemed to think that the change was non-essential...

http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-May/000525.html

>
> Not sure how much more is needed.
>>
>>
>> >
>> > On Wed, May 13, 2015 at 10:55 AM Jack Howarth
>> > <[hidden email]> wrote:
>> >>
>> >> On Wed, May 13, 2015 at 11:58 AM, Chandler Carruth
>> >> <[hidden email]>
>> >> wrote:
>> >> > I think that openmp should work much more like libc++ than like the
>> >> > sanitizers. It has a reasonably stable API and even supports the
>> >> > libgomp
>> >> > APIs and so it should be in the normal library tree just like libc++.
>> >> >
>> >>
>> >> Chandler,
>> >>        Is linux able to find the installed libc++ shared library when
>> >> -DCMAKE_INSTALL_PREFIX=
>> >> is used in the cmake build? On x86_64 darwin, the built libc++ shared
>> >> library is installed
>> >> in the lib subdirectory of the path from CMAKE_INSTALL_PREFIX.
>> >> However, this isn't really
>> >> exercised on darwin as the system libc++ is always used by default.
>> >>
>> >> > However, the CMake build of the openmp needs a lot of work. =/ It
>> >> > doesn't
>> >> > match the patterns and structures of any of our other runtime
>> >> > libraries.
>> >>
>> >> Please do open bugzilla reports on those issues against the openmp
>> >> cmake
>> >> build.
>> >>              Jack
>> >>
>> >> >
>> >> > I think openmp needs to much more closely model its CMake build on
>> >> > libc++'s
>> >> > before we do anything more. Currently I can't even reasonably include
>> >> > it
>> >> > in
>> >> > my builds because it clobbers un-prefixed variable names and doesn't
>> >> > re-use
>> >> > any of the LLVM CMake logic.
>> >> >
>> >> > Also, I'll point out that the CMake build completely and universally
>> >> > uses
>> >> > the term 'iomp'. This trend really needs to reverse....
>> >> >
>> >> > On Wed, May 13, 2015 at 8:32 AM Jack Howarth
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >>     I believe we have a gap in clang's library search path with the
>> >> >> enabling of the openmp support via the proposed patch at...
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html
>> >> >>
>> >> >> Currently, in tree cmake builds of the openmp library using
>> >> >> -DCMAKE_INSTALL_PREFIX to install the llvm build in a buried
>> >> >> subdirectory will place the libiomp5.dylib shared library in a
>> >> >> directory outside of the library search path used by clang...
>> >> >>
>> >> >> % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v
>> >> >> clang version 3.7.0 (trunk)
>> >> >> Target: x86_64-apple-darwin14.4.0
>> >> >> Thread model: posix
>> >> >>  "/sw/opt/llvm-3.7.0/bin/clang-3.7" -cc1 -triple
>> >> >> x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
>> >> >> -disable-llvm-verifier -main-file-name omp_getEnvInfo.c
>> >> >> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> >> >> -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
>> >> >> -target-linker-version 242 -v -dwarf-column-info
>> >> >> -fno-unique-section-names -resource-dir
>> >> >> /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0 -fdebug-compilation-dir
>> >> >> /Users/howarth/openmp_examples -ferror-limit 19 -fmessage-length 140
>> >> >> -fopenmp -stack-protector 1 -mstackrealign -fblocks
>> >> >> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
>> >> >> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
>> >> >>
>> >> >>
>> >> >> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> >> >> -x c omp_getEnvInfo.c
>> >> >> clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target
>> >> >> x86_64-apple-darwin14.4.0
>> >> >> ignoring nonexistent directory "/usr/local/include"
>> >> >> #include "..." search starts here:
>> >> >> #include <...> search starts here:
>> >> >>  /sw/opt/llvm-3.7.0/bin/../lib/clang/3.7.0/include
>> >> >>  /usr/include
>> >> >>  /System/Library/Frameworks (framework directory)
>> >> >>  /Library/Frameworks (framework directory)
>> >> >> End of search list.
>> >> >>  "/sw/opt/llvm-3.7.0/bin/ld" -demangle -dynamic -arch x86_64
>> >> >> -macosx_version_min 10.10.0 -o omp_getEnvInfo -liomp5
>> >> >>
>> >> >>
>> >> >> /var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/omp_getEnvInfo-e20595.o
>> >> >> -lSystem
>> >> >> ld: library not found for -liomp5
>> >> >> clang-3.7: error: linker command failed with exit code 1 (use -v to
>> >> >> see invocation)
>> >> >>
>> >> >> requiring an explicit path to passed to the compiler...
>> >> >>
>> >> >> % clang-3.7 -fopenmp -L/sw/opt/llvm-3.7.0/lib -o omp_getEnvInfo
>> >> >> omp_getEnvInfo.c
>> >> >> % otool -L ./omp_getEnvInfo
>> >> >> ./omp_getEnvInfo:
>> >> >> /sw/opt/llvm-3.7.0/lib/libiomp5.dylib (compatibility version 5.0.0,
>> >> >> current version 5.0.0)
>> >> >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> >> >> version 1213.0.0)
>> >> >>
>> >> >> Currently, all the other shared libraries linked by the clang
>> >> >> compilers (aside from libc++) are expected to be located in the
>> >> >> clang/3.7.0/lib/darwin subdirectory (such as
>> >> >> libclang_rt.asan_iossim_dynamic.dylib and
>> >> >> libclang_rt.asan_osx_dynamic.dylib). Using CMAKE_INSTALL_PREFIX in
>> >> >> the
>> >> >> cmake build to bury the llvm installation has no impact on the usage
>> >> >> of those two libraries with the -fsanitize flags but the current
>> >> >> search library search path doesn't do the same for the libiomp5
>> >> >> relocation in the same case.
>> >> >>             Jack
>> >> >> _______________________________________________
>> >> >> Openmp-dev mailing list
>> >> >> [hidden email]
>> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Carlo Bertolli
In reply to this post by Chandler Carruth
Hi

I vote for -lllomp, i.e. lib name libllomp.a.

There is already a (perhaps unofficially named) LOMP library around (which can be used as openmp runtime for clang) and this would make some discussion hard to understand. See references to it here:



Cheers

-- Carlo 


On 13 May 2015 at 12:34, Chandler Carruth <[hidden email]> wrote:
My suggestion had been 'libllomp' which would be '-lllomp'. But I don't really care.

On Wed, May 13, 2015 at 10:32 AM David Chisnall <[hidden email]> wrote:
On 13 May 2015, at 17:29, Peyton, Jonathan L <[hidden email]> wrote:
>
> What name is desirable instead of iomp?  Do we want to link via…
> -lllvmomp
> -llvmomp
> -lclomp
> -lcomp
> -lnotintelomp ( just kidding J )
> … Some other name?  I get the feeling someone outside of Intel should make this choice.

[Joining in the bikeshed]
-llomp seems most consistent (first letter of LLVM + omp, consistent with first letter of GNU + omp, first letter of Intel + omp).

David


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Klemm, Michael
In reply to this post by Chandler Carruth

How about naming the library “lvmomp”.  Then you can use –llvmomp to link (cf. libiberty J)

 

Cheers,

        -michael

 

Dr.-Ing. Michael Klemm

Senior Application Engineer

Software and Services Group

Developer Relations Division

Phone    +49 89 9914 2340

Cell         +49 174 2417583

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chandler Carruth
Sent: Wednesday, May 13, 2015 6:34 PM
To: David Chisnall; Peyton, Jonathan L
Cc: [hidden email]; cfe-dev
Subject: Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

 

My suggestion had been 'libllomp' which would be '-lllomp'. But I don't really care.

 

On Wed, May 13, 2015 at 10:32 AM David Chisnall <[hidden email]> wrote:

On 13 May 2015, at 17:29, Peyton, Jonathan L <[hidden email]> wrote:
>
> What name is desirable instead of iomp?  Do we want to link via…
> -lllvmomp
> -llvmomp
> -lclomp
> -lcomp
> -lnotintelomp ( just kidding J )
> … Some other name?  I get the feeling someone outside of Intel should make this choice.

[Joining in the bikeshed]
-llomp seems most consistent (first letter of LLVM + omp, consistent with first letter of GNU + omp, first letter of Intel + omp).

David

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chris Lattner
In reply to this post by Peyton, Jonathan L

On May 13, 2015, at 9:29 AM, Peyton, Jonathan L <[hidden email]> wrote:

We understand that iomp is undesirable.  What we don’t know is what name is desirable.
 
What name is desirable instead of iomp?  Do we want to link via…
-lllvmomp
-llvmomp
-lclomp
-lcomp
-lnotintelomp ( just kidding J )
… Some other name?  I get the feeling someone outside of Intel should make this choice.

Why not -lomp?

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

C Bergström
Adding a prefix may be desireable to avoid conflicts or confusion.


On Sat, May 16, 2015 at 5:35 AM, Chris Lattner <[hidden email]> wrote:

>
> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L
> <[hidden email]> wrote:
>
> We understand that iomp is undesirable.  What we don’t know is what name is
> desirable.
>
> What name is desirable instead of iomp?  Do we want to link via…
> -lllvmomp
> -llvmomp
> -lclomp
> -lcomp
> -lnotintelomp ( just kidding J )
> … Some other name?  I get the feeling someone outside of Intel should make
> this choice.
>
>
> Why not -lomp?
>
> -Chris
>
>
> _______________________________________________
> Openmp-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Carlo Bertolli-2
In reply to this post by Chris Lattner

Hi Chris

I sent an e-mail a while ago but I made a mistake when transforming it from daily digest into a single e-mail and you may not have seen it.

lomp is already used for the "lightweight OpenMP" (LOMP) implementation, which is for PPC64, BlueGene, and Z-series systems.
Here are some references to it:

http://cscads.rice.edu/workshops/summer-2012/slides/performance-tools/OpenMP-for-exascale-CScADS.pdf
https://www.alcf.anl.gov/files/BlueGeneQ_Optimization.pdf

One important note is that LOMP supports the KMP* interface and can be (and currently is) used as a OpenMP library for LLVM.
Unless you feel strongly for re-using the name, I would rather prefer LLOMP to avoid confusion.


Thanks

-- Carlo



Inactive hide details for Chris Lattner ---05/15/2015 06:37:07 PM---> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L <jonathanChris Lattner ---05/15/2015 06:37:07 PM---> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L <[hidden email]> wrote: >

From: Chris Lattner <[hidden email]>
To: "Peyton, Jonathan L" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, cfe-dev <[hidden email]>
Date: 05/15/2015 06:37 PM
Subject: Re: [Openmp-dev] [cfe-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path
Sent by: [hidden email]





    On May 13, 2015, at 9:29 AM, Peyton, Jonathan L <[hidden email]> wrote:

    We understand that iomp is undesirable.  What we don’t know is what name is desirable.
     
    What name is desirable instead of iomp?  Do we want to link via…
    -lllvmomp
    -llvmomp
    -lclomp
    -lcomp
    -lnotintelomp ( just kidding J )
    … Some other name?  I get the feeling someone outside of Intel should make this choice.

Why not -lomp?

-Chris
_______________________________________________
Openmp-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chris Lattner
In reply to this post by C Bergström

> On May 15, 2015, at 3:47 PM, C Bergström <[hidden email]> wrote:
>
> Adding a prefix may be desireable to avoid conflicts or confusion.

Sure, OTOH, we have precedent with this.  There were many c++ standard libraries before libc++.  I'm ok with LLVM's implementation being the defacto implementation, aren't you?

-Chris

>
>
> On Sat, May 16, 2015 at 5:35 AM, Chris Lattner <[hidden email]> wrote:
>>
>> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L
>> <[hidden email]> wrote:
>>
>> We understand that iomp is undesirable.  What we don’t know is what name is
>> desirable.
>>
>> What name is desirable instead of iomp?  Do we want to link via…
>> -lllvmomp
>> -llvmomp
>> -lclomp
>> -lcomp
>> -lnotintelomp ( just kidding J )
>> … Some other name?  I get the feeling someone outside of Intel should make
>> this choice.
>>
>>
>> Why not -lomp?
>>
>> -Chris
>>
>>
>> _______________________________________________
>> Openmp-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chris Lattner
In reply to this post by Carlo Bertolli-2

On May 15, 2015, at 4:55 PM, Carlo Bertolli <[hidden email]> wrote:

Hi Chris

I sent an e-mail a while ago but I made a mistake when transforming it from daily digest into a single e-mail and you may not have seen it.

lomp is already used for the "lightweight OpenMP" (LOMP) implementation, which is for PPC64, BlueGene, and Z-series systems.
Here are some references to it:

http://cscads.rice.edu/workshops/summer-2012/slides/performance-tools/OpenMP-for-exascale-CScADS.pdf
https://www.alcf.anl.gov/files/BlueGeneQ_Optimization.pdf

One important note is that LOMP supports the KMP* interface and can be (and currently is) used as a OpenMP library for LLVM.
Unless you feel strongly for re-using the name, I would rather prefer LLOMP to avoid confusion.


Sure, but “lomp” is presumably actually linked with the command line flag -llomp today.  The “-l” part is an aspect of the compiler interface to specify a library to link, not part of the name of the library.

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

C Bergström
In reply to this post by Chris Lattner
maybe we're talking about the same thing
---------
Each STL has a different name.. libc++ isn't named libstl.so

So calling it libiomp.so or libwhocares.so ensures that it doesn't
conflict with something down the road. Again it doesn't really matter
since the packager can now easily change the name. We may want to
allow that same cmake variable to be used inside llvm/clang so that if
everything is built together it all plays nice. This isn't something
user facing. The compiler will/should automatically add the right
name.

As an example
clang -mp foo.c # User never see's the name of the lib unless they do
ldd later or something. Assuming the default is llvm/openmp.

I hope the noise on this topic dies down soon. It's really all bikeshed


On Sat, May 16, 2015 at 11:35 AM, Chris Lattner <[hidden email]> wrote:

>
>> On May 15, 2015, at 3:47 PM, C Bergström <[hidden email]> wrote:
>>
>> Adding a prefix may be desireable to avoid conflicts or confusion.
>
> Sure, OTOH, we have precedent with this.  There were many c++ standard libraries before libc++.  I'm ok with LLVM's implementation being the defacto implementation, aren't you?
>
> -Chris
>
>>
>>
>> On Sat, May 16, 2015 at 5:35 AM, Chris Lattner <[hidden email]> wrote:
>>>
>>> On May 13, 2015, at 9:29 AM, Peyton, Jonathan L
>>> <[hidden email]> wrote:
>>>
>>> We understand that iomp is undesirable.  What we don’t know is what name is
>>> desirable.
>>>
>>> What name is desirable instead of iomp?  Do we want to link via…
>>> -lllvmomp
>>> -llvmomp
>>> -lclomp
>>> -lcomp
>>> -lnotintelomp ( just kidding J )
>>> … Some other name?  I get the feeling someone outside of Intel should make
>>> this choice.
>>>
>>>
>>> Why not -lomp?
>>>
>>> -Chris
>>>
>>>
>>> _______________________________________________
>>> Openmp-dev mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>>>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

Chris Lattner

> On May 15, 2015, at 9:44 PM, C Bergström <[hidden email]> wrote:
>
> maybe we're talking about the same thing
> ---------
> Each STL has a different name.. libc++ isn't named libstl.so
>
> So calling it libiomp.so or libwhocares.so ensures that it doesn't
> conflict with something down the road.

Let me be very clear here.  I am suggesting that this library be named "libomp.so" and thus be linked with "-lomp" (if named explicitly).

I'm not suggesting that we add magic behavior to the -l flag.

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] CMAKE_INSTALL_PREFIX vs -fopenmp and clang search library search path

C Bergström
yeah and I'm saying that name has a high chance to collide with
something else. In fact others have already posted to this fact. The
smart thing to do would be
a) leave it alone
b) name it libllvmopenmp or whatever else

On Sat, May 16, 2015 at 12:40 PM, Chris Lattner <[hidden email]> wrote:

>
>> On May 15, 2015, at 9:44 PM, C Bergström <[hidden email]> wrote:
>>
>> maybe we're talking about the same thing
>> ---------
>> Each STL has a different name.. libc++ isn't named libstl.so
>>
>> So calling it libiomp.so or libwhocares.so ensures that it doesn't
>> conflict with something down the road.
>
> Let me be very clear here.  I am suggesting that this library be named "libomp.so" and thus be linked with "-lomp" (if named explicitly).
>
> I'm not suggesting that we add magic behavior to the -l flag.
>
> -Chris
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
12