About that eeevil library naming decision...
Hello all, I've just had prime evidence of yet another library naming conflict: libuser.so (which is in package libuser-0.32-1). (installed as /usr/lib/libuser.so) Other examples would be libole.so or libavifile.so. So could we please *finally* rename the wine libraries to libwineuser.so or maybe even better libwine_user.so ? Thank you very much... Yeah, people told me that wine libraries would be in separate directories anyway, so no need for that naming. But believe me, I HATED that decision from day 1. Packagers simply won't always choose a separate directory for wine libraries. (especially for "global" installs without a wrapper script) Thus there'll be lots of trouble for some people. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Some more information: Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the naming scheme. That'd be pretty reasonable and cleaner/better than the current approach IMHO, as it'd clearly separate core/dll functionality in a good way. Also, there'll always be global installs with wine library paths added to /etc/ld.so.conf. How would you avoid conflicts then with equally named libraries in other /etc/ld.so.conf paths ?? Further, a lot of other projects do the very same thing, probably to avoid the mess we're experiencing now in the first place: libgtk, libgimp, libgphoto_ libgnome, libvorbis, libgdk, ... (which also results in pretty long names, so this isn't really an argument for wine library naming any more) Now please tell me why this *shouldn't* be done. And I think you better had some real reasons for that... OK, who thinks that this is a good thing to do ? Who doesn't ? I'd certainly write that mega patch converting Wine to this naming scheme. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:
Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the naming scheme. That'd be pretty reasonable and cleaner/better than the current approach IMHO, as it'd clearly separate core/dll functionality in a good way.
The separation will be done by putting dlls in a separate directory (usually /usr/lib/wine) which is a lot cleaner than creating 150 files in /usr/lib, no matter how they are named.
Also, there'll always be global installs with wine library paths added to /etc/ld.so.conf. How would you avoid conflicts then with equally named libraries in other /etc/ld.so.conf paths ??
Wine dll path won't be added to /etc/ld.so.conf. But in any case the plan is that dlls in /usr/lib/wine are named without the lib prefix to make it clear you can't link to them.
OK, who thinks that this is a good thing to do ? Who doesn't ?
I don't. If you really want to do something about it, consider working on dll separation so that we can finally put all dlls in the right place. -- Alexandre Julliard julliard(a)winehq.com
On Mon, Feb 25, 2002 at 11:47:31AM -0800, Alexandre Julliard wrote:
Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:
Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the naming scheme. That'd be pretty reasonable and cleaner/better than the current approach IMHO, as it'd clearly separate core/dll functionality in a good way.
The separation will be done by putting dlls in a separate directory (usually /usr/lib/wine) which is a lot cleaner than creating 150 files in /usr/lib, no matter how they are named.
But some people DON'T separate it. (for various reasons, which might only be evident in the future) Furthermore, having tons of hopelessly chaotically named libraries is everything but clean.
Wine dll path won't be added to /etc/ld.so.conf. But in any case the plan is that dlls in /usr/lib/wine are named without the lib prefix to make it clear you can't link to them. Fact is that a LOT of people/distributors still add it to ld.so.conf.
Anyway, I didn't know about the "omit lib" plan yet. That'd actually be a rather usable choice, since that'd really eliminate the conflicts. But are you sure that you can just omit the lib prefix on *all* supported environments ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:
But some people DON'T separate it. (for various reasons, which might only be evident in the future)
If people want to break the directory structure that's their choice, but I don't see a valid reason for doing it.
Fact is that a LOT of people/distributors still add it to ld.so.conf.
Nobody adds it to ld.so.conf since the directory doesn't exist at the moment. People add /usr/local/lib or whatever the lib directory is, and that will still be correct with the new scheme.
But are you sure that you can just omit the lib prefix on *all* supported environments ?
If there are environments that don't support it they can use some other scheme. I don't think any Unix platform would have the problem. -- Alexandre Julliard julliard(a)winehq.com
On 2002.02.25 15:05 Andreas Mohr wrote:
On Mon, Feb 25, 2002 at 11:47:31AM -0800, Alexandre Julliard wrote:
Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:
Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the naming scheme. That'd be pretty reasonable and cleaner/better than the current approach IMHO, as it'd clearly separate core/dll functionality in a good way.
The separation will be done by putting dlls in a separate directory (usually /usr/lib/wine) which is a lot cleaner than creating 150 files in /usr/lib, no matter how they are named.
But some people DON'T separate it. (for various reasons, which might only be evident in the future)
Furthermore, having tons of hopelessly chaotically named libraries is everything but clean.
Andi... if Wine DLLs eventually go into a /usr/lib/wine then you cannot possibly argue that anybody in their right mind would put them in /usr/lib. I don't see any distributors putting the libraries in /usr/lib/xmms/* into /usr/lib, do you?
Wine dll path won't be added to /etc/ld.so.conf. But in any case the plan is that dlls in /usr/lib/wine are named without the lib prefix to make it clear you can't link to them. Fact is that a LOT of people/distributors still add it to ld.so.conf.
We are not talking about libraries that people would want to link to in the normal UNIX sense. We are basically talking about what amounts to "plugins" for the wine emulator (in some sense). Therefore when wine is able to load the DLLs from a specific wine library directory then nobody is going to install them into /usr/lib, if they do then that is their own damn problem for being stupid.
Anyway, I didn't know about the "omit lib" plan yet. That'd actually be a rather usable choice, since that'd really eliminate the conflicts.
But are you sure that you can just omit the lib prefix on *all* supported environments ?
Does it really matter? If they are in a seperate plugins type directory then who cares if the "lib" is ommitted or not. -Dave
On Mon, 25 Feb 2002 21:37:21 -0500 David Elliott <David Elliott <dfe(a)tgwbd.org>> wrote: [SNIP]
Andi... if Wine DLLs eventually go into a /usr/lib/wine then you cannot possibly argue that anybody in their right mind would put them in
Never underestimate the power of stupidity and naievity, especially as projects like 'Linux from scratch' are getting popular.
/usr/lib. I don't see any distributors putting the libraries in /usr/lib/xmms/* into /usr/lib, do you?
-- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration
On Mon, Feb 25, 2002 at 11:47:31AM -0800, Alexandre Julliard wrote:
Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:
Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the naming scheme. That'd be pretty reasonable and cleaner/better than the current approach IMHO, as it'd clearly separate core/dll functionality in a good way.
The separation will be done by putting dlls in a separate directory (usually /usr/lib/wine) which is a lot cleaner than creating 150 files in /usr/lib, no matter how they are named.
Presumably there is no reason not to give these files a different suffix as well? Then there will be even less confusion :-) I presume that if an ELF file has a 'needed' entry of "wine/xyz.abc" the dynamic linker will correctly locate the dependant library. But for most of wine, they are not ELF and wine does all the loading anyway. David -- David Laight: david(a)l8s.co.uk
participants (5)
-
Alexandre Julliard -
Andreas Mohr -
David Elliott -
David Laight -
Keith Matthews