RE: huge library renaming ?

[Patrik Stridvall]

> On Fri, 23 Feb 2001, Andreas Mohr wrote:
> > 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...
>
> Any reason for doing this?
> I can't think of any...
>
> The Debian packages work perfectly, without any potential for 
> conflict.
> They install the dlls into /usr/lib/wine, do *not* put 
> /usr/lib/wine into
> ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from
> /usr/lib (and Wine's own configure adds rpath stuff last time 
> I looked)

I think the discussion is more about what Winelib applications
in general do (or should do) rather than what Wine (a very
specific Winelib application) does.

Sure Wine uses (or can be made to use rpath), but I'm not sure we
want to require all Winelib applications to do the same.

It would IMHO be much better if a simple Winelib applications just
could add -lwin32_XXX and be done with it.

huge library renaming ?

[Ove Kaaven]

On Fri, 23 Feb 2001, Patrik Stridvall wrote:
> Sure Wine uses (or can be made to use rpath), but I'm not sure we
> want to require all Winelib applications to do the same.

No, the configure script applies rpath to the winelib dlls. The wine
binary itself doesn't use rpath by default.
> It would IMHO be much better if a simple Winelib applications just
> could add -lwin32_XXX and be done with it.

Winelib apps should never link to the .so files using -lXXX. They should
add "import XXX" to the main .spec file and let winelib handle the actual
loading, but never link to the libs directly at the ELF level. At least
that's Alexandre's plan...