On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote:
Hello all,
one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ?
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for not doing this ? I can't think of any...
If this is a good thing, then we should do this NOW, not
when it's too late.
I agree, if we do we must do it before Wine 1.0.
The current drawbacks are just too much IMHO.
Why not put them in /usr/lib/wine/ as suggested by the FHS?
I second that.
However I would suggest that we also put symbolic link to the corresponding files in /usr/lib following the suggested naming scheme libwineXXX or something similar.
Other suggestions. 1. libwine_XXX 2. libwin32_XXX
Personal think I would prefer the libwin32_XXX variant because in theory use could have other implementations of the Windows API than Wine and that is of no pariticular concern of the programmer eventhough of course it is for the administrator of the system.
If a programmer wanted to use say Win32 filehandling functions he could, in theory, just link with libwin32_kernel32 and be done with it. Something (in our case Wine) provides it, but he doesn't care what. This is currently not possible IIRC but it might be in the future.
Additionally is makes it possible to support both Win32 and Win64 on 64bit systems like Itanium by having libwin64_XXX.
This would make it easier to properly link to the files in Winelib application.
This means you can do gcc -o foo foo.c -lwin32_ole instead of doing gcc -o foo foo.c -I/usr/lib/wine -lole that might cause problems if libole.so exist in another path.
Also not that this also makes it harder to link to the DLL:s that are not supposed to be use with Winelib by misstake, like the Win16 DLL:s since we can choose to not provide symbolic links to them.
-
Patrik Stridvall