[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Remaning Dlls
From:       Albert den Haan <oponvybl () umail ! corel ! com>
Date:       2000-08-28 19:28:49
[Download RAW message or body]

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
albertd@corel.com
-- 
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 "postmaster@umail.corel.com".  
The poster's email address is "albertd@corel.com".


[prev in list] [next in list] [prev in thread] [next in thread]