I don't know whether I should suggest something here, but be free to clarify me the right way, or place to do it, if I shouldn't.
I'm updating a WTL application that uses libgaim 1.5 to new version 2.0 of this library.
Both, the application and libgaim (with associated plugins and protocols), must be build using Microsoft Visual Studio 2003 .Net.
On some places, mainly on ICQ protocol implementation, I found "standard C" calls malloc/free and "glib" calls g_malloc/g_free being used to allocation/deallocation purposes.
When the pair association is maintained, like g_free being used with allocations made through g_malloc, and on the same way to "standard C" calls, I have no problems at all.
But, when a mix of calls happens, my application usually raises an exception.
If I'm not wrong, this happens because different libraries are used during allocation/deallocation process through glib and "standard C". Glib is linked against "msvcrt.dll", while the rest of binaries are build by default against the updated version "msvcr71.dll".
So, I would like to suggest the total adoption (in the case of ICQ protocol, mostly), of glib to allocation/deallocation processes.
Thank's and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As soon as I can update the version I'm working with (I'm still with libgaim beta 6), I intend to post the patches here...
Unfortunately, I can't do it for now...
Thank's and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank's a lot for your post Daniel!
This is great news.
I was thinking whether we should jump to latest release of libgaim (now libpurple) on last days, and I think we must do it now, before anything else.
We are having problems here that could have being solved by last fixes (like the file transfer problem on Jabber protocol, that we have already found as fixed on last updates).
So I think this is the best alternative on this moment.
Thank's a lot again, and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1- A release implies on a new version of bz2 compressed file with sources becaming available on pidgin site ?
2- Will this changes be available on Sourceforge Subversion repository, or only on Monotone path informed ?
3- Has Pidgin source code versioning started on Monotone (i.e. is there no reference of pidgin (libpurple) on Sourceforge svn repository) ? Because, I couldn't find a path where the updated lib path "libpurple" was present.
Best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello there!
I don't know whether I should suggest something here, but be free to clarify me the right way, or place to do it, if I shouldn't.
I'm updating a WTL application that uses libgaim 1.5 to new version 2.0 of this library.
Both, the application and libgaim (with associated plugins and protocols), must be build using Microsoft Visual Studio 2003 .Net.
On some places, mainly on ICQ protocol implementation, I found "standard C" calls malloc/free and "glib" calls g_malloc/g_free being used to allocation/deallocation purposes.
When the pair association is maintained, like g_free being used with allocations made through g_malloc, and on the same way to "standard C" calls, I have no problems at all.
But, when a mix of calls happens, my application usually raises an exception.
If I'm not wrong, this happens because different libraries are used during allocation/deallocation process through glib and "standard C". Glib is linked against "msvcrt.dll", while the rest of binaries are build by default against the updated version "msvcr71.dll".
So, I would like to suggest the total adoption (in the case of ICQ protocol, mostly), of glib to allocation/deallocation processes.
Thank's and best regards!
If you have an example of such a mismatched allocation and freeing, supply a patch and we'd be glad to apply it.
As soon as I can update the version I'm working with (I'm still with libgaim beta 6), I intend to post the patches here...
Unfortunately, I can't do it for now...
Thank's and best regards!
I actually committed a fix for this yesterday. liboscar will now use the glib allocation and freeing functions exclusively to avoid this issue.
Thank's a lot for your post Daniel!
This is great news.
I was thinking whether we should jump to latest release of libgaim (now libpurple) on last days, and I think we must do it now, before anything else.
We are having problems here that could have being solved by last fixes (like the file transfer problem on Jabber protocol, that we have already found as fixed on last updates).
So I think this is the best alternative on this moment.
Thank's a lot again, and best regards!
Hello Daniel,
Could you please post the place from where I can download the source code for latest release, including the fix we have pointed above ?
Thank's!!!
There hasn't yet been a release with the fix (I only just made the change yesterday!).
The plan is to release 2.0.1 tomorrow.
The source is in monotone, see the following instructions:
http://developer.pidgin.im/wiki/UsingPidginMonotone
Thank's again for you post.
I still have some questions about that:
1- A release implies on a new version of bz2 compressed file with sources becaming available on pidgin site ?
2- Will this changes be available on Sourceforge Subversion repository, or only on Monotone path informed ?
3- Has Pidgin source code versioning started on Monotone (i.e. is there no reference of pidgin (libpurple) on Sourceforge svn repository) ? Because, I couldn't find a path where the updated lib path "libpurple" was present.
Best regards!
Yes, a release implies a source new tarball.
The changes will never make it to the Sourceforge svn repository - it isn't being used anymore.
All of the work to make gaim into pidgin took place in the monotone repository.