-- Original message --
From: Alexandre Julliard <[EMAIL PROTECTED]>
> Detlef Riekenberg <[EMAIL PROTECTED]> writes:
>
> > On Do, 2007-04-26 at 13:42 +, Ben Taylor wrote:
> >
> >
> >> if [ ! `which wine` ]
> >>
> >
> > data=`which wine`
> > if [ -n "$dat
Detlef Riekenberg <[EMAIL PROTECTED]> writes:
> On Do, 2007-04-26 at 13:42 +, Ben Taylor wrote:
>
>
>> if [ ! `which wine` ]
>>
>
> data=`which wine`
> if [ -n "$data" -a -x "$data" ]
> then
> # found wine
> WINEINSTALLED=yes
> else
> echo "Could not find wine on your system. Ru
On Do, 2007-04-26 at 13:42 +, Ben Taylor wrote:
> if [ ! `which wine` ]
>
data=`which wine`
if [ -n "$data" -a -x "$data" ]
then
# found wine
WINEINSTALLED=yes
else
echo "Could not find wine on your system. Run wineinstall as root to
install wine"
echo "before re-running win
Ran into this error after building wine again. Not sure why I haven't seen
this before, but:
tools/wineinstall: line 272: [: too many arguments
which translates to this line:
if [ ! `which wine` ]
On Solaris, if I do "which wine", I get a
no wine in (long list of path
Hi,
I don't know when it started and if found I wasn't able to reproduce,
but this is the message I sometimes get during a tools/wineinstall on a
clean cvs install:
Configuring Wine for a no-windows install in /data/wine-c...
err:dplay:DPLAYX_ConstructData : unable to map static
On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
> Sorry, didn't help.
>
> I'm going to try Rob's suggestions now.
Right, Alexandre just clued me in that anonymous mmaps are always zerod.
Nice theory, but no cigar this time. I've been able to reproduce the bug
(sometimes) and am narrowing it
On Thu, 2005-01-20 at 20:17, Mike Hearn wrote:
> On Thu, 20 Jan 2005 19:36:27 +0100, Paul Vriens wrote:
> > When I do the same change now, the X Error is gone as well. Does this
> > give you a clue?
>
> Could you try this patch please?
>
> --- dlls/ntdll/thread.c (revision 109)
> +++ dlls/ntdll/
Paul Vriens wrote:
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
If it's heap corruption then it could well depend on the order of
allocations, so it could be timing dependent.
I've attached a patch that poisons the apartment structure after when it
is freed so that hopefully any use-aft
On Thu, 20 Jan 2005 19:36:27 +0100, Paul Vriens wrote:
> When I do the same change now, the X Error is gone as well. Does this
> give you a clue?
Could you try this patch please?
--- dlls/ntdll/thread.c (revision 109)
+++ dlls/ntdll/thread.c (local)
@@ -73,6 +73,7 @@ static TEB *alloc_teb( ULON
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
> If it's heap corruption then it could well depend on the order of
> allocations, so it could be timing dependent.
> I've attached a patch that poisons the apartment structure after when it
> is freed so that hopefully any use-after-free will b
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
> If it's heap corruption then it could well depend on the order of
> allocations, so it could be timing dependent.
> I've attached a patch that poisons the apartment structure after when it
> is freed so that hopefully any use-after-free will b
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
> Paul Vriens wrote:
>
> >On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
> >
> >
> >>On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
> >>
> >>
> >>>Paul Vriens <[EMAIL PROTECTED]> writes:
> >>>
> >>>
> >>>
> and part of a
Paul Vriens wrote:
On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
Paul Vriens <[EMAIL PROTECTED]> writes:
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
oxid 80009
Looks li
On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
> On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
> > Paul Vriens <[EMAIL PROTECTED]> writes:
> >
> > > and part of a trace:
> > >
> > > 0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
> > > oxid 80009
> >
> > Looks
On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
> Paul Vriens <[EMAIL PROTECTED]> writes:
>
> > and part of a trace:
> >
> > 0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
> > oxid 80009
>
> Looks like some sort of heap corruption, the apartment pointer is
> susp
Paul Vriens <[EMAIL PROTECTED]> writes:
> and part of a trace:
>
> 0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460,
> oxid 80009
Looks like some sort of heap corruption, the apartment pointer is
suspiciously similar to the bad contents of the x11drv window
structure.
> I
On Wed, 2005-01-19 at 16:53, Alexandre Julliard wrote:
> "Paul Vriens" <[EMAIL PROTECTED]> writes:
>
> > doing a tools/wineinstall on a clean system yields in an X-Error.
>
> What's the X error?
The error:
(default is /home/paul/.wine/drive_c) /data/w
"Paul Vriens" <[EMAIL PROTECTED]> writes:
> doing a tools/wineinstall on a clean system yields in an X-Error.
What's the X error?
--
Alexandre Julliard
[EMAIL PROTECTED]
Paul Vriens wrote:
Hi,
doing a tools/wineinstall on a clean system yields in an X-Error.
Doing:
winedbg rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128
wine.inf
gives:
..
Wine-dbg>bt
Backtrace:
=>1 0x00abec49 (0x00a6d7f4)
2 0x00656d76 _XcmsSine+0xe6 in x11drv (0x00a6d8
Hi,
doing a tools/wineinstall on a clean system yields in an X-Error.
Doing:
winedbg rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128
wine.inf
gives:
..
Wine-dbg>bt
Backtrace:
=>1 0x00abec49 (0x00a6d7f4)
2 0x00656d76 _XcmsSine+0xe6 in x11drv (0x00a6d818)
3 0x00
Bon soir Vincent, dear all,
Vincent Béron schrieb:
>That's because it's unable to determine how it was installed in the
>first place, and where the files are located. The "wine" program itself
>is usually easy to find, but not necessarily so for the dlls and other
>installed files.
>
>rpm -e, the
Le mar 07/12/2004 à 21:21, Christian Britz a écrit :
> Dear all,
>
> the script tools/wineinstall suggest to uninstall wine first if you
> update an existing installation.
>
> This makes senses but it is uncomfortable that the script doesn't offer
> the option to do tha
Dear all,
the script tools/wineinstall suggest to uninstall wine first if you
update an existing installation.
This makes senses but it is uncomfortable that the script doesn't offer
the option to do that for the user. You always have to su before
installing a new version
Thx
Christian
Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> what about the case when ~/.wine/dosdevices exists but is empty?
I don't think we need to worry about that, this shouldn't happen in
normal use.
> PS eghm, should it be bad for wineinstall and winecfg to share common code
> for creating links in do
> Log message:
> Only create the device symlinks the first time around.
> + # Check if dosdevices exists and create it if necessary
> + if [ ! -d ~/.wine/dosdevices ]
> + then
> +mkdir ~/.wine/dosdevices
> +ln -s /mnt/fd0 ~/.wine/dosdevices/a:
> +ln -s $CROOT ~/.wine/dosdevice
On Wed, 12 Nov 2003 07:33:36 +, Sir Robert Shearman scribed thus:
>> Log message:
>> Added a wine-glibc binary that detects the glibc threading
>> in use and
>> execs the corresponding wine binary.
>> Removed the --with-nptl configure option.
>
> Cool! Well done.
>
> Rob
Seco
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Alexandre Julliard
> Sent: 12 November 2003 03:28
> To: [EMAIL PROTECTED]
> Subject: wine/ tools/wineinstall loader/Makefile.in loa ...
>
> Log message:
> Added a wine-gl
27 matches
Mail list logo
