Hello,
On Sun, 01 Dec 2019, Anton Aylward wrote:
On 01/12/2019 17.50, Anton Aylward wrote:
[..]
# zypper refresh zypper: symbol lookup error:
/usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
^^^^^^^^^^^
Please note
Hum!
[..]
On 01/12/2019 13:18, Carlos E. R. wrote:
main:/var/log # strings /usr/lib64/libmodman.so.1|grep -i zn9
_ZN9libmodman14module_managerD2Ev
_ZN9libmodman14module_managerD1Ev
_ZN9libmodman14module_manager12load_builtinEP9mm_module
_ZN9libmodman14module_manager9load_fileESsb
_ZN9libmodman14module_manager8load_dirESsb
RTFM: man 1 c++filt
$ cat <<'EOF' | c++filt
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
_ZN9libmodman14module_managerD2Ev
_ZN9libmodman14module_managerD1Ev
_ZN9libmodman14module_manager12load_builtinEP9mm_module
_ZN9libmodman14module_manager9load_fileESsb
_ZN9libmodman14module_manager8load_dirESsb
EOF
libmodman::module_manager::load_dir(std::__cxx11::basic_string, bool)
libmodman::module_manager::~module_manager()
libmodman::module_manager::~module_manager()
libmodman::module_manager::load_builtin(mm_module*)
libmodman::module_manager::load_file(std::basic_string, bool)
libmodman::module_manager::load_dir(std::basic_string, bool)
Note, too, that the switch from the old c++ strings
(std::basic_string) to the c++11 ones (std::__cxx11::basic_string)
requires to recompile the involved libs. In this case (having read
downthread), it's probably that libmodman is not compiled with
-std=c++11 nor -std=gnu++11 (because it's not from leap 15.0 but
a leftover from 42.3)...
So, just go and "force install" the current libmodman package from
leap 15.0, possibly using plain rpm in the process or even from a
rescue medium...
E.g. from a rescue system with a recent enough rpm (worst case):
# cd /mnt/DLS/suse/x86_64/
# rpm --test -ivh --root=/mnt/TARGET_SYS libmodman1-*.rpm
(assuming you have not downloaded unnessessary file to /mnt/DLS/ like
*-debug* packages or -32bit packages where unneeded).
Add more packages as needed by deps, possibly using ../noarch/foo*.rpm
in the process.
Keep downloading, adding packages to the commandline and '--test'
installing until rpm is satisfied (that's the main job that zypper
does!). Once rpm is happy, omit the --test, install packages (rpm will
handle the inter-package deps of those packages given on the
commandline) and all should be well...
BTDT[1], HTH,
-dnh
[1] on my borked switch from i586 to x86_64 while leaving 'arch=i586'
in /etc/zypp/zypp.conf... Too bad binaries were 64bit and libs
32bit or so... IIRC not even rpm ran. Had to fix that with the
above method (a level lower) from a rescue system ... Good thing I
had the full install-ISO to loop-mount and install from instead of
DL-ing each package in turn...
--
Eh, that's it, I guess. No 300 million dollar unveiling event for this
kernel, I'm afraid, but you're still supposed to think of this as the
"happening of the century" (at least until the next kernel comes along).
-- Linus, in the announcement for 1.3.27
--
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org