On Tue, Oct 4, 2011 at 3:52 AM, Austin English wrote:
> On Mon, Oct 3, 2011 at 12:24, Vijay Kiran Kamuju wrote:
>> Hi,
>>
>> This is on fedora 15. I have just downloaded the fresh git, and
>> attempting the my first build on this system.
>
> Please bottom-post on wine mailing lists.
>
>> The sour
On Mon, Oct 3, 2011 at 12:24, Vijay Kiran Kamuju wrote:
> Hi,
>
> This is on fedora 15. I have just downloaded the fresh git, and
> attempting the my first build on this system.
Please bottom-post on wine mailing lists.
> The source code is downloaded to a usb drive which is FAT32 formatted.
Lo
Hi,
This is on fedora 15. I have just downloaded the fresh git, and
attempting the my first build on this system.
The source code is downloaded to a usb drive which is FAT32 formatted.
The hardware is a Compaq laptop with core duo processor and 2 G RAM.
Do you need any more details.
Thanks,
Vijay
On Mon, Oct 3, 2011 at 05:03, Vijay Kiran Kamuju wrote:
> Hi,
>
> I just downloaded the git and tried compile it.
>
> I just issued `make` command after doing `./configure`
>
> But it gave the below errors:
> make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/tools/wrc'
What type of file
hen I tried 'make' still the same error.
Now doing the distclean and recompling.
Still the same
can this be a file system issue. (i do not think it is)
I can see that there is libd3dcompiler.def file
> Taken from:
> http://wine.1045685.n5.nabble.com/Latest-Git-Fails-tools-install-td1838892.html
>
Vijay
sue.
Try make distclean && ./configure && make depend && make
Try this too:
git clean -fd
Taken from:
http://wine.1045685.n5.nabble.com/Latest-Git-Fails-tools-install-td1838892.html
Hi,
I just downloaded the git and tried compile it.
I just issued `make` command after doing `./configure`
But it gave the below errors:
make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/tools/wrc'
make[1]: Entering directory `/media/PENDRIVE/devel/repo/wine/include'
make[1]: Nothing t
On Wed, Sep 21, 2011 at 2:48 AM, Octavian Voicu
wrote:
>
> I'm guessing daily builds are done after daily commits, so you could
> use the build id (which is just a prefix of the last commit id) from
> here [1].
>
> In your case, it's probably 9b729bb1b348 - 12-Sep-2011 15:45.
>
> Octavian
>
> [1]
On Tue, Sep 20, 2011 at 11:48, Octavian Voicu wrote:
> On Tue, Sep 20, 2011 at 9:27 PM, Qian Hong wrote:
>> Is there any good ways to get the git-describe-like version number
>> from the daily build ppa version number?
>> That's useful while running a regression test. For example, I'd like
>> to
On Tue, Sep 20, 2011 at 9:27 PM, Qian Hong wrote:
> Is there any good ways to get the git-describe-like version number
> from the daily build ppa version number?
> That's useful while running a regression test. For example, I'd like
> to know exactly what is wine1.3_1.3.28+daily-20110912
> in http
On Thu, Sep 1, 2011 at 8:43 PM, Scott Ritchie wrote:
> Unfortunately I have to use Launchpad Recipe's supported substitution
> variables here, and while they do have one for the latest git-tag if I
> build locally this doesn't work on launchpad itself. The reason for
On 09/01/2011 05:05 AM, Alex Bradbury wrote:
> On 1 September 2011 10:50, Scott Ritchie wrote:
>> For an easier user testing experience, you can now install the latest
>> git as a convenient Ubuntu package.
>
> This seems very handy, thank you.
>
> As this seems like
tually ahead of 1.3.28.
>>
> I don't use Ubuntu, so this doesn't really affect me, but can't you
> use the output from "git describe" for the version?
Unfortunately I have to use Launchpad Recipe's supported substitution
variables here, and while they do have
On Thu, Sep 1, 2011 at 3:05 PM, Alex Bradbury wrote:
> As this seems like as good a place as any for Ubuntu packaging of wine
> - do you see any fix in the future for gstreamer support on Wine when
> compiling on 64-bit Ubuntu? The current Wine configure script (quite
> correctly) disables support
On 1 September 2011 11:50, Scott Ritchie wrote:
> The packages are versioned like wine1.3-1.3.27+daily-20110901.
>
> Limitations:
> The major version number is based on the latest released version of the
> Ubuntu packages, so on release days you might see something like
> 1.3.27+daily-20110909 whi
On 1 September 2011 10:50, Scott Ritchie wrote:
> For an easier user testing experience, you can now install the latest
> git as a convenient Ubuntu package.
This seems very handy, thank you.
As this seems like as good a place as any for Ubuntu packaging of wine
- do you see any fix
For an easier user testing experience, you can now install the latest
git as a convenient Ubuntu package.
The instructions are very similar to using the standard Ubuntu packages,
however the PPA name is different. Instead of ppa:ubuntu-wine/ppa, you
add ppa:ubuntu-wine/daily.
>From a termi
> If you run configure again it is gone at least.
You're right, that fixed it for me too. Thanks.
--Juan
chris ahrendt wrote:
Compiling Wine. Grab a lunch or two, rent a video, or whatever,
in the meantime...
config.status: executing Makefile commands
cat: Make.tmp: No such file or directory
config.status: error: could not create Makefile
make: *** [Makefile] Error 1
config.status: executing Makefi
On 3/26/2010 22:55, Juan Lang wrote:
As usual, run ./configure.
Doesn't help, same problem here with ./configure. Make distclean also fails.
--Juan
Don't know then, I'm building right now, on m* modules already.
On Fri, Mar 26, 2010 at 12:48:06PM -0700, chris ahrendt wrote:
>
> > Compiling Wine. Grab a lunch or two, rent a video, or whatever,
> > in the meantime...
> >
> > config.status: executing Makefile commands
> > cat: Make.tmp: No such file or directory
> > config.status: error: could not create Mak
> As usual, run ./configure.
Doesn't help, same problem here with ./configure. Make distclean also fails.
--Juan
On 3/26/2010 22:48, chris ahrendt wrote:
Compiling Wine. Grab a lunch or two, rent a video, or whatever,
in the meantime...
config.status: executing Makefile commands
cat: Make.tmp: No such file or directory
config.status: error: could not create Makefile
make: *** [Makefile] Error 1
config.
> Compiling Wine. Grab a lunch or two, rent a video, or whatever,
> in the meantime...
>
> config.status: executing Makefile commands
> cat: Make.tmp: No such file or directory
> config.status: error: could not create Makefile
> make: *** [Makefile] Error 1
> config.status: executing Makefile comm
On Thu, Feb 11, 2010 at 2:06 PM, chris ahrendt wrote:
> Just did the latest git and got the following :
>
> all -c wineapploader /usr/local/bin/`dirname
> programs/msiexec/__installprog__`
> /usr/bin/install: cannot create regular file
> `/usr/local/bin/programs/msiexec
Just did the latest git and got the following :
all -c wineapploader /usr/local/bin/`dirname programs/msiexec/__installprog__`
/usr/bin/install: cannot create regular file `/usr/local/bin/programs/msiexec':
No such file or directory
make[1]: *** [programs/msiexec/__installprog__] Error 1
You have some false positives, e.g.
dlls/gdi32/enhmfdrv/mapping.c 1 The function
EMFDRV_ModifyWorldTransform' is never used
That function is indeed used in dlls/gdi32/enhmfdrv/init.c; the struct
EMFDRV_Funcs is initialized with it. I guess cppcheck doesn't
grok function pointers yet?
- D
On 1/17/2010 21:50, chris ahrendt wrote:
Don't know if anyone is interested in this or not but I thought I would send
this out to the list.
CPPCheck is now running clean on the GIT tree... but its showing some style
issues. If they are there
for API compatibility let me know and I will ignore t
Don't know if anyone is interested in this or not but I thought I would send
this out to the list.
CPPCheck is now running clean on the GIT tree... but its showing some style
issues. If they are there
for API compatibility let me know and I will ignore them from now on. Here they
are:
File
2009/6/10 Austin English :
> On Tue, Jun 9, 2009 at 7:14 AM, Ben Klein wrote:
>> I've occasionally got compilation errors while doing a git bisect. As
>> there is no way to fix this (assuming there's nothing wrong with libs
>> on my system, since every other revision I try gets built fine)
>> witho
On Tue, Jun 9, 2009 at 7:14 AM, Ben Klein wrote:
> 2009/6/9 Uwe Bonnes :
>>> "Ben" == Ben Klein writes:
>>
>> Ben> 2009/6/9 Uwe Bonnes :
>> >> Hello,
>> >>
>> >> on a fresh tree check out and compiled successfully yesterday
>> >> (090608) and updated today(090609), compile fails
2009/6/9 Uwe Bonnes :
>> "Ben" == Ben Klein writes:
>
> Ben> 2009/6/9 Uwe Bonnes :
> >> Hello,
> >>
> >> on a fresh tree check out and compiled successfully yesterday
> >> (090608) and updated today(090609), compile fails with:
> >>
> >> make[1]: Entering directory
> >>
> "Ben" == Ben Klein writes:
Ben> 2009/6/9 Uwe Bonnes :
>> Hello,
>>
>> on a fresh tree check out and compiled successfully yesterday
>> (090608) and updated today(090609), compile fails with:
>>
>> make[1]: Entering directory
>> `/media/sda8/sdb8/spare/bon/W
2009/6/9 Uwe Bonnes :
> Hello,
>
> on a fresh tree check out and compiled successfully yesterday (090608) and
> updated today(090609), compile fails with:
>
> make[1]: Entering directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include'
> ../tools/widl/widl -I. -I. -I../include -I../include \
>
Hello,
on a fresh tree check out and compiled successfully yesterday (090608) and
updated today(090609), compile fails with:
make[1]: Entering directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include'
../tools/widl/widl -I. -I. -I../include -I../include \
-h -H activaut.h activaut.idl
../to
2009/6/6, Henri Verbeet :
> 2009/6/6 Milan Kostić :
>> Deafulting to fbo is good, but it should be more good to leave also
>> prior working support for backbuffer on older cards who not have
>> EXT_framebuffer_object. Reverting to
>> "OffscreenRenderingMode"="backbuffer" is not working as expected
Am 06.06.2009 um 08:18 schrieb Roderick Colenbrander:
We don't use GL extensions when they aren't around. Perhaps there is a
small check which fails for FBOs. Backbuffer should work fine but a
lot more changes have been made in .23 and those are which cause the
zbuffer error.
A long time ago th
2009/6/6 Milan Kostić :
> Deafulting to fbo is good, but it should be more good to leave also
> prior working support for backbuffer on older cards who not have
> EXT_framebuffer_object. Reverting to
> "OffscreenRenderingMode"="backbuffer" is not working as expected for
> me on r200 Mesa/DRI driver
We don't use GL extensions when they aren't around. Perhaps there is a
small check which fails for FBOs. Backbuffer should work fine but a
lot more changes have been made in .23 and those are which cause the
zbuffer error.
Roderick
On Sat, Jun 6, 2009 at 4:58 PM, Milan Kostić wrote:
> Deafulting
2009/6/6 Stefan Dösinger :
> Hmm. Does fglrx support this extension at all?
http://bugs.winehq.org/attachment.cgi?id=21581
That's attached to bug 18794.
That's probably the same issue as http://bugs.winehq.org/show_bug.cgi?id=18794
I'm afraid the conclusion there is simply going to be that fglrx's FBO
support sucks. We could probably justify not checking depth stencil
formats, but it's perfecly reasonable to try
GL_COMPRESSED_RED_GREEN_RGTC2_EXT.
Deafulting to fbo is good, but it should be more good to leave also
prior working support for backbuffer on older cards who not have
EXT_framebuffer_object. Reverting to
"OffscreenRenderingMode"="backbuffer" is not working as expected for
me on r200 Mesa/DRI drivers, for example in Max Payne 2 whic
2009/6/6 Jerome Leclanche :
> Would it be a good/stupid idea to check for fglrx during wineboot, and
> set OSRM to a different value than fbo?
>
That's essentially what blacklisting EXT_framebuffer_object would do,
although during wined3d initialization, not wineboot. We want to avoid
that for the
Sure that is possible but it is something we should avoid. In the
longterm having this enabled by default is better as it would get ATI
and others to fix their drivers. If we would restore the old value
(the old method is also not great for modern games and causes a lot of
issues, FBOs are needed f
Would it be a good/stupid idea to check for fglrx during wineboot, and
set OSRM to a different value than fbo?
2009/6/6 Henri Verbeet :
> 2009/6/6 Kovács András :
>> wine: Unhandled page fault on read access to 0x0018 at address
>> 0x7c71fb02 (thread 0009), starting debugger...
>> Unhandled ex
"chris ahrendt" wrote:
Using this attached Reg File Is still a no go... same...
(I forgot the Direct3D tag but added it and no change)
Have you heard of a regression testing? Also wine-devel is not
an appropriate place to report bugs.
--
Dmitry.
Using this attached Reg File Is still a no go... same...
(I forgot the Direct3D tag but added it and no change)
Chris
rendering3.Reg
Description: Binary data
2009/6/6 Kovács András :
> wine: Unhandled page fault on read access to 0x0018 at address
> 0x7c71fb02 (thread 0009), starting debugger...
> Unhandled exception: page fault on read access to 0x0018 in 32-bit
> code (0x7c71fb02).
> Register dump:
> CS:0073 SS:007b DS:007b ES:007b FS:0033 GS
On 06/05/2009 09:16 PM, Austin English wrote:
> On Fri, Jun 5, 2009 at 8:03 PM, chris ahrendt wrote:
>
>> On 06/05/2009 08:15 PM, Austin English wrote:
>>
>>> On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt
>>> wrote:
>>>
>>>
Tried it several times.. and different iterati
On Fri, Jun 5, 2009 at 8:03 PM, chris ahrendt wrote:
>
> On 06/05/2009 08:15 PM, Austin English wrote:
>> On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt wrote:
>>
>>> Tried it several times.. and different iterations of the registry keys
>>> (you will find them attached) and both cases it fails the
Hi!
With new wine (1.1.23+ git) I'm getting wide range of failures of
different games.
System:
Ubuntu Jaunty x86
ATI Radeon HD4870 512 MB
fglrx 9.5
- The most significant crash (with several games):
wine: Unhandled page fault on read access to 0x0018 at address
0x7c71fb02 (thread 0009), star
On 06/05/2009 08:15 PM, Austin English wrote:
> On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt wrote:
>
>> Tried it several times.. and different iterations of the registry keys
>> (you will find them attached) and both cases it fails the same way any
>> of the d3d tests will fail or the machi
On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt wrote:
> Tried it several times.. and different iterations of the registry keys
> (you will find them attached) and both cases it fails the same way any
> of the d3d tests will fail or the machine locks up.
--
-Austin
REGEDIT4
[HKEY_CURRENT_USER\Soft
Tried it several times.. and different iterations of the registry keys
(you will find them attached) and both cases it fails the same way any
of the d3d tests will fail or the machine locks up.
rendering.Reg
Description: Binary data
rendering2.Reg
Description: Binary data
eringMethod to backbuffer restores the old behavior.
>>>
>>> Roderick
>>>
>>> On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt
>>> wrote:
>>>
>>>
>>>> Something majorly changed and is wrong with the latest GIT tree.
>
:04 PM, chris ahrendt wrote:
>>
>>> Something majorly changed and is wrong with the latest GIT tree.
>>> Between the comits yesterday and today 90% of the tests get exceptions
>>> or fail.
>>> All of the d3d tests get a process exception and fail with a dialog
o backbuffer restores the old behavior.
>
> Roderick
>
> On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt wrote:
>
>> Something majorly changed and is wrong with the latest GIT tree.
>> Between the comits yesterday and today 90% of the tests get exceptions
>> o
:04 PM, chris ahrendt wrote:
>
> Something majorly changed and is wrong with the latest GIT tree.
> Between the comits yesterday and today 90% of the tests get exceptions
> or fail.
> All of the d3d tests get a process exception and fail with a dialog box.
>
>
> Ideas?
>
> Chris
>
>
>
>
>
>
>
>
>
>
Something majorly changed and is wrong with the latest GIT tree.
Between the comits yesterday and today 90% of the tests get exceptions
or fail.
All of the d3d tests get a process exception and fail with a dialog box.
Ideas?
Chris
2008/10/21 chris ahrendt <[EMAIL PROTECTED]>:
> Austin English wrote:
>> On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote:
>>> Anyone else having a problem compiling the latest git?
>>>
>>> mine has failed 2 times when I comp
On Mon, Oct 20, 2008 at 10:37 PM, chris ahrendt <[EMAIL PROTECTED]> wrote:
> Austin English wrote:
>> On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote:
>>
>>> Anyone else having a problem compiling the latest git?
>>>
>>>
Austin English wrote:
> On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote:
>
>> Anyone else having a problem compiling the latest git?
>>
>> mine has failed 2 times when I compile... one with a clean tree and one
>&
Austin English wrote:
> On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote:
>
>> Anyone else having a problem compiling the latest git?
>>
>> mine has failed 2 times when I compile... one with a clean tree and one
>&
On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote:
> Anyone else having a problem compiling the latest git?
>
> mine has failed 2 times when I compile... one with a clean tree and one
> with an olde
Anyone else having a problem compiling the latest git?
mine has failed 2 times when I compile... one with a clean tree and one
with an older tree..
chris
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http
I did a make clean in the wine directory and it appears to be working now.
From: "Vijay Kiran Kamuju" <[EMAIL PROTECTED]>
To: "EA Durbin" <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: wine complation fails with latest git
Date: Wed, 13 Sep 2006
Please do a make clean in widl directory and do make
On 9/12/06, EA Durbin <[EMAIL PROTECTED]> wrote:
I'm not able to compile wine with the latest source from git.
gcc-3.4 -c -I. -I. -I../../include -I../../include-Wall -pipe
-fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwri
I'm not able to compile wine with the latest source from git.
gcc-3.4 -c -I. -I. -I../../include -I../../include-Wall -pipe
-fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings
-Wpointer-arith -g -O2 -o parser.yy.o parser.yy.c
parser.l: In function `parser_lex':
pa
On Tue, Jul 18, 2006 at 09:35:05AM +0200, Christoph Frick wrote:
> > Well, I was able to successfully build git revision
> > 6a97f2202e91fed286ff6ca254926e5f57ca17c1 so this topic is closed.
> this is a problem, that seemed to exist for a few days on gcc32
> compiles. Alexandre fixed this yesterda
On Tue, 2006-04-18 at 09:06 +0200, Paul Vriens wrote:
> Hi,
>
> I've just removed my .wine to get a clean start (wasn't much in there
> anyway).
>
> When I now start any program (regedit, iexplore) I get an X-crash. I did
> a WINEDEBUG=+all,+relay and the last X-related thing I see is :
>
> err:
Hi,
I've just removed my .wine to get a clean start (wasn't much in there
anyway).
When I now start any program (regedit, iexplore) I get an X-crash. I did
a WINEDEBUG=+all,+relay and the last X-related thing I see is :
err:x11drv:error_handler X protocol error: serial=6892, request_code=146
- b
On 09/02/06, Paul Vriens <[EMAIL PROTECTED]> wrote:
> Hi,
>
> with the latest git version (is that the correct naming?) I'm getting:
>
> make[1]: Entering directory `/wine/wine-git/include'
> ../tools/widl/widl -I. -I. -I../include -I../include-h -H mshtml.h
&
On Thursday 09 February 2006 18:34, Paul Vriens wrote:
> with the latest git version (is that the correct naming?) I'm getting:
>
> make[1]: Entering directory `/wine/wine-git/include'
> ../tools/widl/widl -I. -I. -I../include -I../include-h -H mshtml.h
> mshtml.idl
&
Hi,
with the latest git version (is that the correct naming?) I'm getting:
make[1]: Entering directory `/wine/wine-git/include'
../tools/widl/widl -I. -I. -I../include -I../include-h -H mshtml.h
mshtml.idl
error: length() does not define an explicit binding handle!
make[1]: ***
74 matches
Mail list logo
