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
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
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
On Fri, Feb 23, 2001 at 01:29:29PM +0100, Marcus Meissner wrote:
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
On Fri, 23 Feb 2001, Marcus Meissner wrote:
Why not put them in /usr/lib/wine/ as suggested by the FHS?
That's what I've been doing for the FreeBSD port for ages.
Welcome to the club! :-)
Gerald
--
Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/
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...
Having got Java running properly under Wine 20010216, now I return to the
application that caused me to start looking at Java, Websphere Studio.
I managed to get it to install with a few non-fatal messages, and it
starts. It is very slow, but my first interest is to get it to work. It
uses
On Fri, 23 Feb 2001, Ove Kaaven 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 doing this?
I can't think of any...
The
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
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
Andreas Mohr [EMAIL PROTECTED] writes:
one thing that occurred to me:
Shouldn't we rename *all* Wine libraries to libwineXXX ?
This was discussed already. The dlls will ultimately reside in
/usr/lib/wine so there won't be any conflict; the libraries that have
to be in /usr/lib already use the
So, this imposes to have the test programs also (compile) and run under
windows... This could even allow (from source code for example) to have
3 test caes :
1/ compiled and running under windows
2/ compiled under windows, but run with wine
3/ compiled as a winelib app
The idea of
Eric Pouech [EMAIL PROTECTED] writes:
Do you really feel like a C compiler is less common than a perl binary
under Windows ? I seriously doubt it...
Anybody can install a perl binary on their machine, while nearly all
Windows compilers are commercial software...
well, the stubs between perl
Alexandre Julliard wrote:
Eric Pouech [EMAIL PROTECTED] writes:
Do you really feel like a C compiler is less common than a perl binary
under Windows ? I seriously doubt it...
Anybody can install a perl binary on their machine, while nearly all
Windows compilers are commercial
Gerald Pfeifer [EMAIL PROTECTED] writes:
I'm leaving for holidays very soon and have to proof-read some 60 exams
before that, so I won't be able to track this down, but perhaps one of
could fix the build failure seen on FreeBSD 4.2?
Perhaps just some incomplete #ifdef ... #endif sequence?
On 23 Feb 2001, Alexandre Julliard wrote:
Perhaps just some incomplete #ifdef ... #endif sequence?
Yep, here's a fix:
Index: scheduler/pthread.c
Yes, that fixes it. Thanks!
Gerald
--
Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/
Group,
Sure Debian handles everything perfectly, and sure other distros do the
same, but this *will* fail at the user level somewhere e.g. if they
want to install the stuff themselves, and e.g. need to uninstall the mess
cleanly again.
(I know my newbies ;-)
The main problem we'll
17 matches
Mail list logo