/pidgin/main: 71533f0d5dc0: win32: switch to OBS, update and pus...

[Tomasz Wasilczyk]

2013/4/8 Daniel Atallah <datallah at pidgin.im>:
> On Sun, Apr 7, 2013 at 4:22 PM, Tomasz Wasilczyk
> <tomkiewicz at cpw.pidgin.im> wrote:
>> Changeset: 71533f0d5dc06a5a5ecfc7dee1713a83e184534b
>> Author:  Tomasz Wasilczyk <tomkiewicz at cpw.pidgin.im>
>> Date:    2013-04-07 22:22 +0200
>> Branch:  default
>> URL: https://hg.pidgin.im/pidgin/main/rev/71533f0d5dc0
>>
>> Description:
>>
>> win32: switch to OBS, update and push to runtime-deps package - libenchant, gtkspell, meanwhile, tcl
>
> <SNIP>
>
> Why was the ActiveTcl handling removed?
>
> Will these changes cause the Tcl plugin to now depend on a different Tcl flavor?

OBS provides tcl implementation, so I've just switched the loader
plugin from ActiveTcl to the implementation bundled with our other
dependencies (pointed out below). This approach have advantage of
simplicity: tcl plugins doesn't need any 3rd party software installed
to work under win32.

>> +TCL="${DOWNLOAD_HOST}mingw32-tcl-8.5.9-13.6.noarch.rpm Tcl 8.5.9-13.6 sha1sum:442eaf5e761d59bb527cb1f9f93749ebc13b4367"
>> +TK="${DOWNLOAD_HOST}mingw32-tk-8.5.9-8.6.noarch.rpm Tk 8.5.9-8.6 sha1sum:d0884c56f767f76981ddf7bc6d74d3c47237740a"
>
> Are these binary-compatible with versions that people are likely to
> have (i.e ActiveTcl is the only one that I'm aware of)?

These are /compatible/ (I've checked it with the example plugin). Is
there any need for binary compatibility, since tcl is scripting
language, and we don't use any other installed implementation (update:
at least, if we do the think with dll loading at the end of this
mail)?

>> diff --git a/pidgin/win32/wspell.c b/pidgin/win32/wspell.c
>> --- a/pidgin/win32/wspell.c
>> +++ b/pidgin/win32/wspell.c
>> @@ -87,20 +87,19 @@ static void load_gtkspell() {
>>         g_free(tmp);
>>         g_setenv("PATH", tmp2, TRUE);
>>         g_free(tmp2);
>> +       g_free(tmp);
>
> This looks like a double free.

Yes, my bad. I'll fix it in a minute. I'm curious, why it didn't
crashed, when I tested it.

>> -       tmp = g_build_filename(wpurple_install_dir(), "spellcheck", GTKSPELL_DLL, NULL);
>>         /* Suppress error popups */
>> -       wpidginspell_new_attach_proxy = (void*) wpurple_find_and_loadproc(tmp, "gtkspell_new_attach" );
>> +       wpidginspell_new_attach_proxy = (void*) wpurple_find_and_loadproc(GTKSPELL_DLL, "gtkspell_new_attach" );
>
> The full path for this and various other dynamically loaded things is
> intentional and necessary to protect against a particular class of
> attacks.
> The same applies to the Tcl initialization above.

I've been thinking of it. Anyway, we don't have a path to directory
where our bundle with dependencies was installed. I can figure out a
way to tell nsis to store it at "HKLM\SOFTWARE\Pidgin" (we already
have version number stored here). I could then implement a function
called wpurple_loadproc_trusted(dllname, "funcname"), which would
search for dll only in this directory. Do you think it's a good
solution?

Tomek