dequis / msn-pecan

Automatically exported from code.google.com/p/msn-pecan
GNU General Public License v2.0
0 stars 0 forks source link

Patch: Compile with old GLib versions (2.12 and below) #304

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
As some may (or may not) know here, the official Pidgin binaries are linked 
aganist the ice-age GLib 2.12 (which was released somewhere in 2006). Although 
most users are using much, MUCH newer versions of GLib, some of us are stuck in 
enviroments with the old 2.12 library (a notoriously known case is CentOS 5), 
and updating it is a quite complex endeavour.

Myself, i'm still using Fedora Core 6 (yes, feel free to call me "OLD!"), 
HOWEVER, Pidgin still provides binaries for it, even for the very latest 
versions, and this is because of the above situation: they still use the GLib 
2.12 API. I recently came to know about the msn-pecan project since i'm also 
got tired of fighting with the countless MSN protocol bugs on the mainline 
Pidgin, however, while it installed fine on my Win32 system, it failed to build 
on my FC6 box.

After reading the sources, i've found the usage of the following GLib functions:
- g_strcmp0
- g_timeout_add_secconds
- g_once_init_enter
- g_once_init_leave
...all of them added on GLib 2.14.

Attached you will find a patch that fixes msn-pecan 0.1.2 to link aganist GLib 
2.12. A few warnings first:

- It *seems* to work, but i've only tested for connecting, doing some basic 
stuff with my contact list, messaging a bit, dealing with avatars and user 
states... but then i haven't tested features like file transfers.
- My knowledge about the GLib API is pretty much zero (and i'm not a great C 
developer), yet i know at least how to read the API docs :P - g_strcmp0 and 
g_timeout_add_seconds were trivial fixes, but i found no clean replacements for 
g_once_init_*, so you may find my fix VERY hacky. So feel free to hack my patch 
to do the proper thing for those of us stuck on old GLib...

Hope that someone finds this useful, and maybe even it finds its way to the 
main codebase...

Original issue reported on code.google.com by tom...@gmail.com on 12 May 2011 at 9:10

Attachments:

GoogleCodeExporter commented 9 years ago
Have you looked at the 'backwards' branch in github? It should have 
compatibility for 2.14. Not sure for 2.12.

Original comment by felipe.contreras on 12 May 2011 at 9:40

GoogleCodeExporter commented 9 years ago
Just checked out that branch, and indeed, it targets 2.14, not 2.12 - it uses 
the same new functions (except for g_strcmp0).

Original comment by tom...@gmail.com on 13 May 2011 at 5:20

GoogleCodeExporter commented 9 years ago
Can you make your patch on top of that branch?

Original comment by felipe.contreras on 13 May 2011 at 7:00

GoogleCodeExporter commented 9 years ago
There you have: patch for backwards branch.

- Added the missing g_timeout_add_seconds
- Removed the usage of the g_once_init_* (again, quite hacky, but seems to work 
nicely)

Did a bit more of testing, this time including file transfers.

Original comment by tom...@gmail.com on 13 May 2011 at 8:52

Attachments:

GoogleCodeExporter commented 9 years ago
Cool. I have used this as a reference to create a more proper verison.

Original comment by felipe.contreras on 14 May 2011 at 3:39

Attachments:

GoogleCodeExporter commented 9 years ago
I also have improved the way backwards compatibility is implemented; branch 
'backwards' updated.

Original comment by felipe.contreras on 14 May 2011 at 3:47

GoogleCodeExporter commented 9 years ago
Nice, thanks!

Just a litte thing: on GLib 2.12, you link aganist gobject, not gio (which does 
not exist there).

Original comment by tom...@gmail.com on 14 May 2011 at 5:05

GoogleCodeExporter commented 9 years ago
Oops. I did test that branch with GLib 2.12, and I saw the right includes with 
pkg-config, but I guess it picked gio-2.0.pc from my system, which dependend on 
glib-2.0.pc of my temporary install.

Fixed.

Original comment by felipe.contreras on 14 May 2011 at 5:13

GoogleCodeExporter commented 9 years ago
Is the current solution good enough? Or does something else needs to be done?

Original comment by felipe.contreras on 4 Aug 2011 at 4:47

GoogleCodeExporter commented 9 years ago
So far, it's working smoothly, and haven't noticed any deal-breaker issues (or 
any issue at all), so i think that we call this FIXED for now :)

Original comment by tom...@gmail.com on 4 Aug 2011 at 5:33

GoogleCodeExporter commented 9 years ago
Cool :)

Original comment by felipe.contreras on 4 Aug 2011 at 6:03