Dong Liu <[EMAIL PROTECTED]> wrote:
> Is GLib type shared lib is supported in prctools-2.0?
Please read the release notes.
> First I can't use it to build GLib since there are no
> utilities 'exportlist' and 'stubgen', after I copy over these two
> from prctool-0.5, then I can build GLib shared lib.
These utilities are somewhat unsatisfactory because the ordinals of the
library's functions will change as new functions are added -- leading to
incompatible revisions of your GLib --, and because the dependence on Perl
is a problem for Windows users. So there is intended to be a facility
in the project definition file to replace exportlist/stubgen, but it's
not implemented yet.
In the meantime, using the exportlist/stubgen utilities from 0.5.0 is
the solution.
> But I can't use it.
GLibs are unsupported in prc-tools 2.0 because the dispatch code (which
is generated in stubgen) linked into your application not only uses %a4
for globals, but also checks whether globals are available by checking
whether %a4 is 0 or not. This check is impossible when globals are being
accessed via %a5. This is the only way I am aware of in which %a5 global
access is inferior to access via %a4. (However, I'm not convinced that
the no globals case ever worked properly anyway.)
By only using GLib functions when your globals are available and changing
stubgen to omit the check and use %a5, you will be able to use your GLib.
I am not sure what the best way to support GLib function calls in the
absence of the invoker's globals is: I suspect it may be necessary to
force the user to invoke the function differently, perhaps via a macro.
Your contributions in this area would be most welcome! You might also
want to look at Michael Sokolov's work in this area (see the archives
of this mailing list).
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
