At a customer site, we had a C++ program (renamed for the purpose of this blog to myprogram) which was failing after running for some time. It’s a program processing messages from an external system and seemed to fail only when the processing of the message triggered some given operations. The error message was:
lookup error: /home/xxx/bin/xxx/myprogram: undefined symbol: _Z22CxxxPxxxExxxPxxxR6CDBManRKSsRSt6vectorISsSaISsEE
The first thought was to use ldd to check whether everything was fine:
# ldd myprogram
linux-gate.so.1 => (0xffffe000)
libxxx230.so => not found
libmc3adv.so => not found
libsybdb.so => not found
libxxxutl.so => not found
libxxxdb.so => not found
libxxxcustom.so => not found
libxerces-c.so.23 => not found
libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40022000)
libm.so.6 => /lib/tls/libm.so.6 (0x400df000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40101000)
libc.so.6 => /lib/tls/libc.so.6 (0x40109000)
/lib/ld-linux.so.2 (0x40000000)
So many not found ! Ok I must have forgotten something… Of course, LD_LIBRARY_PATH is probably not set in my shell:
# pidof myprogram 10132 # export `cat /proc/10132/environ | strings | grep LD_LIBRARY_PATH`
- pidof return the id of the process running the specified program
- /proc/10132/environ contains the whole environment of the specified process
- strings is required to convert the 0x00 separated strings of /proc/xxx/environ
- The rest just gets the line LD_LIBRARY_PATH=… and uses export to set it in my shell as well
Now I have the same LD_LIBRARY_PATH as the process running myprogram and can rerun ldd:
ldd myprogram
linux-gate.so.1 => (0xffffe000)
libxxx230.so => /home/xxx/libs/libxxx230.so (0x40018000)
libmc3adv.so => /home/xxx/libs/libmc3adv.so (0x40051000)
libsybdb.so => /opt/sybase-12.5/OCS-12_5/lib/libsybdb.so (0x403a5000)
libxxxutl.so => /home/xxx/libs/libxxxutl.so (0x404e1000)
libxxxdb.so => /home/xxx/libs/libxxxdb.so (0x405c5000)
libxxxcustom.so => /home/xxx/libs/libxxxcustom.so (0x4068d000)
libxerces-c.so.23 => /home/xxx/libs/libxerces-c.so.23 (0x40695000)
libdl.so.2 => /lib/libdl.so.2 (0x40985000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40988000)
libm.so.6 => /lib/tls/libm.so.6 (0x40a46000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a68000)
libc.so.6 => /lib/tls/libc.so.6 (0x40a70000)
libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40b8a000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40bd2000)
/lib/ld-linux.so.2 (0x40000000)
Everything looks OK. So it’s not that a library is missing. Also the paths to the libraries are OK.
Executing ldd -r -d myprogram basically just shows me the same plus an error with the missing symbol.
Finally, comparing the size of the library files on this system and at another customer site with the exact same version of the software gave us the answer: somehow a different version of one of our library landed there and didn’t contain the missing symbol.
So the search ended there. Otherwise we’d have had to use the following:
Use c++filt to find out the method behind the mangled symbol name:
# c++filt _Z22CxxxPxxxExxxPxxxR6CDBManRKSsRSt6vectorISsSaISsEE CxxxPxxxExxxPxxx(CDBMan&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)
Use nm to list the symbols in the libraries shown by ldd:
# nm /home/xxx/libs/libxxxdb.so
This will show the mangled symbol names. For demangled symbols, use the -C option:
# nm -C /home/xxx/libs/libxxxdb.so
Суть проблемы
Недавно, занимаясь одним из своих С++ проектов обнаружил следующее занимательное поведение программы, использующих динамическую библиотеку. На самом деле, неважно какая библиотека вызвала данную проблему, я уверен, что это не имеет никакого значения. Но в моем случае данная проблема возникла с библиотекой libuhd. Я собрал для себя специальную версию ibuhd, успешно скомпилировал и слинковал приложение с либой и бац! при запуске:
linux; GNU C++ version 4.8.5; Boost_105800; UHD_003.010.001.001-0-unknown
/home/michael/Projects/eclipse/C++/wirelessdriver/UhdRadio/Debug/UhdRadio: symbol lookup error: /home/michael/Projects/eclipse/C++/wirelessdriver/UhdRadio/Debug/UhdRadio: undefined symbol: _ZN20radio_ctrl_core_30004makeEbN5boost10shared_ptrIN3uhd9transport12zero_copy_ifEEES5_jRKSs
Причина в отсутствии функции в классе библиотеки или самого класса! Собирал я это чудо cmake, и, как оказалось, в cmake также можно задавать видимость определенных классов, но предварительно я снял все ограничения, экспортировал все, что есть. Сижу недоумеваю, пью кофе и тихо матерюсь («С++, что же ты со мной делаешь!»).
Дьявол скрывается в мельчайших деталях
В первую очередь решил проверить, а есть ли в библиотеке такой символ. Для таких целей в Linux есть утилита nm. Она позволяет вывести список экспортируемых символов, но он оказывается гигантским, поэтому используем ее совместно с grep, получаем:
~/Projects/eclipse/C++/wirelessdriver/UhdRadio/uhd-release_003_010_001_001/host/build/lib> nm -D libuhd.so | grep _ZN20radio_ctrl_core_30004makeEbN5boost10shared_ptrIN3uhd9transport12zero_copy_ifEEES5_jRKSs
00000000004e1ff0 T _ZN20radio_ctrl_core_30004makeEbN5boost10shared_ptrIN3uhd9transport12zero_copy_ifEEES5_jRKSs
Да, что же такое! Нужные символы есть, возможно не все зависимости (библиотеки) есть в системе, но ldd показывает, что все ОК (показывает откуда (путь) подлинковываются либы). И тут меня осенило!!! Я собирал целую массу версий uhd и параллельно ставил ее из пакетов, а что же говорит ldd относительно этой либы в моей утилите??? А говорит он, что либа при запуске приложения берется не из того, же источника откуда проводилась линковка! Понятно, что для запуска либа должна быть в LD_LIBRARY_PATH, но оба пути находятся в этой переменной, а при запуске либа тянется из первого в порядке упоминания пути, а моих изменений там вовсе НЕТ. Правим и наслаждаемся спокойной работой дальше.
Заключение
С++ , GCC люблю я вас! Настолько много в вас неожиданных сюрпризов…
I installed skype using several process in my newly installed Ubuntu 14. 04 64 bit… it shows a skype icon in dash… but when I click on it, nothings happens. What can I do?
I tried almost everything found in net. Every time it installed quite normally and found skype icon in dash. But not opening, when I click on it.
I downloaded skype 4.2 version from their website and installed using software centre and also tried installing via command line. But still not working.
When I tried to run skype using terminal it produce following output—
skype: symbol lookup error: /usr/lib/i386-linux-gnu/libQtOpenGL.so.4: undefined symbol: _ZNK14QWidgetPrivate17hasHeightForWidthEv
Wilf
29.2k16 gold badges103 silver badges162 bronze badges
asked Apr 19, 2014 at 17:25
9
The problem is for nVidia optimus driver
Skype 4.2 in Ubuntu 13.04 won’t open in nVidia Optimus Laptops
Open the link and enjoy not even a restart is needed
Steps:
-
Open a terminal and type sudo nano /etc/ld.so.conf.d/skype.conf
-
Add the code /usr/lib/i386-linux-gnu/mesa/ in the next console window, and press ctrl+x to exit, when prompted enter y to say yes
-
And finally run sudo ldconfig -v
answered Jun 3, 2014 at 16:23
This post helped me to figure out my problem.
«skype: symbol lookup error: skype: undefined symbol»
I had problem in my skype launcher. However I edited this through this command
gksu gedit /usr/share/applications/skype.desktop
in super user mode. After opening the script in gedit I edit
Exec=Skype to Exec=env LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/ /usr/bin/skype
to force use of the libraries in the i-386-linux-gnu directory and successfuly launched Skype.
answered Apr 24, 2014 at 19:51
plabonplabon
511 silver badge5 bronze badges
Because I just solved an issue with a Qt application on my installation of Ubuntu 16.04:
If you go to /usr/local/lib, you might find many libQtfiles. Simply move these files out of that folder and into /usr/.
mv *Qt* /usr/local/lib /usr/
Moving these will not break your system, I’ve done it before and the changes can be reverted by simply moving them back to /usr/local/lib.
One of my Qt applications behaved just like your issue with Skype. Clicking on it did nothing and running a terminal command would respond by saying «symbol lookup error».
It seems Qt doesn’t like to run well on Ubuntu and even fresh installations of it seem to have wrong configurations.
TheOdd
2,9021 gold badge20 silver badges41 bronze badges
answered Sep 29, 2017 at 17:23
cchoe1cchoe1
1195 bronze badges
It seems to be a bug in the build against the Qt libraries, since they are using the same packages as precise in trusty. In the case of skype, you need to wait until new builds are available. In the case of any other opensource application, just download the sources, download the development libraries of Qt libqt*-dev and build your program again.
This is not specific of Skype, other Qt applications has the same problems:
https://askubuntu.com/q/389246/169736
answered Apr 19, 2014 at 17:52
BraiamBraiam
66.2k30 gold badges174 silver badges262 bronze badges
5
Installed Skype using the method described in the NoobsLab article.
http://www.noobslab.com/2014/01/skype-released-new-version-install-in.html
While it installed and ran flawlessly on my desktop I had the same issue as the original poster and could not run the application on my laptop.
I realised that it maybe due to the GPU with the use of Bumblebee so I tried it using optirun from the terminal. I was able to run and configure Skype after which it continued to run from the launcher.
I leave it upto you guys to work out why and offer a better solution.
answered Apr 19, 2014 at 23:57
3
This worked for me
sudo add-apt-repository "deb http://archive.canonical.com/ $(lsb_release -sc) partner"
sudo apt-get update
sudo apt-get install skype
Eric Carvalho
53k102 gold badges134 silver badges161 bronze badges
answered Apr 24, 2014 at 11:01
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
joysfera opened this issue
May 12, 2016
· 38 comments
Comments
Expected behaviour
owncloud client should start
Actual behaviour
$ owncloud
owncloud: symbol lookup error: /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain15ReadPasswordJob6setKeyERK7QString
Steps to reproduce
- apt-get install owncloud-client
- owncloud
Client configuration
Client version: 2.2.0-1.1
Operating system: Ubuntu 16.04 64-bit
FYI, the Ubuntu 15.10 nightlies of 2.2.x worked OK but I thought I’d revert back to «stable» compiled precisely for my version of Ubuntu.
$ more /etc/apt/sources.list.d/owncloud.list
deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_16.04/ /
$ dpkg -l "*cloud*" | grep ^ii
ii libowncloudsync0:amd64 2.2.0-1.1 amd64 the ownCloud sync library
ii owncloud-client:amd64 2.2.0-1.1 amd64 The ownCloud sync client - github.com/owncloud/client
ii owncloud-client-l10n 2.2.0-1.1 all Internationalization files for ownCloud
$ ldd `which owncloud` | grep sync
libowncloudsync.so.0 => /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0 (0x00007f7b46d53000)
libocsync.so.0 => /usr/lib/x86_64-linux-gnu/owncloud/libocsync.so.0 (0x00007f7b45938000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f7b3c03f000)
This seems to be caused by incorrect version of libqt5keychain0 — after uninstalling the nightly version there remains libqt5keychain0 version 0.6.2-11.1. If you then install a stable build it fails to run. You have to remove the libqt5keychain0 first and only then install the stable owncloud-client that in turn installs libqt5keychain0 version 0.5.0-1build1~gcc5.1 with which it works OK.
So this is basically a package issue — the libqt5keychain0 should have been uninstalled automatically and also the stable package should enforce installing the right version of libqt5keychain0 as apparently it doesn’t work with a newer one.
The problem is that qtkeychain changed their ABI without bumping the SO Version.
A workaround is to recompile owncloudclient with libqtkeychain 0.6.2 and add this as dependency or add a break to the 0.6.X version to make sure that apt installs the correct version.
@hefee can you file this upstream?
Anyway, isv:ownCloud:desktop should have 0.6.2 as well. Fixing this now. Updated packages should be available in a few minutes.
@hefee Shame on me. Didn’t. Thanks!
Same issue after latest update on OpenSUSE LEAP 42.1:
owncloud: symbol lookup error: /usr/lib64/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain3Job6setKeyERKT
This appeared after the last zypper update today. According to the rpm changelog, the package was updated on FR 13.5 by freitag@owncloud.com:
Information for package owncloud-client:
Repository: Owncloud Client
Name: owncloud-client
Version: 2.2.0-2.2
Arch: x86_64
Vendor: obs://build.opensuse.org/isv:ownCloud
Installed: Yes
Status: up-to-date
Installed Size: 2.4 MiB
Summary: The ownCloud client
Description:
The ownCloud sync client — github.com/owncloud/client
Similar issue after latest upgrade on OpenSUSE 13.2:
«owncloud: symbol lookup error: /usr/lib64/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain15ReadPasswordJob6setKeyERK7QString».
Worked again after downgrading libqt5keychain0 from 0.6.2-1.1-x86_64 (from isv:ownCloud:desktop) to 0.5.0-12.2-x86_64 (from KDE:Extra)
This workaround does not help on leap.
the symbol lookup error appears with libqtkeychain0 0.4-3.3 (OpenSUSE standard), 0.4-5.1 (KDE Extra) and 0.6.2-1.1 (isv: ownCloud)
I’m having same issue with Ubuntu 14.04:
owncloud: symbol lookup error: /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain3Job6setKeyERK7QString
If it can help, doing ldd reports:
libowncloudsync.so.0 => /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0 (0x00007ffa9fe1e000)
libocsync.so.0 => /usr/lib/x86_64-linux-gnu/owncloud/libocsync.so.0 (0x00007ffa9ecdb000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007ffa9432d000)
However, libocsync package is not installed on my system and it’s impossible to install as libowncloudsync0 package says it breaks libocsync0
Please find a solution, as of today I can’t use owncloud client anymore!!
EDIT: please read post below, also my post was wrong for the simple reason that libocsync is directly provided from owncloud
I was having this issue because I had libqt5keychain0 0.5-9. I upgraded it to 0.6.2-1.1 (standard ubuntu update) and now it’s finally working.
Thanks danimo irc user for suggestion
Same as bulletxt here. I’ve upgraded from owncloud-client 2.1.1 to 2.2.0, and got the same «undefined symbol» error as the original poster. After upgrading libqt5keychain0 from version 0.5.0-1build1~gcc5.1 to 0.6.2-1.1, it worked again.
Same issue on Red Hat Enterprise Linux 6.8.
After installing latest stable 2.2.0, owncloud client won’t start.
owncloud —logfile —
/opt/qt-4.8/bin/owncloud: symbol lookup error: /usr/lib64/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain3Job6setKeyERK7QString
ldd /usr/lib64/libowncloudsync.so.0 shows
libqtkeychain.so.0 => /opt/qt-4.8/lib64/libqtkeychain.so.0 (0x00007f4bbcde4000)
On this Debian/stable box, libqtkeychain0 would only be upgraded to 0.6.2 when apt-get is called with -t jessie-backports — although libqtkeychain0 is then fetched from the OC repo, not from the Debian backports repository. o_O
But now I have two packages: libqtkeychain0 (v0.6.2) and libqt5keychain0 (v0.4.0). After removing the latter, the original error is back:
$ owncloud
owncloud: symbol lookup error: /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain16WritePasswordJob6setKeyERK7QString
$ ldd /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0 | grep qt
libqtkeychain.so.0 => /usr/lib/x86_64-linux-gnu/libqtkeychain.so.0 (0x00007f086b850000)
$ ls -go /usr/lib/x86_64-linux-gnu/libqtkeychain.so.0*
lrwxrwxrwx 1 22 May 14 05:47 /usr/lib/x86_64-linux-gnu/libqtkeychain.so.0 -> libqtkeychain.so.0.6.2
-rw-r--r-- 1 144144 May 14 05:47 /usr/lib/x86_64-linux-gnu/libqtkeychain.so.0.6.2
$ nm -D /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0 | grep WritePasswordJob6setKey
U _ZN9QKeychain16WritePasswordJob6setKeyERK7QString
It looks like trying to upgrade libqtkeychain is not an option for me unfortunately; when I try to upgrade it, zypper says that the version I already have installed is 0.20131103-27.1 (0.6.2-2.1) from the ownCloud OBS repo, which is newer than the other versions that I can find out on OBS. I’m running oS 13.1 Evergreen 32-bit.
I thought that I’d just downgrade to the older version of the client then, but it doesn’t exist on OBS anymore apparently :'(
chrismyers81, you need libqt5keychain0 from isv:ownCloud:desktop repository.
jnweiger
added a commit
to owncloud/administration
that referenced
this issue
May 17, 2016
jnweiger
added a commit
to owncloud/administration
that referenced
this issue
May 17, 2016
RHEL6 still not fixed. Updated by yum:
May 18 08:37:38 Updated: libowncloudsync0-2.2.0-5.1.x86_64
May 18 08:37:40 Updated: owncloud-client-l10n-2.2.0-5.1.x86_64
May 18 08:37:43 Updated: owncloud-client-2.2.0-5.1.x86_64
Using repository:
http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/RHEL_6/
Keychain installed from same repo:
Installed Packages
Name : opt-libqtkeychain0
Arch : x86_64
Version : 0.20140128
Release : 4.1
Size : 146 k
Repo : installed
From repo : isv_ownCloud_desktop
Summary : A cross platform password store library
URL : https://github.com/frankosterfeld/qtkeychain
License : MIT
Description : use qtkeychain to store passwords easy and secure on Linux, Windows and
: Mac.
@newachu I cannot reproduce your RHEL_6 issue:
wget -nv http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/RHEL_6/isv:ownCloud:desktop.repo -O /etc/yum.repos.d/isv:ownCloud:desktop.repo yum install owncloud-client
pulls in libowncloudsync0-2.2.0-5.1.x86_64 which has
rpm -q --requires libowncloudsync0 | grep keychain libqtkeychain.so.0()(64bit) opt-libqtkeychain0 >= 0.6.2
So your opt-libqtkeychain0 should be upgraded to the correct version.
We did not increment the version number of libowncloudsync0 in this rebuild. Maybe you are stuck with the old one? It should be build release 5.1 …
Hmm, still no love for me :/
chrismyers:/home/cmyers # rpm -qa | grep -i libqt5keychain0
libqt5keychain0-0.6.2-1.1.i586
chrismyers:/home/cmyers/Downloads/oc2 # rpm -Uvh *.rpm
Preparing… ################################# [100%]
Updating / installing…
1:libowncloudsync0-2.2.1nightly201################################# [ 17%]
2:owncloud-client-l10n-2.2.1nightl################################# [ 33%]
3:owncloud-client-2.2.1nightly2016################################# [ 50%]
Cleaning up / removing…
4:owncloud-client-l10n-2.2.1nightl################################# [ 67%]
5:owncloud-client-2.2.1nightly2016################################# [ 83%]
6:libowncloudsync0-2.2.1nightly201################################# [100%]cmyers@chrismyers:> owncloud
owncloud: symbol lookup error: /usr/lib/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain3Job6setKeyERK7QString
cmyers@chrismyers:> ls -l /usr/lib/libowncloudsync.so.*
lrwxrwxrwx 1 root root 24 May 18 08:28 /usr/lib/libowncloudsync.so.0 -> libowncloudsync.so.2.2.1
-rwxr-xr-x 1 root root 1283479 May 17 20:59 /usr/lib/libowncloudsync.so.2.2.1
But it looks like upgrading to libqt5keychain didn’t update the links?
cmyers@chrismyers:~> ldd /usr/lib/libowncloudsync.so.0 | grep qt
libqtkeychain.so.0 => /usr/lib/libqtkeychain.so.0 (0xb6585000)
Are there any ramifications of me manually changing the symlink?
@jnweiger Thank you for the check. I tried to reinstall both libowncloudsync0 and opt-libqtkeychain0 with the following results:
`yum reinstall libowncloudsync0
Setting up Reinstall Process
Resolving Dependencies
—> Running transaction check
—> Package libowncloudsync0.x86_64 0:2.2.0-5.1 will be reinstalled
—> Finished Dependency Resolution
Downloading Packages:
libowncloudsync0-2.2.0-5.1.x86_64.rpm | 424 kB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : libowncloudsync0-2.2.0-5.1.x86_64 1/1
Verifying : libowncloudsync0-2.2.0-5.1.x86_64 1/1
Installed:
libowncloudsync0.x86_64 0:2.2.0-5.1
yum reinstall opt-libqtkeychain0
Loaded plugins: product-id, refresh-packagekit, rhnplugin, search-disabled-repos, security
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Reinstall Process
Installed package opt-libqtkeychain0-0.20140128-4.1.x86_64 (from isv_ownCloud_desktop) not available.
Error: Nothing to do
yum install opt-libqtkeychain0
Loaded plugins: product-id, refresh-packagekit, rhnplugin, search-disabled-repos, security
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Package matching opt-libqtkeychain0-0.6.2-1.1.x86_64 already installed. Checking for update.
Nothing to do`
Managed to fix the issue with full removal and reinstall:
yum remove opt-libqtkeychain0
yum install owncloud-client
Solved for RHEL6 👍
I tried completely uninstalling and reinstalling from the repos, and when I chose to reinstall it’s pulling libqtkeychain, not libqt5keychain : http://susepaste.org/5de15bdd
However, it looks like it’s working now after doing a full uninstall-reinstall.
Happy to see that enforcing version 0.6.2 of qtkeychain/qt5keychain seems to solve the issue for everybody one way or the other. Please open new issues if more fixes are needed.
On Fedora 24 you can workaround the issue by running dnf downgrade qtkeychain-qt5 qtkeychain. After that owncloud client runs fine.
Hi, under Ubuntu Mate 16.04 i have the same issue.
symbol lookup error: /usr/lib/x86_64-linux-gnu/libowncloudsync.so
Do you have any solution ?
This is what I did under Xubuntu 14.04 to get it working again:
sudo apt-get update
sudo apt-get remove owncloud-client
sudo apt-get autoremove
sudo apt-get install owncloud-client
Maybe it’ll help someone.
I see this on Debian testing.
libqt5keychain0 is 0.6.2-1.1
Unfortunately this comment isn’t valid as a general fix.
@mtompkins
sudo apt-get install libqtkeychain0=0.6.2-1.1 libqt5keychain0=0.6.2-1.1
@Cyb0org
Thanks for suggestion. No go unfortunately:
mtompkins@aio:~$ sudo apt-get install libqtkeychain0=0.6.2-1.1 libqt5keychain0=0.6.2-1.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
libqt5keychain0 is already the newest version (0.6.2-1.1).
The following NEW packages will be installed:
libqtkeychain0
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 42.6 kB of archives.
After this operation, 179 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0 libqtkeychain0 0.6.2-1.1 [42.6 kB]
Fetched 42.6 kB in 0s (67.1 kB/s)
Selecting previously unselected package libqtkeychain0.
(Reading database ... 282590 files and directories currently installed.)
Preparing to unpack .../libqtkeychain0_0.6.2-1.1_amd64.deb ...
Unpacking libqtkeychain0 (0.6.2-1.1) ...
Setting up libqtkeychain0 (0.6.2-1.1) ...
mtompkins@aio:~$ owncloud
owncloud: symbol lookup error: /usr/lib/x86_64-linux-gnu/libowncloudsync.so.0: undefined symbol: _ZN9QKeychain16WritePasswordJob6setKeyERK7QString
mtompkins@aio:~$
@Cyb0org Pt2.
Full uninstall and reinstall after that package does indeed work. Thank you.
On Debian/jessie, the owncloud-client would not work unless its version numbers were forced during the installation:
$ sudo apt-get -V install owncloud-client=2.2.0-2 libowncloudsync0=2.2.0-2
owncloud-client-l10n=2.2.0-2 libowncloudsync0=2.2.0-2
libqt5keychain0=0.6.2-1.1 libqtkeychain0=0.6.2-1.1
However, APT pinning may be a more elegant way to achieve the same:
$ cat /etc/apt/preferences.d/owncloud.pref Package: * Pin: origin download.opensuse.org Pin-Priority: 1000 $ sudo apt-get -V install owncloud-client [...] Get:1 http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0/ libqtkeychain0 0.6.2-1.1 [42.6 kB] Get:2 http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0/ libowncloudsync0 2.2.0-2 [394 kB] Get:3 http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0/ owncloud-client-l10n 2.2.0-2 [32.1 kB] Get:4 http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0/ owncloud-client 2.2.0-2 [963 kB]
With that, owncloud-client is working again. The only oddity is the «%nil» in the version string in the «General» tab in the application:
Had same issue, my repository setting was still set on 15.10 while I have installed 16.04 a few weeks ago
Changing the repository to 16.04 and then reinstalling (thx to @FriendFX) worked well.
@ckujau thank you a lot, your answer helped me!
#4829 (comment) fixed it for me (Debian/Sid).
Looks like Debian have an issue in their build of 2.2.0-2-dfsg. Pinning takes care of that though!
the trialing %nil will be fixed with 2.2.1 — fixed the rules template today.