We (Corel) ducked this issue by installing our .so's and .dll's to nonstandard
directories to we couldn't trample a wine-hq installation if
on existed (or arrived later).
This has the joyous side effect of hiding the version skew between the corelwine's
released with WPO2000 and DRAW.
Check out our DRAW and Paint launching shell script (/usr/bin/* files are symlinks to
it) for where we prefix LD_LIBRARY_PATH to point to the proper library directory.
This allowed us to stick with the cannonical names (I hate to waste your work so
far!:) and co-exist with other wine installations.
Albert.
> Michael Cardenas wrote:
>
> Hello again.
>
> I'm working on renaming our versions of the wine libs, so that the corel and
>deneba installations do not break each other. My question is, what is the right way
>to do this?
>
> I have been working for a week on changing shell32.dll to cv7shell32.dl, or
>really changing libshell32.so to libcv7shell23.so
>
> I did it by doing the following:
> 1. changing the directory name from shell32 to cv7shell32
> 2. modifying the following files to refer to cv7shell32
> /wine/Makefile.in
> /wine/dlls/Makefile.in
> /wine/dlls/cv7shell32/Makefile.in
> /wine/dlls/cv7shell32/shell32.spec
> /wine/configure
> (applicationDir)/.winerc
> 3. changing all attempts to LoadLibrary("shell32.dll") to
>LoadLibrary("cv7shell32.dll")
>
> but it still didn't work! Not only did the library not get loaded, but other
>libraries also did not load after changing the name of the lib.
>
> I suspect this is going to be a problem for anyone else who is going to make
>winelib applications. I think it's so common that we should have a configure option
>for it.
Our "configure option" is to build the libraries into an out-of-the-way place. Look
at the existing --prefix option of configure. IIRC we used
--prefix=/usr/lib/corel/wine-$application. In the
future we will use --prefix=/opt/corel instead to match the latest version of the file
system standard.
Another potential gotcha is the location and name of the .winerc file and the .wine
directory. Alexandre seems to have some ideas on how to evolve Wine-hq beyond the
current two environment variable
approach (WINEPREFIX and WINE_INI) to have the .winerc reside *in* the .wine directory
so one environment variable can indicate what configuration to use.
I hope that any evolution could include a two location approach so that we can have a
master winerc file somewhere visible to all that users could override in their .wine
directories if they wanted.
I might end up coding this RSN before Alexandre gets it right in a way that will be
hard for us to migrate to :)
> What are your thoughts or suggestions on this? Any help would be greatly
>appreciated.
>
> Thank You,
> Michael Cardenas
> Deneba Software
Let's work together on this one too!
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
[EMAIL PROTECTED]
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
