wine users - Feb 2001 - Installling more than one wine version (fwd)

On Thu, 8 Feb 2001, Rick Moulton wrote:
> It seems that Corel Office 2000 for linux will not run on any version of
> wine later that the 1022999 ver..  Seems Any newer version causes an
> "ERROR no 6 and  stuff about not being able to find
"wordperfect" or
> quattropro executuables, and also saying it is a wine error.
> 	My question, is there a way to install multiple versions of wine by
> changing makefile presets or destination directories? (some details
> would be be nice here.)
> 	There several windoze programs on my machine that seem to work fine in
> an older version, but wont with an upgrade
It can get a little messy, since Wine is based on shared libraries.
Maybe someone who knows configure better than I could work out a
versioned soname to keep so the executable[s] would find the right
winelib version.  From the source, you can control where Wine installs
to with ./configure --prefix=/where/you/like

Maybe, since we are now using -rpath, that would be enough to keep newer
versions straight; for older versions you might need LD_LIBRARY_PATH to
help it find the right library version.

The current Wine will respect WINEPREFIX (you might well want a
different config and registry files) and WINEDLLPATH.  (man wine)

of course, you can choose the executable by calling it by its absolute
path name.

It's sort of a moving target you picked on.

Lawson

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.
---cut here



________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

On Thu, 8 Feb 2001 13:33:38 -0500 (EST), lawson_whitney@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.
>
Was Corel using .so at all, actually ? I think they forked
when Wine was a big executable.

Gerard

lawson_whitney@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@transgaming.com