Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
Makes sense, thanks. Seems like INTERFACE is the way to go then. From: on behalf of Chris Bieneman Date: Tuesday, July 16, 2019 at 10:32 AM To: Shoaib Meenai Cc: Alex Bradbury , cfe-commits Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies I get that CMake does something different for PRIVATE, but the way we use CMake in LLVM we really can't make a private distinction reasonable. Because we don't sub-divide our headers per library, we don't support per-dependency include paths in LLVM or Clang's libraries. This behavior also assumes you are using `target_include_directories` to assign PRIVATE | PUBLIC | INTERFACE to include directories, which we don't generally do in LLVM (a quick grep showed one place in LLVM code excluding our google benchmark drop). We do generally use `include_directories` which always treats things as PRIVATE, so they don't cascade to dependencies. -Chris On Jul 12, 2019, at 7:16 PM, Shoaib Meenai mailto:smee...@fb.com>> wrote: I struggled for a while thinking why PRIVATE might be useful in a target_link_libraries call for a shared library, and then I found https://cmake.org/pipermail/cmake/2016-May/063400.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_pipermail_cmake_2016-2DMay_063400.html=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=NhVmexDDl4XvCBWPO8Gl6v5pSPl5UAQ-g0gZ9RQeJl0=GzTNsMdGWEe8rJMKHfM017MWdw-WBJyV493ARE6B8YE=>. The relevant bit is: If you were paying careful attention, you would have noticed that when A links in B as PRIVATE, the include directories of B never propagate to something linking to A, but if A is a static library, then the *linking* of B behaves as though the relationship was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the *linking*, not to the other dependencies (compiler options/flags and include search paths). So PRIVATE/INTERFACE/PUBLIC doesn’t make any difference as far as the actual linking goes, but it does affect propagation of other options, and I think it’s valid to want to have a PRIVATE dependency for a static library. From: mailto:cbiene...@apple.com>> on behalf of Chris Bieneman mailto:be...@apple.com>> Date: Friday, July 12, 2019 at 9:08 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` linkage for a static archive is silly, and shouldn't be possible. All link dependencies for static archives are really `INTERFACE` dependencies, and it looks like CMake is doing something kinda silly instead of producing a reasonable error or warning like it probably should do. For context, `PRIVATE` linkage in the context of that change would mean DirectoryWalker links something, but things that link DirectoryWalker don't. That just isn't possible with static archives, so they become interface dependencies (and CMake seems to insert a generator expression to make that work). In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and `INTERFACE` for static, which does the right thing. Unless there is a better reason than a new patch coming in, I think the right fix is to revert this back and expect the new patch to correct its linkage behavior. -Chris On Jul 12, 2019, at 8:53 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: See https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670=DwMFAg=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok=>. More generally it would appear for any static library with a PRIVATE dependency though. I guess an alternative would be to use the LINK_LIBRARIES property (which should be free of generator expressions, I believe) to propagate dependencies instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies on a static library definitely seems more valuable than supporting INTERFACE dependencies.) From: mailto:cbiene...@apple.com>> on behalf of Chris Bieneman mailto:be...@apple.com>> Date: Friday, July 12, 2019 at 8:49 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies One of the benefits of the object library approach for generating the clang dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke it, so I was trying
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
I get that CMake does something different for PRIVATE, but the way we use CMake in LLVM we really can't make a private distinction reasonable. Because we don't sub-divide our headers per library, we don't support per-dependency include paths in LLVM or Clang's libraries. This behavior also assumes you are using `target_include_directories` to assign PRIVATE | PUBLIC | INTERFACE to include directories, which we don't generally do in LLVM (a quick grep showed one place in LLVM code excluding our google benchmark drop). We do generally use `include_directories` which always treats things as PRIVATE, so they don't cascade to dependencies. -Chris > On Jul 12, 2019, at 7:16 PM, Shoaib Meenai wrote: > > I struggled for a while thinking why PRIVATE might be useful in a > target_link_libraries call for a shared library, and then I found > https://cmake.org/pipermail/cmake/2016-May/063400.html > <https://cmake.org/pipermail/cmake/2016-May/063400.html>. The relevant bit is: > > If you were paying careful attention, you would have noticed that when A > links in B as PRIVATE, the include directories of B never propagate to > something linking to A, but if A is a static library, then the *linking* of > B behaves as though the relationship was PUBLIC. This > PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the > *linking*, not to the other dependencies (compiler options/flags and > include search paths). > > So PRIVATE/INTERFACE/PUBLIC doesn’t make any difference as far as the actual > linking goes, but it does affect propagation of other options, and I think > it’s valid to want to have a PRIVATE dependency for a static library. > > From: on behalf of Chris Bieneman > Date: Friday, July 12, 2019 at 9:08 AM > To: Shoaib Meenai > Cc: Alex Bradbury , cfe-commits > Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > Ah! I see what is going on here. This is kinda a silliness of CMake. > `PRIVATE` linkage for a static archive is silly, and shouldn't be possible. > All link dependencies for static archives are really `INTERFACE` > dependencies, and it looks like CMake is doing something kinda silly instead > of producing a reasonable error or warning like it probably should do. > > For context, `PRIVATE` linkage in the context of that change would mean > DirectoryWalker links something, but things that link DirectoryWalker don't. > That just isn't possible with static archives, so they become interface > dependencies (and CMake seems to insert a generator expression to make that > work). > > In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, > and `INTERFACE` for static, which does the right thing. > > Unless there is a better reason than a new patch coming in, I think the right > fix is to revert this back and expect the new patch to correct its linkage > behavior. > > -Chris > > > On Jul 12, 2019, at 8:53 AM, Shoaib Meenai <mailto:smee...@fb.com>> wrote: > > See https://reviews.llvm.org/D58418#1577670 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670=DwMFAg=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok=>. > More generally it would appear for any static library with a PRIVATE > dependency though. > > I guess an alternative would be to use the LINK_LIBRARIES property (which > should be free of generator expressions, I believe) to propagate dependencies > instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set > an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies > on a static library definitely seems more valuable than supporting INTERFACE > dependencies.) > > From: mailto:cbiene...@apple.com>> on behalf of Chris > Bieneman mailto:be...@apple.com>> > Date: Friday, July 12, 2019 at 8:49 AM > To: Shoaib Meenai mailto:smee...@fb.com>> > Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits > mailto:cfe-commits@lists.llvm.org>> > Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > One of the benefits of the object library approach for generating the clang > dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues > with libLLVM where people using BUILD_SHARED_LIBS would make changes that > broke it, so I was trying to make the clang dylib in a way that it could > always be enabled. > > Do we know where the nested generator expression was coming from? > > -Chris > > > > On Jul 12, 2019, at 8:32 AM, Shoaib Meenai <mailto:smee...@fb.com>> wrote:
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
I struggled for a while thinking why PRIVATE might be useful in a target_link_libraries call for a shared library, and then I found https://cmake.org/pipermail/cmake/2016-May/063400.html. The relevant bit is: If you were paying careful attention, you would have noticed that when A links in B as PRIVATE, the include directories of B never propagate to something linking to A, but if A is a static library, then the *linking* of B behaves as though the relationship was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the *linking*, not to the other dependencies (compiler options/flags and include search paths). So PRIVATE/INTERFACE/PUBLIC doesn’t make any difference as far as the actual linking goes, but it does affect propagation of other options, and I think it’s valid to want to have a PRIVATE dependency for a static library. From: on behalf of Chris Bieneman Date: Friday, July 12, 2019 at 9:08 AM To: Shoaib Meenai Cc: Alex Bradbury , cfe-commits Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` linkage for a static archive is silly, and shouldn't be possible. All link dependencies for static archives are really `INTERFACE` dependencies, and it looks like CMake is doing something kinda silly instead of producing a reasonable error or warning like it probably should do. For context, `PRIVATE` linkage in the context of that change would mean DirectoryWalker links something, but things that link DirectoryWalker don't. That just isn't possible with static archives, so they become interface dependencies (and CMake seems to insert a generator expression to make that work). In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and `INTERFACE` for static, which does the right thing. Unless there is a better reason than a new patch coming in, I think the right fix is to revert this back and expect the new patch to correct its linkage behavior. -Chris On Jul 12, 2019, at 8:53 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: See https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670=DwMFAg=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok=>. More generally it would appear for any static library with a PRIVATE dependency though. I guess an alternative would be to use the LINK_LIBRARIES property (which should be free of generator expressions, I believe) to propagate dependencies instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies on a static library definitely seems more valuable than supporting INTERFACE dependencies.) From: mailto:cbiene...@apple.com>> on behalf of Chris Bieneman mailto:be...@apple.com>> Date: Friday, July 12, 2019 at 8:49 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies One of the benefits of the object library approach for generating the clang dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke it, so I was trying to make the clang dylib in a way that it could always be enabled. Do we know where the nested generator expression was coming from? -Chris On Jul 12, 2019, at 8:32 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: Oops, sorry about the breakage. Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? Should we disable building the latter if the former is set? From: Alex Bradbury mailto:a...@lowrisc.org>> Date: Friday, July 12, 2019 at 2:02 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: Author: smeenai Date: Thu Jul 11 14:20:38 2019 New Revision: 365825 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= Log: [clang-shlib] Fix clang-shlib for PRIVATE dependencies Any static library with a PRIVATE dependency ends up with a $ generator expression in its INTERFACE_LINK_LIBRARIES, which won't be evaluated by the $, so we end up with an unevaluated generator expression in the generated build file and Ninja chokes on the dollar
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
Reverted in r365922. From: on behalf of Chris Bieneman Date: Friday, July 12, 2019 at 9:08 AM To: Shoaib Meenai Cc: Alex Bradbury , cfe-commits Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` linkage for a static archive is silly, and shouldn't be possible. All link dependencies for static archives are really `INTERFACE` dependencies, and it looks like CMake is doing something kinda silly instead of producing a reasonable error or warning like it probably should do. For context, `PRIVATE` linkage in the context of that change would mean DirectoryWalker links something, but things that link DirectoryWalker don't. That just isn't possible with static archives, so they become interface dependencies (and CMake seems to insert a generator expression to make that work). In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and `INTERFACE` for static, which does the right thing. Unless there is a better reason than a new patch coming in, I think the right fix is to revert this back and expect the new patch to correct its linkage behavior. -Chris On Jul 12, 2019, at 8:53 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: See https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670=DwMFAg=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok=>. More generally it would appear for any static library with a PRIVATE dependency though. I guess an alternative would be to use the LINK_LIBRARIES property (which should be free of generator expressions, I believe) to propagate dependencies instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies on a static library definitely seems more valuable than supporting INTERFACE dependencies.) From: mailto:cbiene...@apple.com>> on behalf of Chris Bieneman mailto:be...@apple.com>> Date: Friday, July 12, 2019 at 8:49 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies One of the benefits of the object library approach for generating the clang dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke it, so I was trying to make the clang dylib in a way that it could always be enabled. Do we know where the nested generator expression was coming from? -Chris On Jul 12, 2019, at 8:32 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: Oops, sorry about the breakage. Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? Should we disable building the latter if the former is set? From: Alex Bradbury mailto:a...@lowrisc.org>> Date: Friday, July 12, 2019 at 2:02 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: Author: smeenai Date: Thu Jul 11 14:20:38 2019 New Revision: 365825 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= Log: [clang-shlib] Fix clang-shlib for PRIVATE dependencies Any static library with a PRIVATE dependency ends up with a $ generator expression in its INTERFACE_LINK_LIBRARIES, which won't be evaluated by the $, so we end up with an unevaluated generator expression in the generated build file and Ninja chokes on the dollar sign. Just use the static library directly for its dependencies instead of trying to propagate dependencies manually. Differential Revision: https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ= This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at the point of linking lib/libclang_shared.so.9svn with errors like: ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by Attributes.cpp:34 (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule)) ld.
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
Hmm, I thought CMake did something more sensible with PRIVATE/INTERFACE/PUBLIC dependencies on static libraries, but now I’m not so sure… I’m continuing to investigate more, but I’ll revert in the meantime. From: on behalf of Chris Bieneman Date: Friday, July 12, 2019 at 9:08 AM To: Shoaib Meenai Cc: Alex Bradbury , cfe-commits Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` linkage for a static archive is silly, and shouldn't be possible. All link dependencies for static archives are really `INTERFACE` dependencies, and it looks like CMake is doing something kinda silly instead of producing a reasonable error or warning like it probably should do. For context, `PRIVATE` linkage in the context of that change would mean DirectoryWalker links something, but things that link DirectoryWalker don't. That just isn't possible with static archives, so they become interface dependencies (and CMake seems to insert a generator expression to make that work). In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and `INTERFACE` for static, which does the right thing. Unless there is a better reason than a new patch coming in, I think the right fix is to revert this back and expect the new patch to correct its linkage behavior. -Chris On Jul 12, 2019, at 8:53 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: See https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670=DwMFAg=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok=>. More generally it would appear for any static library with a PRIVATE dependency though. I guess an alternative would be to use the LINK_LIBRARIES property (which should be free of generator expressions, I believe) to propagate dependencies instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies on a static library definitely seems more valuable than supporting INTERFACE dependencies.) From: mailto:cbiene...@apple.com>> on behalf of Chris Bieneman mailto:be...@apple.com>> Date: Friday, July 12, 2019 at 8:49 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies One of the benefits of the object library approach for generating the clang dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke it, so I was trying to make the clang dylib in a way that it could always be enabled. Do we know where the nested generator expression was coming from? -Chris On Jul 12, 2019, at 8:32 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: Oops, sorry about the breakage. Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? Should we disable building the latter if the former is set? From: Alex Bradbury mailto:a...@lowrisc.org>> Date: Friday, July 12, 2019 at 2:02 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: Author: smeenai Date: Thu Jul 11 14:20:38 2019 New Revision: 365825 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= Log: [clang-shlib] Fix clang-shlib for PRIVATE dependencies Any static library with a PRIVATE dependency ends up with a $ generator expression in its INTERFACE_LINK_LIBRARIES, which won't be evaluated by the $, so we end up with an unevaluated generator expression in the generated build file and Ninja chokes on the dollar sign. Just use the static library directly for its dependencies instead of trying to propagate dependencies manually. Differential Revision: https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ= This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at the point of linking lib/libclang_shared.so.9svn with errors like: ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by Attributes.cpp:34 (/home/asb/llvm-project/clang/lib/B
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` linkage for a static archive is silly, and shouldn't be possible. All link dependencies for static archives are really `INTERFACE` dependencies, and it looks like CMake is doing something kinda silly instead of producing a reasonable error or warning like it probably should do. For context, `PRIVATE` linkage in the context of that change would mean DirectoryWalker links something, but things that link DirectoryWalker don't. That just isn't possible with static archives, so they become interface dependencies (and CMake seems to insert a generator expression to make that work). In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and `INTERFACE` for static, which does the right thing. Unless there is a better reason than a new patch coming in, I think the right fix is to revert this back and expect the new patch to correct its linkage behavior. -Chris > On Jul 12, 2019, at 8:53 AM, Shoaib Meenai wrote: > > See https://reviews.llvm.org/D58418#1577670 > <https://reviews.llvm.org/D58418#1577670>. More generally it would appear for > any static library with a PRIVATE dependency though. > > I guess an alternative would be to use the LINK_LIBRARIES property (which > should be free of generator expressions, I believe) to propagate dependencies > instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set > an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies > on a static library definitely seems more valuable than supporting INTERFACE > dependencies.) > > From: on behalf of Chris Bieneman > Date: Friday, July 12, 2019 at 8:49 AM > To: Shoaib Meenai > Cc: Alex Bradbury , cfe-commits > Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > One of the benefits of the object library approach for generating the clang > dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues > with libLLVM where people using BUILD_SHARED_LIBS would make changes that > broke it, so I was trying to make the clang dylib in a way that it could > always be enabled. > > Do we know where the nested generator expression was coming from? > > -Chris > > > On Jul 12, 2019, at 8:32 AM, Shoaib Meenai <mailto:smee...@fb.com>> wrote: > > Oops, sorry about the breakage. > > Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? > Should we disable building the latter if the former is set? > > From: Alex Bradbury mailto:a...@lowrisc.org>> > Date: Friday, July 12, 2019 at 2:02 AM > To: Shoaib Meenai mailto:smee...@fb.com>> > Cc: cfe-commits <mailto:cfe-commits@lists.llvm.org>> > Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > > Author: smeenai > Date: Thu Jul 11 14:20:38 2019 > New Revision: 365825 > > URL: > https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk=> > Log: > [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > Any static library with a PRIVATE dependency ends up with a > $ generator expression in its INTERFACE_LINK_LIBRARIES, > which won't be evaluated by the $, so we end up > with an unevaluated generator expression in the generated build file and > Ninja chokes on the dollar sign. Just use the static library directly > for its dependencies instead of trying to propagate dependencies > manually. > > Differential Revision: > https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ=> > > This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at > the point of linking lib/libclang_shared.so.9svn with errors like: > ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char > const*, char co
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
See https://reviews.llvm.org/D58418#1577670. More generally it would appear for any static library with a PRIVATE dependency though. I guess an alternative would be to use the LINK_LIBRARIES property (which should be free of generator expressions, I believe) to propagate dependencies instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies on a static library definitely seems more valuable than supporting INTERFACE dependencies.) From: on behalf of Chris Bieneman Date: Friday, July 12, 2019 at 8:49 AM To: Shoaib Meenai Cc: Alex Bradbury , cfe-commits Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies One of the benefits of the object library approach for generating the clang dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke it, so I was trying to make the clang dylib in a way that it could always be enabled. Do we know where the nested generator expression was coming from? -Chris On Jul 12, 2019, at 8:32 AM, Shoaib Meenai mailto:smee...@fb.com>> wrote: Oops, sorry about the breakage. Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? Should we disable building the latter if the former is set? From: Alex Bradbury mailto:a...@lowrisc.org>> Date: Friday, July 12, 2019 at 2:02 AM To: Shoaib Meenai mailto:smee...@fb.com>> Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: Author: smeenai Date: Thu Jul 11 14:20:38 2019 New Revision: 365825 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= Log: [clang-shlib] Fix clang-shlib for PRIVATE dependencies Any static library with a PRIVATE dependency ends up with a $ generator expression in its INTERFACE_LINK_LIBRARIES, which won't be evaluated by the $, so we end up with an unevaluated generator expression in the generated build file and Ninja chokes on the dollar sign. Just use the static library directly for its dependencies instead of trying to propagate dependencies manually. Differential Revision: https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ= This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at the point of linking lib/libclang_shared.so.9svn with errors like: ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by Attributes.cpp:34 (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule)) ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by TargetCXXABI.h:168 (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft() const) ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by TargetCXXABI.h:149 (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily() const) ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks referenced by Attributes.cpp tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks) ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
One of the benefits of the object library approach for generating the clang dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke it, so I was trying to make the clang dylib in a way that it could always be enabled. Do we know where the nested generator expression was coming from? -Chris > On Jul 12, 2019, at 8:32 AM, Shoaib Meenai wrote: > > Oops, sorry about the breakage. > > Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? > Should we disable building the latter if the former is set? > > From: Alex Bradbury > Date: Friday, July 12, 2019 at 2:02 AM > To: Shoaib Meenai > Cc: cfe-commits > Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > > Author: smeenai > Date: Thu Jul 11 14:20:38 2019 > New Revision: 365825 > > URL: > https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk=> > Log: > [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > Any static library with a PRIVATE dependency ends up with a > $ generator expression in its INTERFACE_LINK_LIBRARIES, > which won't be evaluated by the $, so we end up > with an unevaluated generator expression in the generated build file and > Ninja chokes on the dollar sign. Just use the static library directly > for its dependencies instead of trying to propagate dependencies > manually. > > Differential Revision: > https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ=> > > This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at > the point of linking lib/libclang_shared.so.9svn with errors like: > ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char > const*, char const*, unsigned int) > referenced by Attributes.cpp:34 > (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34) > > tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule)) > > ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char > const*, char const*, unsigned int) > referenced by TargetCXXABI.h:168 > (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168) > > tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft() > const) > > ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char > const*, char const*, unsigned int) > referenced by TargetCXXABI.h:149 > (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149) > > tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily() > const) > > ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks > referenced by Attributes.cpp > > tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks) > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
Oops, sorry about the breakage. Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? Should we disable building the latter if the former is set? From: Alex Bradbury Date: Friday, July 12, 2019 at 2:02 AM To: Shoaib Meenai Cc: cfe-commits Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: Author: smeenai Date: Thu Jul 11 14:20:38 2019 New Revision: 365825 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk= Log: [clang-shlib] Fix clang-shlib for PRIVATE dependencies Any static library with a PRIVATE dependency ends up with a $ generator expression in its INTERFACE_LINK_LIBRARIES, which won't be evaluated by the $, so we end up with an unevaluated generator expression in the generated build file and Ninja chokes on the dollar sign. Just use the static library directly for its dependencies instead of trying to propagate dependencies manually. Differential Revision: https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ= This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at the point of linking lib/libclang_shared.so.9svn with errors like: ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by Attributes.cpp:34 (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule)) ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by TargetCXXABI.h:168 (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft() const) ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) referenced by TargetCXXABI.h:149 (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149) tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily() const) ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks referenced by Attributes.cpp tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks) ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits wrote: > > Author: smeenai > Date: Thu Jul 11 14:20:38 2019 > New Revision: 365825 > > URL: http://llvm.org/viewvc/llvm-project?rev=365825=rev > Log: > [clang-shlib] Fix clang-shlib for PRIVATE dependencies > > Any static library with a PRIVATE dependency ends up with a > $ generator expression in its INTERFACE_LINK_LIBRARIES, > which won't be evaluated by the $, so we end up > with an unevaluated generator expression in the generated build file and > Ninja chokes on the dollar sign. Just use the static library directly > for its dependencies instead of trying to propagate dependencies > manually. > > Differential Revision: https://reviews.llvm.org/D64579 This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at the point of linking lib/libclang_shared.so.9svn with errors like: ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) >>> referenced by Attributes.cpp:34 >>> (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34) >>> >>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule)) ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) >>> referenced by TargetCXXABI.h:168 >>> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168) >>> >>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft() >>> const) ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) >>> referenced by TargetCXXABI.h:149 >>> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149) >>> >>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily() >>> const) ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks >>> referenced by Attributes.cpp >>> >>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks) ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825
URL: http://llvm.org/viewvc/llvm-project?rev=365825=rev
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies
Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.
Differential Revision: https://reviews.llvm.org/D64579
Modified:
cfe/trunk/tools/clang-shlib/CMakeLists.txt
Modified: cfe/trunk/tools/clang-shlib/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-shlib/CMakeLists.txt?rev=365825=365824=365825=diff
==
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt Thu Jul 11 14:20:38 2019
@@ -7,8 +7,35 @@ get_property(clang_libs GLOBAL PROPERTY
foreach (lib ${clang_libs})
list(APPEND _OBJECTS $)
- list(APPEND _DEPS $)
- list(APPEND _DEPS $)
+ # Use the static library for its dependencies. The objects that constitute
the
+ # static library will appear on the link line before the library, so it'll
+ # just be ignored, but the dependencies of the library will still be linked
+ # correctly.
+ #
+ # We could propagate the dependencies manually using the library's
+ # INTERFACE_LINK_LIBRARIES property, but that will contain $
+ # generator expressions if a static library has a private dependency, so we
+ # can't use a $ generator expression to get the property
+ # (since it wouldn't evaluate any generator expressions inside the property).
+ # We could use get_property and do string manipulation to manually evaluate
+ # the $, but that would miss any dependencies added after we
+ # evaluate the get_property. We could also use the LINK_LIBRARIES property
+ # instead, which should be free of any generator expressions, but that's
+ # technically incorrect (it'd most likely work fine in practice, but still).
+ #
+ # Another alternative would be to use --whole-archive or equivalent instead
of
+ # using the object library at all. However, CMake reorders static libraries
on
+ # the link line so that a library appears after all its dependents, which can
+ # reorder static libraries out of their --whole-archive --no-whole-archive
+ # sandwich. It's really hard to avoid that reordering while still propagating
+ # dependencies, which defeats the whole point.
+ #
+ # The ideal solution here is to bump our minimum CMake requirement to 3.12,
+ # which adds support for dependencies on object libraries. Until then,
linking
+ # both the object and the static libraries seems like the least bad solution.
+ #
+ # TODO: Rework this when we bump our minimum CMake version to 3.12 or newer.
+ list(APPEND _DEPS ${lib})
endforeach ()
add_clang_library(clang_shared
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
