Re: GLib and Symbian?
If Tim or Matthias can comment and mention whether this solution would be acceptable, I'd be willing to try to adapt the gtk rewriter to try to automatically convert the global statics to use Tor's macro. The WSD changes, and the build files will be the major changes required for getting glib to work on Symbian. Regarding the first, WSD is only a problem with development on the emulator. More specifically, it is only a problem, if TWO or more processes on the emulator are using the DLL. Otherwise, the flag 'EPOCALLOWDLLDATA' in the build file is all that is required to build and use Glib. Regarding the build files, I would suppose the right folder to put them into, would be /build/symbian/ . Taking these 2 into consideration, as a first step, I will attempt to create a patch for the glib trunk, to allow it to be built on Symbian. We can use the glib test suite to validate this first port, and refine it further. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib and Symbian?
Hi, A few months back someone reported on this list hat he had ported GLib to Symbian. Has this port been merged, or is there somewhere I can get the branch of the Symbian version? Kind regards, Wim -- Wim Vander Schelden http://fixnum.org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and Symbian?
On Mon, 2009-05-18 at 01:07 +0200, Wim Vander Schelden wrote: A few months back someone reported on this list hat he had ported GLib to Symbian. Has this port been merged, or is there somewhere I can get the branch of the Symbian version? It has not been merged in. The problem was that static globals are not allowed in Symbian, and are used in quite a number of places. Tor posted a possible solution for that [1], but it would require a lot of changes to be made. If Tim or Matthias can comment and mention whether this solution would be acceptable, I'd be willing to try to adapt the gtk rewriter to try to automatically convert the global statics to use Tor's macro. [1]. http://mail.gnome.org/archives/gtk-devel-list/2008-September/msg00029.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib on Symbian
WSD in DLLs is not, and never will be, supported on EKA1 based versions of Symbian OS. However WSD in DLLs is supported on EKA2.(versions 9.x) Hence for the port of GLIB to work on EKA2 version of Symbian OS emulator we had to do these changes. As Biswajeet has mentioned, for Symbian OS 9.x (with the EKA2 kernel) WSD is supported on the target hardware but not on the emulator. Thus, these changes are applicable only for the emulator. A more accurate changed LOC count can be estimated only after we start porting these changes to the SVN trunk (we have currently ported the 2.10.3 version). Tor's suggestion looks good and will help reduce the number of changed files/locations. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib on Symbian
Kalle Vahlman wrote :-
Wrong. Symbian does not support static data in DLL:s in all versions out
there:
Please refer to the following link for the updated latest version of the
document :-
http://developer.symbian.com/main/downloads/papers/static_data/SupportForWriteableStaticDataInDLLs.pdf
The SYMBIAN OS EKA2 emulator only allows a DLL with WSD to load into a
single process
Hence for Support for emulator WSD
Symbian OS v9.4 provides emulator WSD (EWSD library), a mechanism to allow
DLLs
with WSD to be able to load into multiple processes. The support is not
transparent to the DLL writer;
they have to wrap the WSD in a data structure and pass it to the EWSD
library.
This library maintains the relationship between the library, and its WSD
values in each process.
The DLL writer has to make emulator-conditional changes to the source code
to:
? wrap all the WSD in the DLL into a single ?wrapper? data structure
? change code to refer to the wrapper data member rather than directly
? prevent EPOCALLOWDLLDATA being declared in the emulator build
For example, consider a DLL with a function foo() that uses WSD iState as
shown:
// source for foo.cpp
int iState;
void foo()
{
if (iState == ESomeState)
{
//do something
}
else
{
//do something else
}
}
You would change as shown:
// source for foo.cpp
struct MyWSD
{
int iState;
};
void foo()
{
#ifdef _USE_EWSD_
MyWSD *MyWSDPtr = PlsMyWSD(ThisLibUid);
// Pls is an API provided by the ewsd - it fetches the ptr for this
// (process,libuid) tuple.
// You can also pass an initialisation function to Pls() to initialise the
WSD
// ? initialisation is only done the 1st time the templated function is
called
#endif
10
if (MyWSDPtr-iState == ESomeState)
{
//do something
}
else
{
//do something else
}
}
The MMP file of that DLL must not have EPOCALLOWDLLDATA for the emulator
build,
so you would make its specification conditional on use of EWSD in the MMP
file:
#ifndef _USE_EWSD_
EPOCALLOWDLLDATA
#endif
WSD in DLLs is not, and never will be, supported on EKA1 based versions of
Symbian OS. However WSD in DLLs is supported on EKA2.(versions 9.x)
Hence for the port of GLIB to work on EKA2 version of Symbian OS emulator
we had to do these changes.
Regards
Biswajeet Dash|
Symbian Software India Private Limited |
[EMAIL PROTECTED]
Behdad Esfahbod [EMAIL PROTECTED]
Sent by: Behdad Esfahbod [EMAIL PROTECTED]
09/06/2008 02:14 AM
To
sparkymat [EMAIL PROTECTED]
cc
Tor Lillqvist [EMAIL PROTECTED], [EMAIL PROTECTED], gtk+ dev
gtk-devel-list@gnome.org
Subject
Re: glib on Symbian
sparkymat wrote:
We are doing what you have mentioned above, i.e. defining name of global
variables as function calls returning a pointer.
So, this limitation is *only* for the simulator, not the actual Symbian
running on mobile hardware, right? If that's the case I believe the
simulator
should be fixed instead.
behdad
For example, in gdate.c,
static gboolean using_twodigit_years = FALSE;
would become
#if defined(__SYMBIAN32__) defined(EMULATOR)
PLS(using_twodigit_years,gdate, gboolean)
#define using_twodigit_years
(*FUNCTION_NAME(using_twodigit_years ,gdate)()
#else
static gboolean using_twodigit_years = FALSE;
#endif
where the PLS() macro will add the specified variable to the Process
Local Storage, and the define will map it to a function pointer.
This is repeated for all write-able static data (WSD).
Experience innovation in action - visit the Smartphone Show, 21-22
October 2008, Earls Court 2, London
**
Symbian Software Ltd is a company registered in England and Wales
with registered number 4190020 and registered office at 2-6
Boundary Row, Southwark, London, SE1 8HP, UK. This message is
intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error
please notify [EMAIL PROTECTED] and delete the message and any
attachments accompanying it immediately. Neither Symbian nor any of
its Affiliates accepts liability for any corruption, interception,
amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
**___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib on Symbian
2008/9/5 Behdad Esfahbod [EMAIL PROTECTED]: sparkymat wrote: We are doing what you have mentioned above, i.e. defining name of global variables as function calls returning a pointer. So, this limitation is *only* for the simulator, not the actual Symbian running on mobile hardware, right? Wrong. Symbian does not support static data in DLL:s in all versions out there: http://developer.symbian.com/main/downloads/papers/static_data/SupportForWriteableStaticDataInDLLsv1.1.pdf I'm not that familiar with symbian development, or the symbian device landscape, but those who are could give their view on whether it makes any sense to only support the versions that do have static data for DLL:s in upstream glib and the rest as for example a branch. While Tor's suggestion wasn't totally awkward for developers and might even have other benefits (eg. for debugging), changing 2000 LOCs just to get symbian in sounds like a bit of a stretch. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib on Symbian
There is one more issue that needs addressing. The Symbian OS emulator does not support global static data in libraries. We found a fair amount of global static data in the code and to work around these, we have symbian specific code inserted within '#ifdef SYMBIAN32' . The problem here is that these changes are peppered throughout the code and rack up nearly 2000 lines of changed code. Please show some concrete (minimal) example... I have a hard time to understand *exactly* what you mean. There must be some better way around this than adding 2000 ifdefs all around the code, which frankly doesn't sound acceptable to me. Sure, some ifdefs can be added, but in as few places as possible. Some clever use of the C preprocessor defining names of global variables as function calls retuning a pointer to function-local static data instead, or some clever preprocessing script used for Symbian compilations, or whatever. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib on Symbian
For example, in gdate.c,
static gboolean using_twodigit_years = FALSE;
would become
#if defined(__SYMBIAN32__) defined(EMULATOR)
PLS(using_twodigit_years,gdate, gboolean)
#define using_twodigit_years (*FUNCTION_NAME(using_twodigit_years
,gdate)()
#else
static gboolean using_twodigit_years = FALSE;
#endif
OK, I see, I think it would be cleaner to do it like this: in gdate.c
the only change would be to have:
GLIB_STATIC (gboolean, using_twodigit_years, FALSE);
and then have the GLIB_STATIC macro defined in some suitable header:
#if defined(__SYMBIAN32__) defined(EMULATOR)
# define GLIB_STATIC(type, name, initvalue) \
PLS(name, type) \
static type PTR_name(void) \
{ \
static type value = initvalue; \
return value; \
}
#else
# define GLIB_STATIC(type, name, initvalue) type name = initvalue
#endif
and then have a preprocessing script that changes all occurences of
identifiers that are seen in GLIB_STATIC() macros to
(*PTR_identiifier) instead, i.e. for instance it would change all uses
of using_twodigit_years to *(PTR_using_twodigit_years) after it sees
the GLIB_STATIC (gboolean, using_twodigit_years, FALSE) in gdate.c
(This is just a quick sketch, no idea if it actually would work in
general, etc.)
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib on Symbian
I am a developer working for Symbian. We have ported glib to the Symbian OS and wish to contribute the changes back to the main codeline. We had talked to Tim Janik and Dave Neary regarding this and they recommended the changes be split up into smaller patches and be submitted to either of bugzilla or the mailinglist. There is one more issue that needs addressing. The Symbian OS emulator does not support global static data in libraries. We found a fair amount of global static data in the code and to work around these, we have symbian specific code inserted within '#ifdef SYMBIAN32' . The problem here is that these changes are peppered throughout the code and rack up nearly 2000 lines of changed code. Without these changes, glib will not work on the Symbian OS emulator. I am looking for your opinions regarding how to handle this particular changeset. Thanks Regards, Ajith ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
