[SailfishDevel] symbol lookup error from syncemail-client (undefined symbol: _ZN5Buteo13PluginManagerC1Ev)
Hi, I then get following error from syncemail-client symbol lookup error: /usr/lib/buteo-plugins-qt5//oopp/syncemail-client: undefined symbol: _ZN5Buteo13PluginManagerC1Ev But I have nm -D /usr/lib/libbuteosyncfw5.so.0 | grep ZN5Buteo13PluginManager 000419fc T _ZN5Buteo13PluginManagerD0Ev 000414f4 T _ZN5Buteo13PluginManagerD1Ev 000414f4 T _ZN5Buteo13PluginManagerD2Ev can someone give me a hint how to deal with this? I compiled buteo-syncfw from mer (https://git.sailfishos.org/deloptes/buteo-syncfw) and I do not recall seeing this error before. I compiled on the SDK-3 EA for 3.2.1.20. Thank you in advance. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] symbol lookup error from syncemail-client (undefined symbol: _ZN5Buteo13PluginManagerC1Ev)
Hello, Maybe not a good idea, but remove all the .moc in buteo-syncfw or make clean and recompile. Damien. Le Vendredi 3 janvier 2020, deloptes a écrit : > Hi, > I then get following error from syncemail-client > > symbol lookup error: /usr/lib/buteo-plugins-qt5//oopp/syncemail-client: > undefined symbol: _ZN5Buteo13PluginManagerC1Ev > > But I have > nm -D /usr/lib/libbuteosyncfw5.so.0 | grep ZN5Buteo13PluginManager > > 000419fc T _ZN5Buteo13PluginManagerD0Ev > 000414f4 T _ZN5Buteo13PluginManagerD1Ev > 000414f4 T _ZN5Buteo13PluginManagerD2Ev > > can someone give me a hint how to deal with this? > > I compiled buteo-syncfw from mer > (https://git.sailfishos.org/deloptes/buteo-syncfw) and I do not recall > seeing this error before. > I compiled on the SDK-3 EA for 3.2.1.20. > > Thank you in advance. > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.or ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] symbol lookup error from syncemail-client (undefined symbol: _ZN5Buteo13PluginManagerC1Ev)
Damien Caliste wrote: > Hello, > > Maybe not a good idea, but remove all the .moc in buteo-syncfw or make > clean and recompile. > > Damien. > Hi Damien, I did clean up and compiled from scratch. I'll repeat the whole process again to make sure nothing was missed. I am not sure if I understand correctly what it is looking for: _ZN5Buteo13PluginManagerC1Ev while there is _ZN5Buteo13PluginManagerD1Ev What I understand is that C1 is the constructor and D1 the destructor. Could it be some kind of compiler thing? thanks > Le Vendredi 3 janvier 2020, deloptes a écrit : >> Hi, >> I then get following error from syncemail-client >> >> symbol lookup error: /usr/lib/buteo-plugins-qt5//oopp/syncemail-client: >> undefined symbol: _ZN5Buteo13PluginManagerC1Ev >> >> But I have >> nm -D /usr/lib/libbuteosyncfw5.so.0 | grep ZN5Buteo13PluginManager >> >> 000419fc T _ZN5Buteo13PluginManagerD0Ev >> 000414f4 T _ZN5Buteo13PluginManagerD1Ev >> 000414f4 T _ZN5Buteo13PluginManagerD2Ev >> >> can someone give me a hint how to deal with this? >> >> I compiled buteo-syncfw from mer >> (https://git.sailfishos.org/deloptes/buteo-syncfw) and I do not recall >> seeing this error before. >> I compiled on the SDK-3 EA for 3.2.1.20. >> >> Thank you in advance. >> >> regards >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.or > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] symbol lookup error from syncemail-client (undefined symbol: _ZN5Buteo13PluginManagerC1Ev)
_ZN5Buteo13PluginManagerC1Ev is Buteo::PluginManager::PluginManager() $ c++filt _ZN5Buteo13PluginManagerC1Ev Buteo::PluginManager::PluginManager() There's no such thing: https://git.sailfishos.org/deloptes/buteo-syncfw/blob/master/libbuteosyncfw/pluginmgr/PluginManager.h#L96 These are available constructors: $ nm -D /usr/lib/libbuteosyncfw5.so.0 | grep ZN5Buteo13PluginManagerC 0003f0b8 T _ZN5Buteo13PluginManagerC1ERK7QString 0003f0b8 T _ZN5Buteo13PluginManagerC2ERK7QString $ c++filt _ZN5Buteo13PluginManagerC1ERK7QString Buteo::PluginManager::PluginManager(QString const&) Something must be wrong with your build environment, e.g. you're pulling in wrong headers from somewhere. Cheers, -Slava Hi, I then get following error from syncemail-client symbol lookup error: /usr/lib/buteo-plugins-qt5//oopp/syncemail-client: undefined symbol: _ZN5Buteo13PluginManagerC1Ev But I have nm -D /usr/lib/libbuteosyncfw5.so.0 | grep ZN5Buteo13PluginManager 000419fc T _ZN5Buteo13PluginManagerD0Ev 000414f4 T _ZN5Buteo13PluginManagerD1Ev 000414f4 T _ZN5Buteo13PluginManagerD2Ev can someone give me a hint how to deal with this? I compiled buteo-syncfw from mer (https://git.sailfishos.org/deloptes/buteo-syncfw) and I do not recall seeing this error before. I compiled on the SDK-3 EA for 3.2.1.20. Thank you in advance. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] symbol lookup error from syncemail-client (undefined symbol: _ZN5Buteo13PluginManagerC1Ev)
Thank you Slava, but I think the message is coming from /usr/lib/buteo-plugins-qt5//oopp/syncemail-client (buteo-sync-plugins-email-0.1.2-1.4.1.jolla.armv7hl) and I have nothing to do with that client :/ I even wonder if it is left over or installed by default, as I am not aware of using it. thanks in advance regards Slava Monich wrote: > _ZN5Buteo13PluginManagerC1Ev is Buteo::PluginManager::PluginManager() > > > $ c++filt _ZN5Buteo13PluginManagerC1Ev > Buteo::PluginManager::PluginManager() > > There's no such thing: > > > https://git.sailfishos.org/deloptes/buteo-syncfw/blob/master/libbuteosyncfw/pluginmgr/PluginManager.h#L96 > > These are available constructors: > > $ nm -D /usr/lib/libbuteosyncfw5.so.0 | grep ZN5Buteo13PluginManagerC > 0003f0b8 T _ZN5Buteo13PluginManagerC1ERK7QString > 0003f0b8 T _ZN5Buteo13PluginManagerC2ERK7QString > > $ c++filt _ZN5Buteo13PluginManagerC1ERK7QString > Buteo::PluginManager::PluginManager(QString const&) > > Something must be wrong with your build environment, e.g. you're pulling > in wrong headers from somewhere. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I have submitted PR to libhybris allowing to use Flatpak on hybris devices with the same version serving its main purpose and inside Flatpak sandbox: https://github.com/libhybris/libhybris/pull/433. As soon as your device has such libhybris, you could - use https://build.merproject.org/project/show/home:rinigus:flatpak to install flatpak, flatpak-runner - run flatpak-extension-hybris to generate Flatpah hybris extension at user nemo's home (run as nemo) - install flatpak apps, see instructions at Flathub on how to do it - run them using flatpak-runner Many things don't work, but would be faster to get it fixed together with other devs. Cheers. Rinigus On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: > Hi, > > just finished the first version of a wrapper for 'flatpak run' command as > well, available at https://github.com/rinigus/flatpak-runner . Its based > on qxcompositor and it opens new Wayland server before running an > application, all explained in README. Device rotation is supported and > should be followed. > > So, as it is: > > - we have to resolve libhybris linker issue to make it possible to > distribute. > - keyboard is not supported currently. At present, app has to have > qtvirtualkeyboard support added as in > https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel > . > - only single-window apps are working well, such as QML developed for > mobile > - no sound so far > - probably many other things are missing, haven't bumped into them. > > Essentially, we will have access to the latest Qt, but would have to write > apps for this use. Fortunately, it all goes along SFOS programming and > should be simple to convert later to Silica, when/if it catches up with Qt > versions. > > I guess we can get better integration after it will be simple to install > on other devices and start using it by others. > > Cheers, > > Rinigus > > On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: > >> Hi, >> >> wait a bit, I may have a way to simplify setup. Few days ago, after >> discussion on IRC, I found a way around disappearance of the window when >> wrapped into qxcomposer. So, that blocker is over now. Which means that we >> will be able to craft apps using the latest Qt available in Flatpaks. >> >> Currently, I am looking into >> >> - how we can use regular hybris >> - making a wrapper similar to qxcomposer for Flatpaks. >> >> Shouldn't take too long for an update on status. >> >> Cheers, >> >> Rinigus >> >> On Wed, Jan 1, 2020 at 4:55 PM wrote: >> >>> Could you elaborate on: >>> > libhybris compiled with specification of default >>> hybris-ld-library-path, >>> > content of libexec/droid-hybris added with GL extension. >>> Is that libhybris build available (and safe to run on main device, or >>> should I dig out my j1)? >>> Also not sure what added with GL extension means? Having a browser that >>> uses up to date webengine would be awesome. >>> >>> Thanks and happy new year! >>> szopin >>> >>> On Sunday, 29 December 2019, rinigus wrote: >>> > Hi, >>> > >>> > I would have preferred to stay away from discussion on why do we >>> need/not >>> > need Flatpak on SFOS. But I guess I have to take it as the one working >>> on >>> > making it possible. >>> > >>> > Native apps rely on the libs allowed in the Store and bundle the rest >>> of >>> > them. I presume OSM Scout Server and Pure Maps are exceptions, but >>> they are >>> > built around almost 20 libs bundled with the application and compiled >>> with >>> > newer gcc than the one on the platform. If I would have continued to >>> > provide OSM Scout Server via the official Store, I'd have to bundle >>> > libsystemd as well - something that I found was crossing a line for >>> me. So, >>> > any security issue in those bundled libs would be propagated the same >>> way >>> > as with the Flatpak. I admit that its way less libs than distributed >>> via >>> > Flatpak. However, in the case of Flatpak, apps are provided on the top >>> of >>> > "runtimes" with the app including everything which is extending the >>> runtime >>> > to make it work. So, in case of OSM Scout Server and Pure Maps, their >>> > Flatpaks do include some libs as well. Those runtimes are updated. >>> Now, I >>> > am not in position to say whether its security updates are as fast as >>> of >>> > distros and have no idea how it compares to SFOS. >>> > >>> > However, I see mainly portability and up-to-date toolbox aspect of >>> Flatpak, >>> > not that much security in terms of sandbox. These are my preferences >>> and >>> > they could differ from yours. >>> > >>> > Looking at the speed of upcoming Qt update, I was considering whether >>> to >>> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to >>> allow >>> > us to work on newer browser engine or make Flatpak available. The both >>> > solutions would break look-and-feel of SFOS, but allow us to use >>> current >>> > libs, something that we have been missing for too long. And, in many >>> > aspect
Re: [SailfishDevel] Flatpak for Sailfish
Ill build it on mido and try it out, thanks! On Fri, 3 Jan 2020 at 22:45, rinigus wrote: > Hi, > > I have submitted PR to libhybris allowing to use Flatpak on hybris devices > with the same version serving its main purpose and inside Flatpak sandbox: > https://github.com/libhybris/libhybris/pull/433. > > As soon as your device has such libhybris, you could > > - use https://build.merproject.org/project/show/home:rinigus:flatpak to > install flatpak, flatpak-runner > - run flatpak-extension-hybris to generate Flatpah hybris extension at > user nemo's home (run as nemo) > - install flatpak apps, see instructions at Flathub on how to do it > - run them using flatpak-runner > > Many things don't work, but would be faster to get it fixed together with > other devs. > > Cheers. > > Rinigus > > On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: > >> Hi, >> >> just finished the first version of a wrapper for 'flatpak run' command as >> well, available at https://github.com/rinigus/flatpak-runner . Its based >> on qxcompositor and it opens new Wayland server before running an >> application, all explained in README. Device rotation is supported and >> should be followed. >> >> So, as it is: >> >> - we have to resolve libhybris linker issue to make it possible to >> distribute. >> - keyboard is not supported currently. At present, app has to have >> qtvirtualkeyboard support added as in >> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel >> . >> - only single-window apps are working well, such as QML developed for >> mobile >> - no sound so far >> - probably many other things are missing, haven't bumped into them. >> >> Essentially, we will have access to the latest Qt, but would have to >> write apps for this use. Fortunately, it all goes along SFOS programming >> and should be simple to convert later to Silica, when/if it catches up with >> Qt versions. >> >> I guess we can get better integration after it will be simple to install >> on other devices and start using it by others. >> >> Cheers, >> >> Rinigus >> >> On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: >> >>> Hi, >>> >>> wait a bit, I may have a way to simplify setup. Few days ago, after >>> discussion on IRC, I found a way around disappearance of the window when >>> wrapped into qxcomposer. So, that blocker is over now. Which means that we >>> will be able to craft apps using the latest Qt available in Flatpaks. >>> >>> Currently, I am looking into >>> >>> - how we can use regular hybris >>> - making a wrapper similar to qxcomposer for Flatpaks. >>> >>> Shouldn't take too long for an update on status. >>> >>> Cheers, >>> >>> Rinigus >>> >>> On Wed, Jan 1, 2020 at 4:55 PM wrote: >>> Could you elaborate on: > libhybris compiled with specification of default hybris-ld-library-path, > content of libexec/droid-hybris added with GL extension. Is that libhybris build available (and safe to run on main device, or should I dig out my j1)? Also not sure what added with GL extension means? Having a browser that uses up to date webengine would be awesome. Thanks and happy new year! szopin On Sunday, 29 December 2019, rinigus wrote: > Hi, > > I would have preferred to stay away from discussion on why do we need/not > need Flatpak on SFOS. But I guess I have to take it as the one working on > making it possible. > > Native apps rely on the libs allowed in the Store and bundle the rest of > them. I presume OSM Scout Server and Pure Maps are exceptions, but they are > built around almost 20 libs bundled with the application and compiled with > newer gcc than the one on the platform. If I would have continued to > provide OSM Scout Server via the official Store, I'd have to bundle > libsystemd as well - something that I found was crossing a line for me. So, > any security issue in those bundled libs would be propagated the same way > as with the Flatpak. I admit that its way less libs than distributed via > Flatpak. However, in the case of Flatpak, apps are provided on the top of > "runtimes" with the app including everything which is extending the runtime > to make it work. So, in case of OSM Scout Server and Pure Maps, their > Flatpaks do include some libs as well. Those runtimes are updated. Now, I > am not in position to say whether its security updates are as fast as of > distros and have no idea how it compares to SFOS. > > However, I see mainly portability and up-to-date toolbox aspect of Flatpak, > not that much security in terms of sandbox. These are my preferences and > they could differ from yours. > > Looking at the speed of upcoming Qt update, I was considering whether to > make qt5.12 (or later) in /opt (/home/opt) and use it from there to allow
