Graham Cobb wrote: > More and more applications cannot be built for Maemo just > because they use features in glib introduced after 2.12.12.
[EMAIL PROTECTED] wrote: > Personally I consider this a mistake of those programs. And I also > believe you're wrong. Dave Neary wrote: > For information, the new APIs added in glib between 2.12.x > and 2.16.x are: appreciated > (from > http://mail.gnome.org/archives/gtk-list/2007-August/msg00017.html) > GRegex - an implementation of Perl regexes It's always fun to ask just how pcre is your pcre impl. I work on a web browser. Web browsers can't use pcre because the spec is way too divergent from pcre. :) > GSequence - a list that is implemented using a balanced binary tree I can't imagine millions of applications suddenly using this feature, although I could be wrong :). > g_get_user_special_dir() support for xdg-user-dirs iirc red hat's code for this was contributed to mozilla. But in the maemo context, I'm not sure how valuable/important this is. > (from > http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00 > 022.html) > GIO - a replacement for GnomeVFS (along with gvfs, which has the > back-end implementations) Right, this has been discussed before (I'm well aware of it) > GChecksum - a utility to provide a central implementation of hash > algorithms such as MD5, SHA-1 and SHA-256. As with GSequence, I can't imagine this is used very often. Our "platform" includes some version of openssl (see other parts of this thread), and people could use that. > A full list of the new symbols in 2.14 and 2.16 is here: > 2.14: http://library.gnome.org/devel/glib/stable/ix09.html > 2.16: http://library.gnome.org/devel/glib/stable/ix10.html > > Aside from GIO, which has recently received a big push for GNOME > applications, I don't know if these APIs are in widespread use. That's pretty much what I'd expect. > I'm afraid I don't get your point - are you suggesting that > the correct > way to handle the issue is to install glib 2.16.x alongside > glib 2.12.12? In short, yes. > The GNOME developers are very careful to maintain ABI stability - > normally, 2.16 is a drop-in replacement for 2.12, and you should not > even need to recompile your applications. This I understand. However there's a faulty assumption. There isn't any original compilation of these applications for this platform. As such, it should be possible to divert to alternate libraries during the original compilation. (this could be facilitated by the autobuilders.) Fwiw, I mentioned something about a revert. This stuff is semi public (albeit painful to browse as afaict the svn itself is closed): http://www.mail-archive.com/[EMAIL PROTECTED]/msg04926.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg04973.html > > The community may not be able to replace: > > /usr/lib/libglib-2.0.so.0 > > However it could easily provide: > > /usr/lib/libgobject-2.0.so.0.1400.0 > > /usr/lib/libgthread-2.0.so.0.1400.0 > > /usr/lib/libglib-2.0.so.0.1400.0 > > /usr/lib/libgmodule-2.0.so.0.1400.0 > > If it felt like it. While this would mean you'd have > > multiple glibs on the system, it isn't impossible to do, > > and if you absolutely need it, you could do it. > Interesting - will the latest version of the library be picked up > automatically at runtime by applications, or do they need a recompile? See above, I was positing an original compile that picked a version. > Or is there an application like ld.so.conf which needs to be run to > update symlinks? The alternate approach I mentioned of a secondary directory is something which I'm assuming could be abused by playing with /etc/ld.so.conf Note that on my device /etc/ld.so.conf has: /usr/lib/microb-engine /usr/lib/microb-engine/components Which implies that packages are allowed to play with it to some extent (I believe the fact that microb - which I work on - is playing with it is probably a bug, but you can ignore that for now). Afaict according to /sbin/ldconfig -v -N -X (as user, not root), microb-engine will be searched first. > I imagine it would be a list of applications plus version numbers, Sure, obviously listing applications which had 20 versions that worked, and an experimental version no one had ever heard of which happens to require the library would be a bad idea. > and would perhaps include applications targeting GNOME 2.20 and later. Sure. > I did a little experiment on my recently updated Ubuntu 8.04 laptop: But you didn't indicate the result, such a tease :) > Try it for yourself. This should also work on 7.10. I actually just gave away my ubuntu 7.10 box yesterday. > The results for me were that most GNOME applications on my system are > consuming 2.14 or 2.16 glib interfaces. Presumably for gio. I will note that gio and this entire abi discussion was mentioned in this mailing list many months ago. It shouldn't be a surprise: http://www.mail-archive.com/maemo-developers@maemo.org/msg14331.html Someone actually kindly provided a gio thing for you: http://www.mail-archive.com/maemo-developers@maemo.org/msg14310.html So if you're in a hurry to help people use gio on chinook/diablo, I'd suggest you thank Philip Van Hoof and work on packaging it. > Of course, these are the full desktop versions, and not the > maemo ports. Of course. I know of one such application (baobab) which is trying to move to gio. I know because I was trying to help paolo borelli a few days ago. fwiw, I'm not actually opposed to gio, however, mozilla (actually this was probably Red Hat), Nokia (this is basically a couple of people in my group, calling it Nokia is probably inappropriate) and myself have all invested non-trivial (i.e., days or weeks instead of just hours) amounts of time/money/effort in gnome-vfs (which I learned to hate; and, as I said in the other thread, am glad to see go the way of the dodo). I'm sure someone will eventually contribute gio for mozilla, but mozilla runs on a number of platforms and I'm sure some don't include gio today and probably won't before 2010, so I won't be rid of it for a while. the only system requirements I can easily find are http://www.mozilla.com/en-US/firefox/system-requirements which currently are for Firefox 2.0 and they don't list a glib requirement. http://www.mozilla.com/en-US/firefox/system-requirements-v3.html is the equivalent for Firefox 3.0, but I think it's wrong on a couple of points. Do note that historically gnome-vfs in mozilla was an optional component so if your system didn't support it, you could certainly use mozilla. Note that the reason I was working on gnome-vfs support most recently for mozilla is because the maemo platform uses gnome-vfs to talk to obex. Sadly, afaict this glue is closed. I'm having a hard time figuring out if gio supports obex. If someone wants to perform a useful experiment, setup glib2.x (a version w/ gio), void the seal on your application manager and install it on your device. Try using a gnome application to interact w/ a phone using gio. If it works, report that it works. If it doesn't, find out why. Obviously if gio-obex doesn't work well enough to replace the gnomevfs stuff used in chinook (or diablo, which again is basically chinook) then that means that it really isn't ready. http://opensolaris.org/jive/thread.jspa?messageID=211105 seems to indicate gnome 2.22 regresses whatever obex support might be available (which is obviously not a good start). The browser itself uses gnome-vfs for bookmarks w/ a psuedo datasource. Afaiu, the rest of the platform uses gnome-vfs for smb and upnp access. I suppose since gnome isn't actually removing gnome-vfs it isn't as big of an issue, however from a qa perspective, it's a feature that would be entirely untested for the platform, and qa will always refuse to allow such an addition, even if some other qa says "oh yeah, it should work on some entirely unrelated environment with much newer compilers and a different memory architecture, and ... And ... And ...." OTOH, gnome basically stopped supporting gnome-vfs, which means someone at Nokia had to (this is still cheaper than porting all the applications to gio). Someone just made a fix for something relating to gnome-vfs for me today (* this may have been some other integration layer and not technically gnome-vfs, but ...). And again, the goal was for diablo to be compatible w/ chinook.... Using a different glib w/ a totally different feature set means that it really isn't. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
