rpms/llvm
8
0
Fork 0
mirror of https://src.fedoraproject.org/rpms/llvm.git synced 2024-11-24 09:32:42 +00:00
Code Issues 5 Projects Releases Packages Wiki Activity Actions
llvm/0001-18-Always-build-shared-libs-for-LLD.patch

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

29 lines
953 B
Diff
Raw Permalink Normal View History

Patch numbering We've established the habit of numbering patches the following way: 0-499: All patches that are unconditionally applied 500-1000: Patches applied under certain conditions (e.g. only on RHEL8) 1500-1599: Patches for LLVM 15 1600-1699: Patches for LLVM 16 1700-1799: Patches for LLVM 17 ... 2000-2099: Patches for LLVM 20 The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow us to "deprecate" a patch instead of deleting it right away. Suppose llvm upstream in git is at version 20 and there's a patch living in some PR that has not been merged yet. You can copy that patch and put it in a line like: Patch2011: upstream.patch As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed. There's no need for you to remove the "Patch2011:" line. In fact, we encourage you to not remove it for some time. For compat libraries and compat packages we might still need this patch and so we're applying it automatically for you in those situations. Remember that a compat library is always at least one major version behind the latest packaged LLVM version. I've restored a patch for an older version of LLVM: We needed to move the `0001-Always-build-shared-libs-for-LLD.patch` from the `0-499` range to the `19xx` (current release) and `20xx` (snapshots) range. In addition the old version of the patch was restored with the following command and added to the `18xx` range: ``` $ git show 0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch > 0001-18-Always-build-shared-libs-for-LLD.patch ``` This was needed because the `bundle_compat_lib` (RHEL only) build condition needs the old version of the patch.
2024-10-30 10:28:03 +00:00
From b1c60d7fa322a2d208556087df9e7ef94bfbffb8 Mon Sep 17 00:00:00 2001
Always build shared libs for LLD We don't want to enable BUILD_SHARED_LIBS for the whole build, but we do want to build lld libraries.
2024-05-06 22:50:03 +00:00
From: Nikita Popov <npopov@redhat.com>
Date: Wed, 8 May 2024 12:30:36 +0900
Subject: [PATCH] Always build shared libs for LLD
We don't want to enable BUILD_SHARED_LIBS for the whole build,
but we do want to build lld libraries.
---
lld/cmake/modules/AddLLD.cmake | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lld/cmake/modules/AddLLD.cmake b/lld/cmake/modules/AddLLD.cmake
Patch numbering We've established the habit of numbering patches the following way: 0-499: All patches that are unconditionally applied 500-1000: Patches applied under certain conditions (e.g. only on RHEL8) 1500-1599: Patches for LLVM 15 1600-1699: Patches for LLVM 16 1700-1799: Patches for LLVM 17 ... 2000-2099: Patches for LLVM 20 The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow us to "deprecate" a patch instead of deleting it right away. Suppose llvm upstream in git is at version 20 and there's a patch living in some PR that has not been merged yet. You can copy that patch and put it in a line like: Patch2011: upstream.patch As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed. There's no need for you to remove the "Patch2011:" line. In fact, we encourage you to not remove it for some time. For compat libraries and compat packages we might still need this patch and so we're applying it automatically for you in those situations. Remember that a compat library is always at least one major version behind the latest packaged LLVM version. I've restored a patch for an older version of LLVM: We needed to move the `0001-Always-build-shared-libs-for-LLD.patch` from the `0-499` range to the `19xx` (current release) and `20xx` (snapshots) range. In addition the old version of the patch was restored with the following command and added to the `18xx` range: ``` $ git show 0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch > 0001-18-Always-build-shared-libs-for-LLD.patch ``` This was needed because the `bundle_compat_lib` (RHEL only) build condition needs the old version of the patch.
2024-10-30 10:28:03 +00:00
index 2ee066b41535..270c03f096ac 100644
Always build shared libs for LLD We don't want to enable BUILD_SHARED_LIBS for the whole build, but we do want to build lld libraries.
2024-05-06 22:50:03 +00:00
--- a/lld/cmake/modules/AddLLD.cmake
+++ b/lld/cmake/modules/AddLLD.cmake
@@ -7,9 +7,8 @@ macro(add_lld_library name)
""
""
${ARGN})
- if(ARG_SHARED)
- set(ARG_ENABLE_SHARED SHARED)
- endif()
+ # Always build shared libs for LLD.
+ set(ARG_ENABLE_SHARED SHARED)
llvm_add_library(${name} ${ARG_ENABLE_SHARED} ${ARG_UNPARSED_ARGUMENTS})
Patch numbering We've established the habit of numbering patches the following way: 0-499: All patches that are unconditionally applied 500-1000: Patches applied under certain conditions (e.g. only on RHEL8) 1500-1599: Patches for LLVM 15 1600-1699: Patches for LLVM 16 1700-1799: Patches for LLVM 17 ... 2000-2099: Patches for LLVM 20 The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow us to "deprecate" a patch instead of deleting it right away. Suppose llvm upstream in git is at version 20 and there's a patch living in some PR that has not been merged yet. You can copy that patch and put it in a line like: Patch2011: upstream.patch As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed. There's no need for you to remove the "Patch2011:" line. In fact, we encourage you to not remove it for some time. For compat libraries and compat packages we might still need this patch and so we're applying it automatically for you in those situations. Remember that a compat library is always at least one major version behind the latest packaged LLVM version. I've restored a patch for an older version of LLVM: We needed to move the `0001-Always-build-shared-libs-for-LLD.patch` from the `0-499` range to the `19xx` (current release) and `20xx` (snapshots) range. In addition the old version of the patch was restored with the following command and added to the `18xx` range: ``` $ git show 0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch > 0001-18-Always-build-shared-libs-for-LLD.patch ``` This was needed because the `bundle_compat_lib` (RHEL only) build condition needs the old version of the patch.
2024-10-30 10:28:03 +00:00
set_target_properties(${name} PROPERTIES FOLDER "lld libraries")
Always build shared libs for LLD We don't want to enable BUILD_SHARED_LIBS for the whole build, but we do want to build lld libraries.
2024-05-06 22:50:03 +00:00
--
Patch numbering We've established the habit of numbering patches the following way: 0-499: All patches that are unconditionally applied 500-1000: Patches applied under certain conditions (e.g. only on RHEL8) 1500-1599: Patches for LLVM 15 1600-1699: Patches for LLVM 16 1700-1799: Patches for LLVM 17 ... 2000-2099: Patches for LLVM 20 The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow us to "deprecate" a patch instead of deleting it right away. Suppose llvm upstream in git is at version 20 and there's a patch living in some PR that has not been merged yet. You can copy that patch and put it in a line like: Patch2011: upstream.patch As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed. There's no need for you to remove the "Patch2011:" line. In fact, we encourage you to not remove it for some time. For compat libraries and compat packages we might still need this patch and so we're applying it automatically for you in those situations. Remember that a compat library is always at least one major version behind the latest packaged LLVM version. I've restored a patch for an older version of LLVM: We needed to move the `0001-Always-build-shared-libs-for-LLD.patch` from the `0-499` range to the `19xx` (current release) and `20xx` (snapshots) range. In addition the old version of the patch was restored with the following command and added to the `18xx` range: ``` $ git show 0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch > 0001-18-Always-build-shared-libs-for-LLD.patch ``` This was needed because the `bundle_compat_lib` (RHEL only) build condition needs the old version of the patch.
2024-10-30 10:28:03 +00:00
2.44.0
Reference in a new issue Copy permalink