Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Apparently, something went wrong with the bug description. I apologies for the double comment. The following line modifies the CMake export target for LLVM loadable modules from LLVMExports to LLVMStaticExports: https://src.fedoraproject.org/rpms/llvm/blob/f31/f/0001-CMake-Split-static-library-exports-into-their-own-ex.patch#_22 This does not appear to be the intended behavior, since loadable modules are shared libraries. Please, consider changing it to: if(ARG_SHARED OR ARG_MODULE)
Do you have an example of what fails due to this change?
When building a pass out-of-tree, one possible way of putting an additional target in the same export set as the pass is to add it to LLVMExports. This allows to easily put the pass and the target in the same namespace. However, this is not possible if the pass is exported in LLVMStaticExports, modifying the behavior of vanilla LLVM. This makes it difficult to compile the pass and the additional component on Fedora without modifying the build system.
Do you have example cmake code that does this?
I created a simple out-of-tree LLVM analysis project that is affected by the issue I was describing: https://github.com/EliaGeretto/TestAnalysis When you try to install this CMake project using "make install", the behavior will differ between the Fedora build and an unpatched build of LLVM: - If you are using an unpatched build of LLVM, the targets exported in "<prefix>/lib64/cmake/TestAnalysis/TestAnalysisConfig.cmake" are "TestAnalysis::LLVMTestAnalysis" and "TestAnalysis::Headers". - If you are using the Fedora package, only "TestAnalysis::Headers" will be present in "<prefix>/lib64/cmake/TestAnalysis/TestAnalysisConfig.cmake". This is due to the fact that the patch I linked above is, apparently, not taking into account that add_llvm_library may be called with MODULE as an argument when building out-of-tree passes. Checking only for ARG_SHARED puts the targets generated with add_llvm_library(... MODULE ...) in LLVMStaticExports, modifying the original behavior. This, in turn, breaks code that relies on that specific behavior. In order to restore the original behavior, the only modification needed is to use: if(ARG_SHARED OR ARG_MODULE) instead of: if (ARG_SHARED) at line: https://src.fedoraproject.org/rpms/llvm/blob/f31/f/0001-CMake-Split-static-library-exports-into-their-own-ex.patch#_22 Since add_llvm_library(... MODULE ...) is used inside LLVM only a few times and always for loadable plugins such as "LLVMHello.so", used mostly for testing, making that change should not break anything.
Can we add this test case to the Fedora test suite?
If you need my permission for copyright reasons, you have it. Does this imply something else on my side or will you just create a copy of the repository I posted? Do you need me to add a license there?
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.