Files could not be expanded: conflict in file python311.patch

virtualbox

Edit Package virtualbox
No description set
Refresh
Refresh
Source Files

Sources could not be expanded: conflict in file python311.patch

Show unmerged sources

Comments 5

z's avatar

Virtualbox 7.1.0 Cannot install extension pack.

VBoxManage: error: Failed to install "/home/username/Downloads/virtualbox/Oracle_VirtualBox_Extension_Pack-7.1.0.vbox-extpack" VBoxManage: error: Failed to load the main module ('/usr/lib/virtualbox/ExtensionPacks/Oracle_VirtualBox_Extension_Pack/linux.amd64/VBoxPuelMain.so'): VERR_FILE_NOT_FOUND - /usr/lib/virtualbox/ExtensionPacks/Oracle_VirtualBox_Extension_Pack/linux.amd64/VBoxPuelMain.so: undefined symbol: _ZN21RTCRestBinaryResponse19setConsumerCallbackEPFiPS_PKvmjmmEPv VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 2099 of file VBoxManageMisc.cpp


Jan Engelhardt's avatar

The problem here is that the extension pack was built with -std=c++14 (or earlier), but virtualbox was built with -std=c++17 (or something later), which is a requirement because of the use of the <filesystem> header. As per https://en.cppreference.com/w/cpp/language/noexcept_spec , "noexcept" is part of the function signature in C++17, and so that's why virtualbox has—wait for it—..CallbackEPDoFiPS.. instead of CallbackEPFiPS (the Do part is that noexcept specifier). Well, in short, that's the bad part of the ext pack being closed-source.


openSUSE Build Service is sponsored by