Ask / Submit

Error building syncevolution

asked 2016-08-30 19:30:47 +0300

Digital Brains gravatar image

updated 2016-08-31 14:11:46 +0300

jiit gravatar image

On my Jolla 1, I have syncevolution for CardDAV sync with a radicale server. Native CalDAV works, but for CardDAV I still need syncevolution.

On my Jolla C, I can't install syncevolution from OpenRepos: it depends on, but my Jolla C has So I got the source from here. I end up stumbling on this error:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I/home/src1/src/sailfish/syncevolution/src/build-synthesis/src -I/usr/include -Ineon27-0.29.3/src -D_LARGEFILE64_SOURCE -DNE_LFS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./test -I./src/gdbusxx -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./src/syncevo -I./src -DSYNCEVO_LIBEXEC=\"/usr/libexec\" -DSYNCEVO_BACKEND=\"/usr/lib/syncevolution/backends/\" -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DDATA_DIR=\"/usr/share/syncevolution\" -DXML_CONFIG_DIR=\"/usr/share/syncevolution/xml\" -DTEMPLATE_DIR=\"/usr/share/syncevolution/templates\" -DLIBDIR=\"/usr/lib\" -I/home/src1/src/sailfish/syncevolution/src/build-synthesis/src -Wall -Wno-unknown-pragmas -Wno-deprecated-declarations -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -fmessage-length=0 -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb -Wno-psabi -MT src/syncevo/src_syncevo_libsyncevolution_la-LocalTransportAgent.lo -MD -MP -MF src/syncevo/.deps/src_syncevo_libsyncevolution_la-LocalTransportAgent.Tpo -c src/syncevo/LocalTransportAgent.cpp  -fPIC -DPIC -o src/syncevo/.libs/src_syncevo_libsyncevolution_la-LocalTransportAgent.o
{standard input}: Assembler messages:
{standard input}:90910: Error: invalid operands (*UND* and .ARM.extab.text._ZN7SyncEvo24LocalTransportAgentChild9startSyncERKSsRKSt4pairISsSsES2_bRKS3_INS_12UserIdentityENS_9InitStateISsEEERKNS_9FullPropsERKSt3mapISsS4_St4lessISsESaIS3_IS1_S4_EEERKN5boost10shared_ptrIN8GDBusCXX7Result2ISsNSQ_9DBusArrayIhEEEEEE sections) for `-'
{standard input}:90913: Error: invalid operands (*UND* and .ARM.extab.text._ZN7SyncEvo24LocalTransportAgentChild9startSyncERKSsRKSt4pairISsSsES2_bRKS3_INS_12UserIdentityENS_9InitStateISsEEERKNS_9FullPropsERKSt3mapISsS4_St4lessISsESaIS3_IS1_S4_EEERKN5boost10shared_ptrIN8GDBusCXX7Result2ISsNSQ_9DBusArrayIhEEEEEE sections) for `-'
armv7hl-meego-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <> for instructions.
make[2]: *** [src/syncevo/src_syncevo_libsyncevolution_la-LocalTransportAgent.lo] Error 1

The precise error changes every invocation, but always it is the assembler complaining about invalid code produced by compiling this particular file src/syncevo/LocalTransportAgent.cpp.

I'm at a loss how to proceed. I don't know C++ and I'm unfamiliar with the build environment. I don't know whether this is truly a compiler bug or not. I thought I'd bring it up here first, and hopefully somebody more familiar with this stuff can give it a try.

By the way, I never have stability issues with the machine on which I'm compiling, and it isn't overclocked. I'm aware that this class of errors can happen with failing hardware, but I have no reason to believe it is related to that.

I'll now describe how I got to where I am now.

At first, I upgraded an ancient Sailfish SDK I already had installed, thinking "let's try that first". I'm not sure how the author of the Sailfish UI for syncevolution built the package, but floundering around a bit, I ended up creating the directory "rpm" in the unpacked source, copying the spec file that is in the root of the unpacked source there, and adding intltool to the BuildRequires, since the build complained about not having that installed.

Issuing a mb2 -t SailfishOS-armv7hl build in the unpacked source dir ended up erroring out as described. At this point, I removed the old Sailfish SDK and installed a fresh one. However, the Virtual Machine of the old SDK somehow survived, creating some Frankenstein VM where it ended up using stuff I had already removed, very odd.

So I once more removed the SDK, checking my process list to make sure VirtualBox was no longer running, and did a fresh SDK install. You can read how it went from there in this gist. The spec file I copied at the start of that gist is here; its only change from the spec file from the source is the added intltool BuildRequires.

Can anybody provide more insight? Is this a compiler bug? And also: could somebody please compile a new syncevolution for SailfishOS v2.0.2.43? :-)

edit retag flag offensive close delete



If that error travels, it is merely because lack of work memory. It might help if you try to increase the memorysize of your virtualbox Mer SDK. It's size is initially only 512MB.

hnhanu ( 2016-09-06 16:41:38 +0300 )edit

Thanks hnhanu!

Digital Brains ( 2016-09-16 13:45:50 +0300 )edit

2 Answers

Sort by » oldest newest most voted

answered 2016-09-09 00:33:22 +0300

accumulator gravatar image

updated 2016-09-09 00:37:44 +0300

I noticed it had disappeared from my Jolla 1 too.

I've made a fresh build here :

edit flag offensive delete publish link more


Ah, great, that is so much more convenient! Thank you! It works great here.

Digital Brains ( 2016-09-16 13:47:05 +0300 )edit

answered 2016-09-16 13:45:12 +0300

Digital Brains gravatar image

As hnhanu said in a comment, indeed the error goes away when you increase the amount of work memory. So that counts as an answer to my question.

But what an ugly, ugly way to fail on out of memory!

edit flag offensive delete publish link more



My build still fails though, now on linking:

/home/src1/src/sailfish/syncevolution/src/syncevo/GLibSupport.h:991:77: error: 'signon_auth_session_process_async' was not declared in this scope
              new SYNCEVO_GLIB_CALL_ASYNC_CXX(_prepare)::CXXFunctionCB_t(_cb))

But I don't particularly care anymore, as accumulator has made a version available on OpenRepos!

Digital Brains ( 2016-09-16 13:45:23 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2016-08-30 19:30:47 +0300

Seen: 269 times

Last updated: Sep 16 '16