Installling more than one wine version (fwd)

[Gavriel State]

lawson_whitney at juno.com wrote:
> Oh - did Corel hack the sonames on their version?  That would sure stop
> it working it you install current dll's and winelib _in place of_ the
> original ones.
> 
> You can find out by doing ldd on an exectable or library.  The sonames
> it wants are on the left; the files the dynamic linker thinks will make
> it happy are on the right.
> 
> Constants aren't, and variables won't.

The weird thing here is that the Corel WPO launcher scripts are specifically
designed so that they can co-exist with another distribution of Wine.  They
store the config info in the ~/.wpo2000rc, and the registry, etc, in ~/.wpo2000/.

The WPO version of Wine is the old monolithic wine binary, that shouldn't care
about the library paths.

And finally, the launcher scripts for WPO use a full path to find the Wine
binary in /usr/lib/corel/wine/bin/wine.  

[Gav does some digging using LD_DEBUG]

Aha - it looks like the problem is that the WPO office version of Wine is 
looking for OLE32.DLL.  Corel's Wine is expecting this not to be found, 
so that the apps can go merrily along their way without OLE, I guess.  
With the latest WineHQ rev installed, ld.so finds the new implementation 
of libole32.so instead.  When WP tries to use this, boom.

So, a quick, hacky fix to the problem is to edit your ~/.wpo2000rc file
and add a line to the DllOverrides section that reads:
  ole32=buildin

That should prevent CorelWine from loading the wrong DLLs.  

This allows me to run WPO on my machine, but LD_DEBUG is showing that
it's still finding the new libwine.so and loading it.  I'm not really
sure why that's happening, or whether it is doing any harm, but it
might be a problem, as might other newly implemented Wine DLL.  

PhotoPaint still seems broken with another Wine installed though...

-Gav

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com