Re: [os-libsynthesis] [os-libsythesis] How to runasampleapplication
Hello Patrick, Thanks for your reply. I am again surprised by a strange output. nm libsmltk.a does not show the required functions. This library is being linked but does not contain any of the required functions. What can be the probable reason? Rgds, Shefali -Original Message- From: Patrick Ohly [mailto:patrick.o...@intel.com] Sent: Tuesday, June 30, 2009 5:52 PM To: Shefali Dutta Cc: Lukas Zeller; os-libsynthesis@synthesis.ch Subject: RE: [os-libsynthesis] [os-libsythesis] How to runasampleapplication Hello Shefali! Good to see that you haven't given up on SyncEvolution yet. I'm still a bit mystified why you keep running into issues that I haven't seen before - I swear, this should work ;-} On Tue, 2009-06-30 at 05:02 -0700, Shefali Dutta wrote: I have tried compilation using --with-synthesis-src and --disable-shared option. I am getting some linking errors related to libsynthesis: File engineinterface.cpp - Undefined reference to smlLockWriteBuffer, smlLockReadBuffer, smlUnlockWriteBuffer. And many more errors related to smlxxx functions. These are in libsmltk, built in the same directory as libsynthesis (src/build-synthesis/src when using SyncEvolution as main makefile): $ nm src/build-synthesis/src/.libs/libsmltk.a | grep smlLockWriteBuffer 05f3 T smlLockWriteBuffer U smlLockWriteBuffer libsynthesis depends on libsmltk, so it should be on your link line after libsynthesis. What's the complete command line of your final link step? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] [os-libsythesis] How to runasampleapplication
On Tue, 2009-06-30 at 23:19 -0700, Shefali Dutta wrote: I am again surprised by a strange output. nm libsmltk.a does not show the required functions. This library is being linked but does not contain any of the required functions. What can be the probable reason? This is really strange. At least we are on-topic for this list again. Let's compare where I get the symbols from: src/build-synthesis/src$ nm -o .libs/libsmltk.a | grep smlLockWriteBuffer .libs/libsmltk.a:libsmltk_la-mgrinstancemgr.o:05f3 T smlLockWriteBuffer .libs/libsmltk.a:libsmltk_la-mgrcmdbuilder.o: U smlLockWriteBuffer The source is in libsynthesis/src/syncml_tk/src/sml/mgr/all/mgrcmdbuilder.c. Does your libsmltk.a contain the object file (ar tv .libs/libsmltk.a | grep mgrinstancemgr.o)? If so, was it compiled successfully? Try rebuilding it and check what the compiler does. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] unified log file
Hello Patrick, Before going into details, i.e. reviewing the patch I'd like to make sure I understand what is the goal: - you want a single log file for ALL logging, which means: - both global and session log of libsynthesis (including messages generated by the DB plugins) - PLUS messages generated by your application Right? I don't see why you need two engines for that. You can initialize the same engine twice, once at the beginning with basically only the log options, and a second time when your generated config stream is ready. Within the engine, you need: - a new flag to have the session logger redirect its output to the global logger, and also forwarding the appendtoexisting flag to the global logger such that it won't overwrite the beginning of the log. Maybe some changes are needed to prevent re-instantiation of the global logger at the second init, I'll have to check that. - a way to send debug message from the outside (the app) into the global log. Luckily, these already exist (Beat uses them exactly this way in his test suite). See DB_DebugPuts, DB_DebugBlock, DB_DebugEndBlock and DB_DebugEndThread entries in the UI_Call_In record, or the ready-to-use wrappers for these in SDK_utils (DEBUG_xxx). Just let me know if your goal is something entirely different I haven't understood so far. But if I'm correct, I think we have do a much less invasive solution - and especially can avoid EVIL globals :-) Best Regards, Lukas Zeller On Jun 30, 2009, at 20:04 , Patrick Ohly wrote: Hello! My goal since switching to the Synthesis engine was to have one single log file again. There are other ideas for logging improvements, but the single log is the most important one: http://bugzilla.moblin.org/show_bug.cgi?id=3474 I've been dragging my feet a bit with it and I knew it would be kind of complicated, but now I have something which works. Beware, I didn't say it is nice ;-} It's also not final yet, but if possible, I'd like to get it done this week. I've pushed the code into the moblin.org logging branch of libsynthesis and SyncEvolution. Lukas, Beat, can you have a look at the code and tell me whether this is okay in principle and what might have to be changed to make it suitable for upstream? The main issues I see are: * had to use a global variable to pass information (TSyncAppBase::fGlobalAppLoggerP); ideally I'd pass the handle for the first engine (with the active logger) to the creator of the second engine (the one with the datastores) * can only log plain text via DB_DebugPuts_Func(); I'd like to include more information (severity level, source file/line) -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
