https://bugzilla.redhat.com/show_bug.cgi?id=1933988 Antonio T. sagitter <trpost@xxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(trpost@rocketmail | |.com) | --- Comment #12 from Antonio T. sagitter <trpost@xxxxxxxxxxxxxx> --- (In reply to code from comment #10) > Okay, I looked into it further, and it seems COPASI already implements > option “1.” Look at > https://github.com/copasi/COPASI/blob/ > 0dddbe0d84e4248270ff65d06ea2b3997cc4f3b9/copasi/math/CJitCompiler.cpp to see > how all JIT is disabled when a runtime CPU feature test shows SSE4 is not > available. So from a policy perspective, everything is fine. > > You do need a quick feature test in the spec file to avoid running the tests > on build hosts without SSE4.2 (like mine!). Your %check could look like this: > > if grep -E '\bsse4_2\b' /proc/cpuinfo >/dev/null > then > %ctest -- -VV > else > echo 'No SSE4.2 support on build host; skipping tests' 1>&2 > fi > > Or, if it’s more to your liking, use the other package you have under review: > > BuildRequires: google-cpu_features > BuildRequires: jq > > if list_cpu_features -j | jq -e '.flags | index("sse4_2")' >/dev/null > then > %ctest -- -VV > else > echo 'No SSE4.2 support on build host; skipping tests' 1>&2 > fi > > Personally, I would favor also adding a comment near the ExcludeArch > mentioning the SSE4.2 requirement and linking > https://pagure.io/packaging-committee/issue/1044, and perhaps mentioning the > SSE4.2 requirement in the package description as well. > > ----- > > Based on > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_listing_shared_library_files, you should write the shared library globs as > > %{_libdir}/libCodeGen.so.0 > %{_libdir}/libNativeJIT.so.0 > > instead of > > %{_libdir}/libCodeGen.so.* > %{_libdir}/libNativeJIT.so.* > > ----- > > I’m not a big fan of claiming something as vague and generic as > /usr/include/Temporary, but I’m not sure there’s a reasonable way to avoid > it. > > ----- > > I’m going to go ahead and claim this for review. Could you post an updated > version that skips the tests when necessary and adjusts the shared library > globs, and I’ll review that? Thanks. Spec URL: https://sagitter.fedorapeople.org/nativejit/nativejit.spec SRPM URL: https://sagitter.fedorapeople.org/nativejit/nativejit-0.0-2.fc33.src.rpm Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=63078250 (In reply to code from comment #11) > > And this: > > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::rip > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::RegisterBase::c_names > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::rbp > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::RegisterBase::c_sizes > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::rsp > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::FunctionBuffer::EndFunctionBodyGeneration(NativeJIT:: > FunctionSpecification const&) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::X64CodeGenerator::CodePrinter::PrintBytes(unsigned int, unsigned > int) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::CodeBuffer::AllocateLabel() > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::X64CodeGenerator::CodePrinter::CodePrinter(NativeJIT:: > X64CodeGenerator&) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::X64CodeGenerator::IsDiagnosticsStreamAvailable() const > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::FunctionBuffer::BeginFunctionBodyGeneration() > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::LogThrowImpl(char const*, char const*, unsigned int, char const*, > char const*, ...) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::IosMiniStateRestorer::~IosMiniStateRestorer() > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::CodeBuffer::Emit32(unsigned int) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::IosMiniStateRestorer::IosMiniStateRestorer(std::basic_ios<char, > std::char_traits<char> >&) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::X64CodeGenerator::GetDiagnosticsStream() const > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::Label::Label() > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::X64CodeGenerator::OpCodeName(NativeJIT::OpCode) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::CodeBuffer::Emit8(unsigned char) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::FunctionBuffer::GetEntryPoint() const > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::X64CodeGenerator::CodePrinter::GetPointerName(unsigned int) > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::CodeBuffer::CurrentPosition() const > nativejit.x86_64: W: undefined-non-weak-symbol /usr/lib64/libNativeJIT.so.0 > NativeJIT::FunctionSpecification::FunctionSpecification(Allocators:: > IAllocator&, int, unsigned int, unsigned int, unsigned int, > NativeJIT::FunctionSpecification::BaseRegisterType, std::basic_ostream<char, > std::char_traits<char> >*) > > I haven’t had time to try to understand why that is happening. I already seen them and asked to upstream maintainer: https://github.com/copasi/copasi-dependencies/issues/7 -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
