Opened 9 years ago

Closed 9 years ago

#7875 closed defect (duplicate)

Pidgin should add Aspell location to its App Paths Windows registry entry

Reported by: dcitron Owned by: datallah
Milestone: Component: winpidgin (gtk)
Version: 2.5.3 Keywords: aspell crash
Cc:

Description

Many people have experienced Win32 Pidgin crashing on startup due to Aspell DLL conflicts (see ticket:7853 and ticket:7750 for examples).

Pidgin is already creating a registry key at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pidgin.exe.

All it need do is append the location of the correct Aspell DLL to the "Path" key and crash-free behavior is guaranteed. This location can be copied from the "Path" key at HKLM\SOFTWARE\Aspell if present.

Change History (7)

comment:1 follow-up: Changed 9 years ago by rekkanoryo

  • Component changed from unclassified to winpidgin (gtk)
  • Owner changed from lschiere to datallah

I'm not so sure this is as simple as you seem to think it is. I'm also not of the opinion we should be fixing inherent brokenness in Windows, but I'll leave that up to Daniel to decide.

comment:2 in reply to: ↑ 1 Changed 9 years ago by dcitron

Replying to rekkanoryo:

Thanks for considering this. Windows has a couple of mechanisms for dealing with this issue:

  1. App Paths
  2. LoadLibraryEx called with the full path to the DLL and the flag LOAD_WITH_ALTERED_SEARCH_PATH
  3. Side-by-side assemblies

The solution I proposed initially worked for me on my particular installation. If that solution is rejected, then please consider instead implementing the second solution. I believe you are already reading the full path to the Aspell DLL from HKLM\SOFTWARE\Aspell, correct? If so, according to the documentation, calling:

   LoadLibraryEx(pathFromAspellKey, NULL, otherFlags | LOAD_WITH_ALTERED_SEARCH_PATH);

should do the trick, no?

Many operating systems have issues dealing with multiple versions of shared libraries. In my experience, LD_LIBRARY_PATH is hardly any better unless you set it per-application, and that's the same idea as App Paths.

comment:3 follow-up: Changed 9 years ago by datallah

To be honest, the solution I'd prefer would be for php not to ship an incompatible dll with the same name.

An AppPath could help with this issue, but only if a compatible version of aspell is actually present, so it really isn't an ideal solution. It also wouldn't work for the portable version.

LoadLibraryEx also could be used to deal with this, but that would also complicate the portable version situation.

Side-by-side assemblies aren't useful to us here, we're not using MSVC, let alone a new enough version.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 9 years ago by dcitron

Replying to datallah:

To be honest, the solution I'd prefer would be for php not to ship an incompatible dll with the same name.

Now you're asking too much :-P

Is there some aspect of the incompatible version that Pidgin could detect and simply fail-and-continue instead of crash?

comment:5 in reply to: ↑ 4 ; follow-up: Changed 9 years ago by datallah

Replying to dcitron:

Replying to datallah:

To be honest, the solution I'd prefer would be for php not to ship an incompatible dll with the same name.

Now you're asking too much :-P

I don't think so :); it is an easy thing to fix and what is being done is clearly the wrong thing to do. (Granted this is only an issue for people who pollute their system path with the php path, but I guess that is a common thing to do for the few people that use it on windows).

Is there some aspect of the incompatible version that Pidgin could detect and simply fail-and-continue instead of crash?

I'm sure that we could do something ugly like detecting the specific aspell binary we want, but I'd rather not add hacks to detect this one specific DLL Hell instance. I'd be more inclined to add a FAQ entry for the handful of windows PHP users who put it in the path and also use pidgin.

comment:6 in reply to: ↑ 5 Changed 9 years ago by dcitron

Replying to datallah:

Fair enough. In my case, I added my PHP directory to my system PATH so that Apache/PHP could find other PHP DLLs that it required (e.g. libmysql.dll). In fact, the official PHP documentation instructs users to add the PHP install directory to their system PATH to use MySQL, hence the Pidgin problems.

However, I agree that a better solution would be for Apache/PHP users to set the PATH for Apache only (perhaps using App Paths) or alternately to copy the required PHP-related DLLs to a separate folder for PATH inclusion.

In any case, a Pidgin FAQ entry would save other users some debugging time :-)

comment:7 Changed 9 years ago by datallah

  • Resolution set to duplicate
  • Status changed from new to closed

Closed as duplicate of #7750.
I added a FAQ entry.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!