from:"Wink Saville via Phabricator via cfe\-commits"

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-10 Thread Wink Saville via Phabricator via cfe-commits

winksaville created this revision.
winksaville added reviewers: tstellar, morehouse, gottesmm, chapuni.
Herald added subscribers: llvm-commits, cfe-commits, mgorny.
Herald added projects: clang, LLVM.

I ran into the need for both while trying to compile zig (https://ziglang.org)
on my Arch Linux system and it fails. The problem is that the Arch Linux
clang package only provides shared libraries using the following cmake
command:

  cmake .. -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=/usr \
-DPYTHON_EXECUTABLE=/usr/bin/python \
-DBUILD_SHARED_LIBS=ON \
-DLLVM_LINK_LLVM_DYLIB=ON \
-DLLVM_ENABLE_RTTI=ON \
-DLLVM_BUILD_TESTS=ON \
-DLLVM_INCLUDE_DOCS=ON \
-DLLVM_BUILD_DOCS=ON \
-DLLVM_ENABLE_SPHINX=ON \
-DSPHINX_WARNINGS_AS_ERRORS=OFF \
-DLLVM_EXTERNAL_LIT=/usr/bin/lit \
-DLLVM_MAIN_SRC_DIR="$srcdir/llvm-$pkgver.src"

In particular, it uses "BUILD_SHARED_LIBS=ON" to get the shared
libraries. This works but there are no static libraries and further
a note in the documentation says,
https://llvm.org/docs/CMake.html#llvm-specific-variables :

  "BUILD_SHARED_LIBS is only recommended for use by LLVM developers.
  If you want to build LLVM as a shared library, you should use the
  LLVM_BUILD_LLVM_DYLIB option."

So it seemed to me it a solution would be to provide an easy way to build
clang or other llvm subprojects with both static and shared libraries.

As it turns out on small number modifications were needed:

  clang/CMAkeLists.txt:
  
   - Add options CLANG_ENABLE_STATIC_LIBRARIES and CLANG_ENABLE_SHARED_LIBRARIES
 These are defaulted to ON so libclang* libraries are built as
 static and shared.  As these are options they can be overridden on the
 cmake command line.
  
  clang/cmake/modules/AddClang.cmake add_clang_library:
  
   - Add support for STATIC, SHARED or both
   - Add support for OUTPUT_NAME which defaults to the ${name} passed to
 add_clang_library
  
  llvm/cmake/modules/AddLLVM.cmake llvm_add_library:
  
   - Changed so when both SHARED and STATIC are passed SHARED is built
 first as cmake object ${name}_shared.
  
 Without this change llvm_add_library causes the shared libraries to
 be linked to clang rather than the static library and clang fails
 when run with:
  
   $ ./bin/clang-9 --version
   : CommandLine Error: Option 'use-dbg-addr' registered more than once!
   LLVM ERROR: inconsistency in registered CommandLine options


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61804

Files:
  clang/CMakeLists.txt
  clang/cmake/modules/AddClang.cmake
  llvm/cmake/modules/AddLLVM.cmake


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -442,20 +442,20 @@
   endif()
 
   if(ARG_SHARED AND ARG_STATIC)
-# static
-set(name_static "${name}_static")
+# Do shared first
+set(name_shared "${name}_shared")
 if(ARG_OUTPUT_NAME)
   set(output_name OUTPUT_NAME "${ARG_OUTPUT_NAME}")
 endif()
 # DEPENDS has been appended to LLVM_COMMON_LIBS.
-llvm_add_library(${name_static} STATIC
+llvm_add_library(${name_shared} SHARED
   ${output_name}
   OBJLIBS ${ALL_FILES} # objlib
   LINK_LIBS ${ARG_LINK_LIBS}
   LINK_COMPONENTS ${ARG_LINK_COMPONENTS}
   )
-# FIXME: Add name_static to anywhere in TARGET ${name}'s PROPERTY.
-set(ARG_STATIC)
+# FIXME: Add name_shared to anywhere in TARGET ${name}'s PROPERTY.
+set(ARG_SHARED)
   endif()
 
   if(ARG_MODULE)
Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -44,8 +44,8 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED"
-""
+"SHARED;STATIC"
+"OUTPUT_NAME"
 "ADDITIONAL_HEADERS"
 ${ARGN})
   set(srcs)
@@ -80,10 +80,20 @@
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+  if(ARG_SHARED OR CLANG_ENABLE_SHARED_LIBRARIES)
 set(ARG_ENABLE_SHARED SHARED)
   endif()
-  llvm_add_library(${name} ${ARG_ENABLE_SHARED} ${ARG_UNPARSED_ARGUMENTS} 
${srcs})
+  if(ARG_STATIC OR CLANG_ENABLE_STATIC_LIBRARIES)
+set(ARG_ENABLE_STATIC STATIC)
+  endif()
+  if(ARG_OUTPUT_NAME)
+set(NAME_OUTPUT OUTPUT_NAME ${ARG_OUTPUT_NAME})
+  elseif(ARG_SHARED AND ARG_STATIC)
+set(NAME_OUTPUT OUTPUT_NAME ${name})
+  else()
+set(NAME_OUTPUT)
+  endif()
+  llvm_add_library(${name} ${NAME_OUTPUT} ${ARG_ENABLE_SHARED} 
${ARG_ENABLE_STATIC} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
   if(TARGET ${name})
 target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -447

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-12 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D61804#1499259 , @beanz wrote:

> I question the general utility of this patch, and I don't really think this 
> does anything we want the build system doing.


When you say you don't think the build system should do this, what do you mean?
The llvm_add_library routine without my change already supports generating both,
my change just changes the default cmake entities created from being:

  shared: ${name}
  static: ${name}_static

to:

  shared: ${name}_shared
  static: ${name}



> If you specify `STATIC` and `SHARED` to `llvm_add_library` it creates the 
> shared library target as the one that everything links against, which is 
> exactly what you don't want.

With the change I've made when both are specified the default cmake entity, 
${name}, is the static libraries. When neither are specified the default is 
static or shared depending on BUILD_SHARED_LIBS which is unchanged.

> There are two primary reasons why `BUILD_SHARED_LIBS` is not recommended for 
> non-development builds both have to do with how shared object linking works:
> 
> (1) Is that clang when linked against shared libraries is *way* slower (I 
> think last I measured was over 10%). This is caused by the need for resolving 
> linkage at process launch every time a process is launched.
> 
> (2) Is that LLVM relies on a strange mess of static initializers used for 
> static registration. The most problematic one is cl::opt. When you link a 
> static archive only the object files that contain unresolved symbols get 
> pulled in, when you link against a shared object, all of it gets pulled in. 
> Because static archives selectively pull in object files (and their static 
> initializers) we have had issues in the past where the static build of LLVM 
> works, but the shared build produces runtime errors from cl::opt.
> 
> I'm curious to understand the problem you are trying to solve. From other 
> posts on the list it really sounds to me like you want a variant of libClang 
> that exports the entire Clang API surface rather than just the C API. I think 
> there are better ways to accomplish that.

The problem is that some people want to use shared libraries and some want 
static. In particular Arch Linux prefers shared over static and with clang 
there is no option for building both so they end up building only shared. I'm 
trying to allow both to be built and ask the Arch Linux people to distribute 
both.

> Exposing Clang's libraries for piecemeal consumption is a much bigger problem 
> than just the build system not building libClang*.so. For example, Clang has 
> no equivalent of llvm-config, so there is no external representation of the 
> clang dependency graph that users can rely on.
> 
> This all aside, I also have issues with this implementation described inline 
> below.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-12 Thread Wink Saville via Phabricator via cfe-commits

winksaville marked an inline comment as done.
winksaville added a comment.

In D61804#1499267 , @beanz wrote:

> As an additional note, Arch linux should not be building clang with 
> `BUILD_SHARED_LIBS` nor should it be distributing those ,so files. That isn't 
> a supported configuration for Clang deployment.

Agreed, but I'd like to give them a choice of making both if I can get this 
accepted. It looks to me that llvm, libunwind and libcxx support building both, 
so the goal isn't unprecedented,

Comment at: clang/CMakeLists.txt:451
+option(CLANG_ENABLE_SHARED_LIBRARIES "Build libclang* as shared libraries." ON)
+option(CLANG_ENABLE_STATIC_LIBRARIES "Build libclang* as static libraries." ON)
+

beanz wrote:
> These shouldn't both default to `On`, that is a change in behavior that would 
> be a build-time regression for anyone not interested in building shared 
> libraries. `STATIC` should default `On`, and `SHARED` default `Off`.
> 
> Also you need to check that one of the two options is enabled. If both are 
> `Off` confusing things will happen.
I'll change it to default SHARED OFF and STATIC ON.

When both are off it acts as it does without these changes, the default will 
depend on BUILD_SHARED_LIBS:
```
# llvm_add_library(name sources...
#   SHARED;STATIC
# STATIC by default w/o BUILD_SHARED_LIBS.
# SHARED by default w/  BUILD_SHARED_LIBS.
```

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-12 Thread Wink Saville via Phabricator via cfe-commits

winksaville updated this revision to Diff 199172.
winksaville added a comment.

Change default to be CLANG_ENABLE_STATIC_LIBRARIES=ON 
CLANG_ENABLE_SHARED_LIBRARIeS=OFF

Suggested by @beanz


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804

Files:
  clang/CMakeLists.txt
  clang/cmake/modules/AddClang.cmake
  llvm/cmake/modules/AddLLVM.cmake


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -442,20 +442,20 @@
   endif()
 
   if(ARG_SHARED AND ARG_STATIC)
-# static
-set(name_static "${name}_static")
+# Do shared first
+set(name_shared "${name}_shared")
 if(ARG_OUTPUT_NAME)
   set(output_name OUTPUT_NAME "${ARG_OUTPUT_NAME}")
 endif()
 # DEPENDS has been appended to LLVM_COMMON_LIBS.
-llvm_add_library(${name_static} STATIC
+llvm_add_library(${name_shared} SHARED
   ${output_name}
   OBJLIBS ${ALL_FILES} # objlib
   LINK_LIBS ${ARG_LINK_LIBS}
   LINK_COMPONENTS ${ARG_LINK_COMPONENTS}
   )
-# FIXME: Add name_static to anywhere in TARGET ${name}'s PROPERTY.
-set(ARG_STATIC)
+# FIXME: Add name_shared to anywhere in TARGET ${name}'s PROPERTY.
+set(ARG_SHARED)
   endif()
 
   if(ARG_MODULE)
Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -44,8 +44,8 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED"
-""
+"SHARED;STATIC"
+"OUTPUT_NAME"
 "ADDITIONAL_HEADERS"
 ${ARGN})
   set(srcs)
@@ -80,10 +80,20 @@
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+  if(ARG_SHARED OR CLANG_ENABLE_SHARED_LIBRARIES)
 set(ARG_ENABLE_SHARED SHARED)
   endif()
-  llvm_add_library(${name} ${ARG_ENABLE_SHARED} ${ARG_UNPARSED_ARGUMENTS} 
${srcs})
+  if(ARG_STATIC OR CLANG_ENABLE_STATIC_LIBRARIES)
+set(ARG_ENABLE_STATIC STATIC)
+  endif()
+  if(ARG_OUTPUT_NAME)
+set(NAME_OUTPUT OUTPUT_NAME ${ARG_OUTPUT_NAME})
+  elseif(ARG_SHARED AND ARG_STATIC)
+set(NAME_OUTPUT OUTPUT_NAME ${name})
+  else()
+set(NAME_OUTPUT)
+  endif()
+  llvm_add_library(${name} ${NAME_OUTPUT} ${ARG_ENABLE_SHARED} 
${ARG_ENABLE_STATIC} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
   if(TARGET ${name})
 target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -447,6 +447,9 @@
 option(CLANG_ENABLE_ARCMT "Build ARCMT." ON)
 option(CLANG_ENABLE_STATIC_ANALYZER "Build static analyzer." ON)
 
+option(CLANG_ENABLE_SHARED_LIBRARIES "Build libclang* as shared libraries." 
OFF)
+option(CLANG_ENABLE_STATIC_LIBRARIES "Build libclang* as static libraries." ON)
+
 option(CLANG_ENABLE_PROTO_FUZZER "Build Clang protobuf fuzzer." OFF)
 
 if(NOT CLANG_ENABLE_STATIC_ANALYZER AND CLANG_ENABLE_ARCMT)


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -442,20 +442,20 @@
   endif()
 
   if(ARG_SHARED AND ARG_STATIC)
-# static
-set(name_static "${name}_static")
+# Do shared first
+set(name_shared "${name}_shared")
 if(ARG_OUTPUT_NAME)
   set(output_name OUTPUT_NAME "${ARG_OUTPUT_NAME}")
 endif()
 # DEPENDS has been appended to LLVM_COMMON_LIBS.
-llvm_add_library(${name_static} STATIC
+llvm_add_library(${name_shared} SHARED
   ${output_name}
   OBJLIBS ${ALL_FILES} # objlib
   LINK_LIBS ${ARG_LINK_LIBS}
   LINK_COMPONENTS ${ARG_LINK_COMPONENTS}
   )
-# FIXME: Add name_static to anywhere in TARGET ${name}'s PROPERTY.
-set(ARG_STATIC)
+# FIXME: Add name_shared to anywhere in TARGET ${name}'s PROPERTY.
+set(ARG_SHARED)
   endif()
 
   if(ARG_MODULE)
Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -44,8 +44,8 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED"
-""
+"SHARED;STATIC"
+"OUTPUT_NAME"
 "ADDITIONAL_HEADERS"
 ${ARGN})
   set(srcs)
@@ -80,10 +80,20 @@
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+  if(ARG_SHARED OR CLANG_ENABLE_SHARED_LIBRARIES)
 set(ARG_ENABLE_SHARED SHARED)
   endif()
-  llvm_add_library(${name} ${ARG_ENABLE_SHARED} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
+  if(ARG_STATIC OR CLANG_ENABLE_STATIC_LIBRARIES)
+set(ARG_ENABLE_STATIC STATIC)
+  endif()
+  if(ARG_OUTPUT_NAME)
+set(NAME_OUTPUT OUTPUT_NAME

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-13 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

> Arch Linux is in an unsupported state, and your patch isn't the way forward.

OK, I'll filed a bug, https://bugs.archlinux.org/task/62624

> Let's rewind.
> 
> Why do "some people like shared libraries"? There are usually two reasons 
> people cite for linking shared libraries. One is reduced binary distribution 
> size because you're reducing duplication of code. The other, is the ability 
> to update libraries without updating tools.
> 
> The later, is not an issue here. LLVM and Clang's C++ libraries don't provide 
> any API or ABI stability guarantees across releases, so there is no way 
> you're going to reasonably update LLVM or Clang libraries without rebuilding 
> the applications using them.
> 
> The former can be valuable, but it comes at a cost. Dynamic resolution of 
> symbols slows down process launch time, and dynamic resolution of C++ 
> link-once ODRs are exceptionally slow. If you are building a compiler, 
> chances are you don't want to slow down your process launch that much. But 
> let's pretend you don't care. Your solution still isn't the right way to do 
> this.
> 
> Creating component shared libraries results in duplicating all the C++ 
> link-once ODRs across each shared module. That will not only slow down your 
> process launch, but bloat the size of your binary distribution.

Learn something new every day, thanks.

> 
> 
> In D61804#1499276 , @winksaville 
> wrote:
> 
>> It looks to me that llvm, libunwind and libcxx support building both, so the 
>> goal isn't unprecedented,
> 
> 
> This is very much an apple and oranges comparison. For one, LLVM does not 
> support generating component dylibs and shared libs. It supports generating 
> libLLVM, a single dylib containing all of the LLVM components rolled 
> together. libunwind, libcxx, libcxxabi, are runtime libraries that are 
> designed to allow static linkage, and they don't link LLVM.
> 
> I apologize that I missed your thread on the dev list, because that would 
> have been a much better place to have this conversation. Having gone back and 
> read it now, it sounds to me like what you really want is a clang equivalent 
> of libLLVM. That is a reasonable and viable thing to want. This patch 
> (https://reviews.llvm.org/P8147) is a first stab. I'm happy to prepare that 
> for landing in Clang if that meets your needs, and that is a viable way 
> forward.

Yes, as @tstellar also said, creating a single clang ".so" that exported the 
same set of symbols as the static libraries (libclang*.a) would be nice and 
probably what Arch Linux would prefer, especially if it was "officially" 
supported and was generated "simultaneously" with the static libraries.

I applied your patch to master:

  $ git log -1
  commit e5a5b7db3ac71a37af790a416486f653dbff47fb (HEAD -> master, 
origin/master, origin/HEAD)
  Author: anatolik 
  Date:   Sun May 12 19:16:54 2019 +
  
  archrelease: copy trunk to testing-x86_64
  
  git-svn-id: file:///srv/repos/svn-packages/svn@353145 
eb2447ed-0c53-47e4-bac8-5bc4a241df78

And built llvm, clang, lld and compiler-rt using:

  $ cmake ../llvm -G Ninja '-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt' 
-DCMAKE_INSTALL_PREFIX=/home/wink/local-clang-shlib-master 
-DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=ON
  $ ninja -j11 -v

I see libclang.so*:

  $ ls build-clang-shlib-master/lib/libclang.so* -al
  lrwxrwxrwx 1 wink users   16 May 13 10:49 
build-clang-shlib-master/lib/libclang.so -> libclang.so.9svn
  -rwxr-xr-x 1 wink users 81573360 May 13 10:49 
build-clang-shlib-master/lib/libclang.so.9
  lrwxrwxrwx 1 wink users   13 May 13 10:49 
build-clang-shlib-master/lib/libclang.so.9svn -> libclang.so.9

But the exported symbols are only the clang C api from libclang.exports:

  $ nm -g --demangle build-clang-shlib-master/lib/libclang.so.9 | grep ' T ' | 
wc -l
  381
  $ wc -l clang/tools/libclang/libclang.exports 
  381 clang/tools/libclang/libclang.exports

If I don't use your patch and build the same way lib/libclang.so.9 is still 
created and with the 381 globals:

  $ cmake ../llvm -G Ninja '-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt' 
-DCMAKE_INSTALL_PREFIX=/home/wink/local-master -DCMAKE_BUILD_TYPE=Release 
-DLLVM_BUILD_LLVM_DYLIB=ON
  $ ninja -j11 -v
  $ ls build-master/lib/libclang*so* -al
  lrwxrwxrwx 1 wink users   16 May 13 11:35 build-master/lib/libclang.so -> 
libclang.so.9svn
  -rwxr-xr-x 1 wink users 81573360 May 13 11:35 build-master/lib/libclang.so.9
  lrwxrwxrwx 1 wink users   13 May 13 11:35 
build-master/lib/libclang.so.9svn -> libclang.so.9
  $ nm -g --demangle build-master/lib/libclang.so.9 | grep ' T ' | wc -l
  381

I was assuming the goal of clang-shlib was to export all of the symbols as 
exported by the libclang*.a files,
of so the first stab didn't quite do it.

But one thing it did do was reduce the steps and time ninja needed to complete 
my test
build from 4355 steps for the

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-13 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D61804#1500409 , @beanz wrote:

> My change should not have decreased build time from trunk, nor should it have 
> reduced the number of build steps. That patch should generate 
> lib/libClang_shared.so, which will export the C++ API. libClang is unchanged 
> since changing it would break existing clients of the library.


OK, I'll look into what I've done wrong. If you see anything or have any 
guesses please let me know.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-13 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D61804#1500445 , @winksaville wrote:

> In D61804#1500409 , @beanz wrote:
>
> > My change should not have decreased build time from trunk, nor should it 
> > have reduced the number of build steps. That patch should generate 
> > lib/libClang_shared.so, which will export the C++ API. libClang is 
> > unchanged since changing it would break existing clients of the library.
>
>
> OK, I'll look into what I've done wrong. If you see anything or have any 
> guesses please let me know.


I found my mistake that caused the speed up, I'd aborted a previous build so 
ninja started where it left off, just as should :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-13 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

@beanz I found what I think is the reason libclang_shared.so isn't being 
created.

I added a bunch of debug output using `message` to add_llvm_subdirectory:

  1041  function(add_llvm_subdirectory project type name)
  1042message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}:+")
  1043set(add_llvm_external_dir "${ARGN}")
  1044if("${add_llvm_external_dir}" STREQUAL "")
  1045  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
1")
  1046  set(add_llvm_external_dir ${name})
  1047endif()
  1048canonicalize_tool_name(${name} nameUPPER)
  1049set(canonical_full_name ${project}_${type}_${nameUPPER})
  1050get_property(already_processed GLOBAL PROPERTY 
${canonical_full_name}_PROCESSED)
  1051if(already_processed)
  1052  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}:- 
already_processed")
  1053  return()
  1054endif()
  1055set_property(GLOBAL PROPERTY ${canonical_full_name}_PROCESSED YES)
  1056message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 1.1 
canonical_full_name=${canonical_full_name} nameUPPER=${nameUPPER}")
  1057  
  1058if(EXISTS 
${CMAKE_CURRENT_SOURCE_DIR}/${add_llvm_external_dir}/CMakeLists.txt)
  1059  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
2")
  1060  # Treat it as in-tree subproject.
  1061  option(${canonical_full_name}_BUILD
  1062 "Whether to build ${name} as part of ${project}" On)
  1063  mark_as_advanced(${project}_${type}_${name}_BUILD)
  1064  if(${canonical_full_name}_BUILD)
  1065
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/${add_llvm_external_dir} 
${add_llvm_external_dir})
  1066  endif()
  1067else()
  1068  set(LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR
  1069"${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}"
  1070CACHE PATH "Path to ${name} source directory")
  1071  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 3 
LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR=\"${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}\"")
  1072  set(${canonical_full_name}_BUILD_DEFAULT ON)
  1073  if(NOT LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR OR NOT EXISTS 
${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR})
  1074set(${canonical_full_name}_BUILD_DEFAULT OFF)
  1075message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.1 
${canonical_full_name}_BUILD_DEFAULT=${${canonical_full_name}_BUILD_DEFAULT}")
  1076  endif()
  1077  if("${LLVM_EXTERNAL_${nameUPPER}_BUILD}" STREQUAL "OFF")
  1078set(${canonical_full_name}_BUILD_DEFAULT OFF)
  1079message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.2 ${LLVM_EXTERNAL_${nameUPPER}_BUILD} 
${canonical_full_name}_BUILD_DEFAULT=${${canonical_full_name}_BUILD_DEFAULT}")
  1080  endif()
  1081  option(${canonical_full_name}_BUILD
  1082"Whether to build ${name} as part of LLVM"
  1083${${canonical_full_name}_BUILD_DEFAULT})
  1084  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.3 ${canonical_full_name}_BUILD=${${canonical_full_name}_BUILD}")
  1085  if (${canonical_full_name}_BUILD)
  1086message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.4")
  1087if(EXISTS ${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR})
  1088  message(STATUS "add_llvm_subdirectory ${project} ${type} 
${name}: 3.4.1")
  1089  add_subdirectory(${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR} 
${add_llvm_external_dir})
  1090elseif(NOT "${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}" STREQUAL "")
  1091  message(STATUS "add_llvm_subdirectory ${project} ${type} 
${name}: 3.4.2")
  1092  message(WARNING "Nonexistent directory for ${name}: 
${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}")
  1093endif()
  1094message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.4.99")
  1095  endif()
  1096  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.99")
  1097endif()
  1098message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}:-")
  1099  endfunction()

The typical output when adding a subdirectory is:

  -- add_llvm_subdirectory CLANG TOOL clang-refactor:+
  -- add_llvm_subdirectory CLANG TOOL clang-refactor: 1
  -- add_llvm_subdirectory CLANG TOOL clang-refactor: 1.1 
canonical_full_name=CLANG_TOOL_CLANG_REFACTOR nameUPPER=CLANG_REFACTOR
  -- add_llvm_subdirectory CLANG TOOL clang-refactor: 2
  -- add_llvm_subdirectory CLANG TOOL clang-refactor:-

Where at line 1058 the clause `if(EXISTS 
${CMAKE_CURRENT_SOURCE_DIR}/${add_llvm_external_dir}/CMakeLists.txt)`
is TRUE and we go through path `2`; lines 1059 - 1066.

The only time we don't go though path 2 is clang-shlib which goes though path 
3,  lines 1068 - 1096.
In that case we endup with CLANG_TOOL_CLANG_SHLIB_BUILD_DEFAULT=OFF
and CLANG_TOOL_CLANG_SHLIB_BUILD=OFF so libclan

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-14 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

You mention that you're using OBJECT libraries so objects aren't built 
mutliples times
and in my current tests the number of steps increased by only 3, it went from 
4353 to 4356,
when using this patch, which is great!

What I see in my testing of the patch is that cmake finds that the compilers 
support position independent code and use `-fPIC` as default:

  -- LLVM default target triple: x86_64-unknown-linux-gnu
  -- Performing Test C_SUPPORTS_FPIC
  -- Performing Test C_SUPPORTS_FPIC - Success
  -- Performing Test CXX_SUPPORTS_FPIC
  -- Performing Test CXX_SUPPORTS_FPIC - Success
  -- Building with -fPIC

And then, as expected, I see the compile command lines have `-fPIC`:

  [1/4356] /usr/bin/c++  -DGTEST_HAS_RTTI=0 ... -fPIC ...

Its my understanding that when creating shared libraries position independent 
code generation is required.
Is there a problem if in some scenario the OBJECT libraries were not compiled 
with `-fPIC`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-14 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

I did some quick testing.

I used cmake and ninja to build `llvm` and enabled `clang;lld;compiler-rt` 
subprojects:

  $ cd build-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON
  $ cmake ../llvm -G Ninja '-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt' 
-DCMAKE_INSTALL_PREFIX=/home/wink/local-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON
 -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON
  $ ninja

I then used `bin/clang++` to create `bin/clang-shared` and verified it ran and 
looked at the sizes; `bin/clang-shared` is 187K while `bin/clang-9` is 45M

  $ bin/clang++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type 
-Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 
-DNDEBUG  -Wl,-allow-shlib-undefined   -Wl,--export-dynamic  
-Wl,-rpath-link,/home/wink/prgs/llvm/llvm-project/build-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON/./lib
  -Wl,-O3 tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o 
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o 
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o 
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1gen_reproducer_main.cpp.o  -o 
bin/clang-shared  -Wl,-rpath,"\$ORIGIN/../lib" -lpthread lib/libclang_shared.so 
lib/libLLVM-9svn.so 
  $ ./bin/clang-shared --version
  clang version 9.0.0 (g...@github.com:winksaville/llvm-project 
2e41f82e327c9aace5b1367995357a787be77105)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix
  InstalledDir: 
/home/wink/prgs/llvm/llvm-project/build-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON/./bin
  $ ls -hal bin/clang-9 bin/clang-shared
  -rwxr-xr-x 1 wink users  45M May 14 17:57 bin/clang-9
  -rwxr-xr-x 1 wink users 187K May 14 22:15 bin/clang-shared

And I'd previously built `clang-9` with LLVM_BUILD_LLVM_DYLIB=OFF and it is 
114M:

  $ ls -hal ../build-beanz-clang-shlib-2-add-debug-DYNLIB-OFF/bin/clang-9
  -rwxr-xr-x 1 wink users 114M May 14 11:31 
../build-beanz-clang-shlib-2-add-debug-DYNLIB-OFF/bin/clang-9

I then compilef hi.c with `clang-shared` and ran the result:

  $ cat ../hi.c
  #include 
  
  int main(void) {
printf("hi\n");
return 0;
  }
  $ ./bin/clang-shared ../hi.c -o hi
  $ ./hi
  hi

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-14 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

Questions:

- Should we only build `libclang_shared.so` if `LLVM_BUILD_LLVM_DYLIB` is ON?
- Should we use link clang-9 to libclang_shared.so when `LLVM_LINK_LLVM_DYLIB` 
is ON?
- Or maybe we should define `BUILD_CLANG_DYLIB` and `LINK_CLANG_DYLIB` or ... ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-14 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

I did some quick testing.

I used cmake and ninja to build `llvm` and enabled `clang;lld;compiler-rt` 
subprojects:

  $ cd build-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON
  $ cmake ../llvm -G Ninja '-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt' 
-DCMAKE_INSTALL_PREFIX=/home/wink/local-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON
 -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON
  $ ninja

I then used `bin/clang++` to create `bin/clang-shared` and verified it ran and 
looked at the sizes; `bin/clang-shared` is 187K while `bin/clang-9` is 45M

  $ bin/clang++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type 
-Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 
-DNDEBUG  -Wl,-allow-shlib-undefined   -Wl,--export-dynamic  
-Wl,-rpath-link,/home/wink/prgs/llvm/llvm-project/build-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON/./lib
  -Wl,-O3 tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o 
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o 
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o 
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1gen_reproducer_main.cpp.o  -o 
bin/clang-shared  -Wl,-rpath,"\$ORIGIN/../lib" -lpthread lib/libclang_shared.so 
lib/libLLVM-9svn.so 
  $ ./bin/clang-shared --version
  clang version 9.0.0 (g...@github.com:winksaville/llvm-project 
2e41f82e327c9aace5b1367995357a787be77105)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix
  InstalledDir: 
/home/wink/prgs/llvm/llvm-project/build-beanz-clang-shlib-2-add-debug-BUILD-LINK_DYNLIB-ON/./bin
  $ ls -hal bin/clang-9 bin/clang-shared
  -rwxr-xr-x 1 wink users  45M May 14 17:57 bin/clang-9
  -rwxr-xr-x 1 wink users 187K May 14 22:15 bin/clang-shared

And I'd previously built `clang-9` with LLVM_BUILD_LLVM_DYLIB=OFF and it is 
114M:

  $ ls -hal ../build-beanz-clang-shlib-2-add-debug-DYNLIB-OFF/bin/clang-9
  -rwxr-xr-x 1 wink users 114M May 14 11:31 
../build-beanz-clang-shlib-2-add-debug-DYNLIB-OFF/bin/clang-9

I then compilef hi.c with `clang-shared` and ran the result:

  $ cat ../hi.c
  #include 
  
  int main(void) {
printf("hi\n");
return 0;
  }
  $ ./bin/clang-shared ../hi.c -o hi
  $ ./hi
  hi

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-14 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

Questions:

- Should we only build `libclang_shared.so` if `LLVM_BUILD_LLVM_DYLIB` is ON?
- Should we use link clang-9 to libclang_shared.so when `LLVM_LINK_LLVM_DYLIB` 
is ON?
- Or maybe we should define `BUILD_CLANG_DYLIB` and `LINK_CLANG_DYLIB` or ... ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-14 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

Sorry, the two previous comments were meant for D61909 
 and I've moved them.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

2019-05-15 Thread Wink Saville via Phabricator via cfe-commits

winksaville abandoned this revision.
winksaville added a comment.

Abandoning, @beanz has proposed a better solution, D61909 



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-15 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

IMHO "`BUILD_CLANG_DYLIB`" is needed. As you have it now libclang_shared.so is 
always builds on UNIX systems, which I believe means that all linux distros 
would have both increasing their sizes. I think the default should be "always" 
`build libclang*.a` as it is now, and optionally build `libclang_shared.so` 
using some flag.

And adding "`LINK_CLANG_DYLIB`" in a future patch SGTM.




Comment at: clang/tools/CMakeLists.txt:16
 add_clang_subdirectory(clang-refactor)
+if(UNIX)
+  add_clang_subdirectory(clang-shlib)

It seems to me we should put creating clang-shlib in the users control and 
default to off.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-15 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D61909#1503483 , @beanz wrote:

> In D61909#1503433 , @winksaville 
> wrote:
>
> > IMHO "`BUILD_CLANG_DYLIB`" is needed. As you have it now libclang_shared.so 
> > is always builds on UNIX systems, which I believe means that all linux 
> > distros would have both increasing their sizes.
>
>
> Distributions shouldn't be installing `all` unless they really want 
> everything and the kitchen sink. We have the `LLVM_DISTRIBUTION_COMPONENTS` 
> so that distributions can decide which pieces of the LLVM & Clang 
> distributions they want to install. That is the cleanest mechanism for 
> curating an install.

Sorry, maybe I didn't make myself clear. I didn't mean distros installing "all" 
of LLVM. What I meant was that this change currently uses `if(UNIX)` to 
generate `libclang_shared.so`, which means "all linux distors" will have both 
`libclang*.a` and `libclang_shared.so`. Therefore, I'm suggesting the need for 
something like "`BUILD_CLANG_DYLIB`" so that `libclang_shared.so` is only 
created when "`BUILD_CLANG_DYLIB`" is `ON` and the default is `OFF`.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-15 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

> Distributions only get libclang_shared if they run the `install` target which 
> installs all of LLVM & Clang. The point of `LLVM_DISTRIBUTION_COMPONENTS` is 
> to allow people constructing distributions to choose which pieces they want 
> to install without introducing a whole lot of overhead in the build system. 
> The old method of passing dozens of flags to enable and disable individual 
> pieces of the build resulted in a combinatoric explosion in build settings 
> which are confusing and ill understood. The new method is one setting that is 
> much cleaner to use.
> 
> Anyone constructing a distribution should be specifying 
> `LLVM_DISTRIBUTION_COMPONENTS` and running the `install-distribution` target.

Is there any documentation for LLVM_DISTRIBUTION_COMPONENTS? I searched 
llvm-project and didn't find any.
The only thing I found on the internet was this LLVM weekly post 
, which pointed me to your llvm-dev post 
 which says look 
at Apple-stage2.cmake.
I looked at it and there are a bunch of `set` commands and the one occurrance 
of `set(LLVM_DISTRIBUTION_COMPONENTS` with a list of components. So I thought 
I'd try the simplest thing possible, pass `-DLLVM_DISTRIBUTION_COMPONENTS` to 
cmake:

  $ cmake ../llvm -G Ninja -DLLVM_DISTRIBUTION_COMPONENTS=clang

And it failed with:

  CMake Error at CMakeLists.txt:1108 (message):
Specified distribution component 'clang' doesn't have a target
  
  
  CMake Error at CMakeLists.txt:1114 (message):
Specified distribution component 'clang' doesn't have an install target
  
  
  CMake Error at CMakeLists.txt:1120 (message):
Specified distribution component 'clang' doesn't have an install-stripped
target.  Its installation target creation should be changed to use
add_llvm_install_targets, or you should manually create the
'install-clang-stripped' target.

So obviously, that was wrong.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-16 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D61909#1505046 , @beanz wrote:

> There is a simpler example distribution configuration, but sadly there isn't 
> documentation. That is something I can fix.


Please add documentation if you want people to use it :)
In the mean time I'll watch the the talk 
 you mentioned.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61909: Add Clang shared library with C++ exports

2019-05-16 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

Just to be clear, I have nothing to do with any distribution except as a user 
(Arch Linux) so please take
what I say and request with a huge grain of salt. As mentioned I have filed a 
bug 
against the clang package in Arch Linux so hopefully we'll be able to get them 
going in the right direction.

I do have another use case that I've done a little work on. For Pony 
 they have a problem tracking
the various versions of LLVM that distros use so I created a git submodule 
 which allows a ponyc
developer to work with multiple versions or variations of LLVM simultaneously 
and switch between them
relatively easily. Also, they will eventually switch to bundling libLLVM 
instead of using the system installed
version which could be any version. I have a standalone version of that at 
mkllvm-tool-chain .

Anyway, I'm obviously using "intall" style and I suggest having a 
`BUILD_CLANG_DYLIB` and `LINK_CLANG_DYLIB` would
be useful to more precisely control how a compiler might use the `libclang*`. 
Some users of LLVM might have a bunch of tools
that use various subparts of clang and they might be resident all the time. So 
startup performance isn't a problem, but
reducing the in memory foot print using shared libraries could be useful. Or 
not building the them at all if they are not
using them in anyway. So you're probably correct that for distros these flags 
shouldn't be used, but for other use cases
of LLVM I think there are.

In anycase, I think this is a worth while change as it and If you're still not 
convinced I like to see this in sooner rather than later.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61909/new/

https://reviews.llvm.org/D61909



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

2019-05-21 Thread Wink Saville via Phabricator via cfe-commits

winksaville created this revision.
winksaville added a reviewer: beanz.
Herald added subscribers: llvm-commits, cfe-commits, mgorny.
Herald added projects: clang, LLVM.

Add runtime libcxxabi, use gold linker and create LLVMgold.so.

Tested with on monorepo with:

mkdir build && cd build && \
 cmake ../llvm -G Ninja \

  -C ../clang/cmake/caches/DistributionExample.cmake \
  -DCMAKE_INSTALL_PREFIX=local-opt \
  && \

ninja stage2-distribution && \
 cd tools/clang/stage2-bins && \
 ninja check-all && \
 ninja install-distribution


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62215

Files:
  clang/cmake/caches/DistributionExample-stage2.cmake
  clang/cmake/caches/DistributionExample.cmake
  llvm/tools/gold/CMakeLists.txt


Index: llvm/tools/gold/CMakeLists.txt
===
--- llvm/tools/gold/CMakeLists.txt
+++ llvm/tools/gold/CMakeLists.txt
@@ -13,6 +13,7 @@
 
   add_llvm_library(LLVMgold MODULE
 gold-plugin.cpp
+PLUGIN_TOOL LLVM
 )
 
 endif()
Index: clang/cmake/caches/DistributionExample.cmake
===
--- clang/cmake/caches/DistributionExample.cmake
+++ clang/cmake/caches/DistributionExample.cmake
@@ -2,7 +2,7 @@
 
 #Enable LLVM projects and runtimes
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
 
 # Only build the native target in stage1 since it is a throwaway build.
 set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
@@ -33,6 +33,9 @@
 
 # Setup the bootstrap build.
 set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+set(LLVM_USE_LINKER "gold" CACHE STRING "")
+set(LLVM_BINUTILS_INCDIR "/usr/include" CACHE PATH "")
+set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS ON CACHE BOOL "")
 
 if(STAGE2_CACHE_FILE)
   set(CLANG_BOOTSTRAP_CMAKE_ARGS
Index: clang/cmake/caches/DistributionExample-stage2.cmake
===
--- clang/cmake/caches/DistributionExample-stage2.cmake
+++ clang/cmake/caches/DistributionExample-stage2.cmake
@@ -2,7 +2,9 @@
 # bootstrap build.
 
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
+
+set(LLVM_USE_LINKER "gold" CACHE STRING "")
 
 set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 


Index: llvm/tools/gold/CMakeLists.txt
===
--- llvm/tools/gold/CMakeLists.txt
+++ llvm/tools/gold/CMakeLists.txt
@@ -13,6 +13,7 @@
 
   add_llvm_library(LLVMgold MODULE
 gold-plugin.cpp
+PLUGIN_TOOL LLVM
 )
 
 endif()
Index: clang/cmake/caches/DistributionExample.cmake
===
--- clang/cmake/caches/DistributionExample.cmake
+++ clang/cmake/caches/DistributionExample.cmake
@@ -2,7 +2,7 @@
 
 #Enable LLVM projects and runtimes
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
 
 # Only build the native target in stage1 since it is a throwaway build.
 set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
@@ -33,6 +33,9 @@
 
 # Setup the bootstrap build.
 set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+set(LLVM_USE_LINKER "gold" CACHE STRING "")
+set(LLVM_BINUTILS_INCDIR "/usr/include" CACHE PATH "")
+set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS ON CACHE BOOL "")
 
 if(STAGE2_CACHE_FILE)
   set(CLANG_BOOTSTRAP_CMAKE_ARGS
Index: clang/cmake/caches/DistributionExample-stage2.cmake
===
--- clang/cmake/caches/DistributionExample-stage2.cmake
+++ clang/cmake/caches/DistributionExample-stage2.cmake
@@ -2,7 +2,9 @@
 # bootstrap build.
 
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
+
+set(LLVM_USE_LINKER "gold" CACHE STRING "")
 
 set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

2019-05-21 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

This may not "correct" but I had to do these to get `ninja stage2-distribution` 
to complete on my computer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62215/new/

https://reviews.llvm.org/D62215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

2019-05-22 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D62215#1510933 , @beanz wrote:

> Adding "libcxxabi" to `LLVM_ENABLE_RUNTIMES` is fine, but the other changes 
> to the DistributionExample are only needed because you chose to use gold, 
> which is a configuration-specific decision that is not representative of how 
> most people will build, therefore it shouldn't be in the example.
>
> I'm also not sure the `PLUGIN_TOOL` line is correct. That seems to assume 
> that you either set `LLVM_ENABLE_LLVM_DYLIB`, or have libLLVM pre-installed, 
> which I don't think most people do.


Actually I used `ld.gold` and `LLVMgold.so` just to make the 
DistributionExample work,
it was not that I wanted or desired to use it.

Here were the initial steps.

I cloned `llvm/llvm-project` and I'm at sha1 6e19534a
(Note: `wink@wink-desktop:~/prgs/llvm/llvm-project-2 (master)` is part of my 
command line prompt):

  wink@wink-desktop:~/prgs/llvm/llvm-project-2 (master)
  $ git log -1
  commit 6e19543a2a2013bd357eb15e383b435cd0cbb810 (HEAD -> master, 
upstream/master, origin/master, origin/HEAD)
  Author: Yi-Hong Lyu 
  Date:   Tue May 21 19:42:57 2019 +
  
  [PowerPC][NFC] Add a tests for Reordering CSR reloads in epilogue to 
follow the same order as CSR saves in the prologue
  
  llvm-svn: 361299

I then used `cmake` and `ninja stage2-distribution` and it fails when trying to 
build `llvm-tblgen` with
`error loading plugin: ` ... `LLVMgold.so: cannot open shared object file: No 
such file or directory`.
Note: There are no modifications and there is no explicit intention of using 
`ld.gold`:

  wink@wink-desktop:~/prgs/llvm/llvm-project-2/build-master (master)
  $ cmake ../llvm -G Ninja -C ../clang/cmake/caches/DistributionExample.cmake 
-DCMAKE_INSTALL_PREFIX=~/local-master
  ...
  -- Configuring done
  -- Generating done
  -- Build files have been written to: 
/home/wink/prgs/llvm/llvm-project-2/build-master
  wink@wink-desktop:~/prgs/llvm/llvm-project-2/build-master (master)
  $ ninja -j5 stage2-distribution
  [186/2251] Generating VCSRevision.h
  -- Found Git: /usr/bin/git (found version "2.21.0") 
  [218/2251] Building CXX object lib/IR/CMakeFiles/LLVMCore.dir/Core.cpp.o
  ...
  -- Build files have been written to: 
/home/wink/prgs/llvm/llvm-project-2/build-master/runtimes/runtimes-bins
  [2249/2251] Performing configure step for 'stage2'
  loading initial cache file 
/home/wink/prgs/llvm/llvm-project-2/clang/cmake/caches/DistributionExample-stage2.cmake
  -- The C compiler identification is Clang 9.0.0
  -- The CXX compiler identification is Clang 9.0.0
  -- The ASM compiler identification is Clang
  ..
  [256/2445] Linking CXX executable bin/llvm-tblgen
  FAILED: bin/llvm-tblgen 
  : && /home/wink/prgs/llvm/llvm-project-2/build-master/./bin/clang++  -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections 
-flto -O3 -gline-tables-only -DNDEBUG  -flto -Wl,-allow-shlib-undefined
-Wl,-O3 -Wl,--gc-sections 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/AsmMatcherEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/AsmWriterEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/AsmWriterInst.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/Attributes.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CallingConvEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeEmitterGen.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenHwModes.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenInstruction.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenMapTable.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenSchedule.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenTarget.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcherEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcherGen.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcherOpt.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcher.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/DisassemblerEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/ExegesisEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/FastISelEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/FixedLenDecoderEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/InfoByHwMode.cpp.o 
utils/Tab

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

2019-05-22 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

> I actually really appreciate you trying this out and reporting back with such 
> detailed feedback on your experience. Thank you for your patience, and I'm 
> sorry if I'm being a bit of a pain.

Been a good learning experince for me, both LLVM and cmake, I hope you don't 
think I'm being pedantic or odd,
but I'm just trying to verify how things should work. Additionally, I want to 
get Arch Linux to provide static and
dynamic libraries for clang.

> I think the correct fix for this is to use lld on non-Darwin platforms, and 
> that can be done by adding the following code to DistributionExample.cmake:
> 
>   if (NOT APPLE)
> set(BOOTSTRAP_LLVM_ENABLE_LLD On CACHE BOOL "")
>   endif()
> 
> 
> This will force using LLD on non-Darwin builds. This combined with adding 
> "libcxxabi" to `LLVM_ENABLE_RUNTIMES` should actually get your build working 
> without any further changes (none of the gold stuff should be needed).

This seems a reasonable solution,

> Additionally we should probably consider adding better error checking to the 
> bootstrap configurations to error out during configuration on some of these 
> problems. For example we should be able to verify that when 
> `BOOTSTRAP_LLVM_ENABLE_LTO=On` the following things should be true.
> 
> - If your host is Windows, in stage 1 you must be building `lld`, and in 
> stage 2 you must be linking with it
> - If your host is Linux, in stage 1 you must be building `lld`, and in stage 
> 2 you must be linking with it -or- you must build the Gold plugin in stage1 
> and link with `ld.gold` in stage 2.
> - If your host is Darwin, you must not be using `lld`

IIRC, on linux if LTO is ON I had to use `ld.gold` for both stage 1 and 2, 
although that maybe
just the way it ended up and it wasn't necessary. But I'll test whatever you 
come up with.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62215/new/

https://reviews.llvm.org/D62215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62279: Use LTO capable linker

2019-05-22 Thread Wink Saville via Phabricator via cfe-commits

winksaville created this revision.
winksaville added a reviewer: beanz.
Herald added subscribers: cfe-commits, dexonsmith, inglorion, mehdi_amini, 
mgorny.
Herald added a project: clang.

In DistributionExample.cmake be sure we use a LTO
capable linker, the easiest to choose is lld.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62279

Files:
  clang/cmake/caches/DistributionExample.cmake


Index: clang/cmake/caches/DistributionExample.cmake
===
--- clang/cmake/caches/DistributionExample.cmake
+++ clang/cmake/caches/DistributionExample.cmake
@@ -17,6 +17,11 @@
 # the proper LTO library dependencies can be connected.
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
+if (NOT APPLE)
+  # Since LLVM_ENABLE_LTO is ON we need a LTO capable linker
+  set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
+
 # Expose stage2 targets through the stage1 build configuration.
 set(CLANG_BOOTSTRAP_TARGETS
   check-all


Index: clang/cmake/caches/DistributionExample.cmake
===
--- clang/cmake/caches/DistributionExample.cmake
+++ clang/cmake/caches/DistributionExample.cmake
@@ -17,6 +17,11 @@
 # the proper LTO library dependencies can be connected.
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
+if (NOT APPLE)
+  # Since LLVM_ENABLE_LTO is ON we need a LTO capable linker
+  set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
+
 # Expose stage2 targets through the stage1 build configuration.
 set(CLANG_BOOTSTRAP_TARGETS
   check-all
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62279: Use LTO capable linker

2019-05-22 Thread Wink Saville via Phabricator via cfe-commits

winksaville abandoned this revision.
winksaville added a comment.

Chris, I thought you had added libcxxabi in LLVM_ENABLE_RUNTIMES, but you 
hadn't so abandoning and trying again.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62279/new/

https://reviews.llvm.org/D62279



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62279: Use LTO capable linker

2019-05-23 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

Adding libcxxabi worked and `ninja stage2-distribution` succeeded but I then 
ran `ninja check-all` and from within stage2-bins/ but that failed:

  [1072/1526] cd 
/home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins
 && /usr/bin/cmake --build 
/home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins/
 --target check-runtimes --config RelWithDebInfo
  ninja: error: 
'/home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/lib/libgtest.a',
 needed by 
'compiler-rt/lib/asan/tests/ASAN_INST_TEST_OBJECTS.gtest-all.cc.x86_64-calls.o',
 missing and no known rule to make it
  FAILED: runtimes/CMakeFiles/check-runtimes 
  cd 
/home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins
 && /usr/bin/cmake --build 
/home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins/
 --target check-runtimes --config RelWithDebInfo

I've add gtest_main and gtest to  CLANG_BOOTSTRAP_TARGETS as a guess, because 
that's where check-all is defined:

   # Expose stage2 targets through the stage1 build configuration.
   set(CLANG_BOOTSTRAP_TARGETS
  +  gtest_main
  +  gtest
 check-all
 check-llvm
 check-clang
 llvm-config
 test-suite
 test-depends
 llvm-test-depends
 clang-test-depends
 distribution
 install-distribution

My guess is likely wrong, what do you advise?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62279/new/

https://reviews.llvm.org/D62279



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62279: Use LTO capable linker

2019-05-23 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

> Are you still having that issue after rL361436 
> ? That should have resolved that problem. 
> The issue isn't that gtest is missing from the bootstrap, but rather that it 
> was missing from the dependencies for the runtime libraries.

Yes, that patch was/is in my master when it failed above 
:

  $ git log -1 -p ed0036796164b3a2a93be8e2707984f57ba94e24
  commit ed0036796164b3a2a93be8e2707984f57ba94e24
  Author: Chris Bieneman 
  Date:   Wed May 22 21:42:06 2019 +
  
  [Runtimes] If LLVM_INCLUDE_TESTS=On depend on gtest
  
  Summary: If we are building the tests for the runtimes we should make 
them depend on gtest so that gtest is built and ready before we run any of the 
check-* targets.
  
  Reviewers: phosek, compnerd
  
  Reviewed By: compnerd
  
  Subscribers: mgorny, winksaville, llvm-commits
  
  Tags: #llvm
  
  Differential Revision: https://reviews.llvm.org/D62269
  
  llvm-svn: 361436
  
  diff --git a/llvm/runtimes/CMakeLists.txt b/llvm/runtimes/CMakeLists.txt
  index 7bbf0cf26a5..285e1fcae1d 100644
  --- a/llvm/runtimes/CMakeLists.txt
  +++ b/llvm/runtimes/CMakeLists.txt
  @@ -553,6 +553,8 @@ else() # if this is included from LLVM's CMake
 obj2yaml
 sancov
 sanstats
  +  gtest_main
  +  gtest
   )
 foreach(target ${test_targets} ${SUB_CHECK_TARGETS})
   add_dependencies(${target} ${RUNTIMES_TEST_DEPENDS})

My master is at 74eb76f6 
:

  wink@wink-desktop:~/prgs/llvm/llvm-project 
(Use-LTO-capable-linker-and-add-libcxxabi)
  $ git log -1 master
  commit 74eb76f6c31e13551269f711cfccceca92b45783 (upstream/master, 
origin/master, origin/HEAD, master)
  Author: Alex Langford 
  Date:   Wed May 22 23:01:18 2019 +
  
  [Target] Protect Processes' language runtimes map with a mutex
  
  Summary:
  From what I understand, it's possible for multiple threads to request
  a specific language runtime (e.g. CPPLanguageRuntime). This leads to a 
data
  race.
  
  Reviewers: jingham, JDevlieghere, compnerd, clayborg
  
  Differential Revision: https://reviews.llvm.org/D62169
  
  llvm-svn: 361442

On top of master I have two commits to add lld, libcxxabi, gtest_main and gtest:

  $ git log -2 -p
  commit b6b78d5b1d55b7643634ded9412c42dd52782e37 (HEAD -> 
Use-LTO-capable-linker-and-add-libcxxabi)
  Author: Wink Saville 
  Date:   Thu May 23 08:14:44 2019 -0700
  
  Add gtest_main and gtest
  
  See if this fixes check all
  
  diff --git a/clang/cmake/caches/DistributionExample.cmake 
b/clang/cmake/caches/DistributionExample.cmake
  index 50fcc09cf07..fd525b8f4ce 100644
  --- a/clang/cmake/caches/DistributionExample.cmake
  +++ b/clang/cmake/caches/DistributionExample.cmake
  @@ -24,6 +24,8 @@ endif()
   
   # Expose stage2 targets through the stage1 build configuration.
   set(CLANG_BOOTSTRAP_TARGETS
  +  gtest_main
  +  gtest
 check-all
 check-llvm
 check-clang
  
  commit b99e88f595fd3e27e68c18d95f88552cb25aea43 
(origin/Use-LTO-capable-linker-and-add-libcxxabi, origin/Use-LTO-capable-linker)
  Author: Wink Saville 
  Date:   Wed May 22 16:23:47 2019 -0700
  
  Use LTO capable linker and add libcxxabi
  
  In DistributionExample.cmake be sure we use a LTO
  capable linker, the easiest to choose is lld.
  
  Reviewers: beanz
  
  Subscribers: mgorny, mehdi_amini, inglorion, dexonsmith, cfe-commits
  
  Tags: #clang
  
  Differential Revision: https://reviews.llvm.org/D62279
  
  diff --git a/clang/cmake/caches/DistributionExample-stage2.cmake 
b/clang/cmake/caches/DistributionExample-stage2.cmake
  index f4d5d92d1d1..99d5dc0fd2f 100644
  --- a/clang/cmake/caches/DistributionExample-stage2.cmake
  +++ b/clang/cmake/caches/DistributionExample-stage2.cmake
  @@ -2,7 +2,7 @@
   # bootstrap build.
   
   set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
  -set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
  +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
   
   set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
   
  diff --git a/clang/cmake/caches/DistributionExample.cmake 
b/clang/cmake/caches/DistributionExample.cmake
  index 35493edd17f..50fcc09cf07 100644
  --- a/clang/cmake/caches/DistributionExample.cmake
  +++ b/clang/cmake/caches/DistributionExample.cmake
  @@ -2,7 +2,7 @@
   
   #Enable LLVM projects and runtimes
   set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
  -set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
  +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
   
   # Only build the native target in stage1 since it is a throwaway buil

[PATCH] D62279: Use LTO capable linker

2019-05-23 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

In D62279#1514596 , @beanz wrote:

> @winksaville I've figured out how to resolve the `gtest` issue, but 
> unfortunately that isn't good enough to get the `check-runtimes` target 
> working. A change went in back in February (rL353601 
> ), which breaks running compiler-rt's 
> tests when building a distribution in non-trivial ways, which will 
> unfortunately be difficult to resolve.
>
> I will land the `gtest` fix sometime today, and I'm going to start working 
> toward getting the larger issue resolved, although that is going to take some 
> time.

@beanz, glad we're making progress!

One other thing, my next goal, after we can successfully build and test the 
`DistributionExample`,
is to make `DistributionExample_shared`.  I envision this creating `clang` that 
is dynamically linked
to `libclang_shared.so` and `libLLVM.so` and also provide the corresponding 
static libraries. Doing
this should provide Evangelos Foutras, whose is the maintainer of the llvm 
packages at Arch Linux,
an "easier" path to creating llvm Arch Linux packages that don't use 
BUILD_SHARED_LIBS.

Is this a reasonable goal and could `DistrubutionExample_shared` be added along 
side `DistributionExample`?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62279/new/

https://reviews.llvm.org/D62279

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62279: Use LTO capable linker

2019-05-24 Thread Wink Saville via Phabricator via cfe-commits

winksaville updated this revision to Diff 201288.
winksaville added a comment.

Added libcxxabi and rebased


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62279/new/

https://reviews.llvm.org/D62279

Files:
  clang/cmake/caches/DistributionExample-stage2.cmake
  clang/cmake/caches/DistributionExample.cmake


Index: clang/cmake/caches/DistributionExample.cmake
===
--- clang/cmake/caches/DistributionExample.cmake
+++ clang/cmake/caches/DistributionExample.cmake
@@ -2,7 +2,7 @@
 
 #Enable LLVM projects and runtimes
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
 
 # Only build the native target in stage1 since it is a throwaway build.
 set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
@@ -17,6 +17,11 @@
 # the proper LTO library dependencies can be connected.
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
+if (NOT APPLE)
+  # Since LLVM_ENABLE_LTO is ON we need a LTO capable linker
+  set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
+
 # Expose stage2 targets through the stage1 build configuration.
 set(CLANG_BOOTSTRAP_TARGETS
   check-all
Index: clang/cmake/caches/DistributionExample-stage2.cmake
===
--- clang/cmake/caches/DistributionExample-stage2.cmake
+++ clang/cmake/caches/DistributionExample-stage2.cmake
@@ -2,7 +2,7 @@
 # bootstrap build.
 
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
 
 set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 


Index: clang/cmake/caches/DistributionExample.cmake
===
--- clang/cmake/caches/DistributionExample.cmake
+++ clang/cmake/caches/DistributionExample.cmake
@@ -2,7 +2,7 @@
 
 #Enable LLVM projects and runtimes
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
 
 # Only build the native target in stage1 since it is a throwaway build.
 set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
@@ -17,6 +17,11 @@
 # the proper LTO library dependencies can be connected.
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
+if (NOT APPLE)
+  # Since LLVM_ENABLE_LTO is ON we need a LTO capable linker
+  set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
+
 # Expose stage2 targets through the stage1 build configuration.
 set(CLANG_BOOTSTRAP_TARGETS
   check-all
Index: clang/cmake/caches/DistributionExample-stage2.cmake
===
--- clang/cmake/caches/DistributionExample-stage2.cmake
+++ clang/cmake/caches/DistributionExample-stage2.cmake
@@ -2,7 +2,7 @@
 # bootstrap build.
 
 set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
 
 set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62279: Use LTO capable linker

2019-05-24 Thread Wink Saville via Phabricator via cfe-commits

winksaville added a comment.

So this compiles and as such improves on what we currently have and as such I 
think it should be merged,
although there maybe other solutions. It still fails `ninja stage2-check-all` 
with the gtest problem which
@beanz is working on resolving.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62279/new/

https://reviews.llvm.org/D62279



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

2019-05-25 Thread Wink Saville via Phabricator via cfe-commits

winksaville abandoned this revision.
winksaville added a comment.

Rather than creating LLVMgold.so as this change does, @beanz suggested we use a 
known LTO capable linker, `lld`.  See D62279 ..


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62215/new/

https://reviews.llvm.org/D62215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61804: Support building shared and static libraries simultaneously

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D61909: Add Clang shared library with C++ exports

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

[PATCH] D62279: Use LTO capable linker

[PATCH] D62279: Use LTO capable linker

[PATCH] D62279: Use LTO capable linker

[PATCH] D62279: Use LTO capable linker

[PATCH] D62279: Use LTO capable linker

[PATCH] D62279: Use LTO capable linker

[PATCH] D62279: Use LTO capable linker

[PATCH] D62215: Fixes to distribution example for X86_64 Arch Linux

32 matches

Site Navigation

Mail list logo

Footer information