On 26 July 2010 17:08, Michael Stefaniuc wrote:
> Works for me with the gcc 4.4.4 on F13 but it breaks with the old 3.1.1
> gcc used by the old Smatch.
>
Well, it works with 4.4.3 on Gentoo for me as well... :-) just saying
that you don't necessarily have to try very hard to break it.
Henri Verbeet wrote:
> On 26 July 2010 10:00, Alexandre Julliard wrote:
>> Octavian Voicu writes:
>>
>>> On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
-static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /*
flags that can be set by user */
+static const D
On 26 July 2010 10:00, Alexandre Julliard wrote:
> Octavian Voicu writes:
>
>> On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
>>> - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /*
>>> flags that can be set by user */
>>> + static const DWORD user_flags = DCX_PARENTC
Octavian Voicu writes:
> On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
>> - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /* flags
>> that can be set by user */
>> + static const DWORD user_flags = DCX_PARENTCLIP | DCX_CLIPSIBLINGS |
>> DCX_CLIPCHILDREN | DCX_WINDO
On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa wrote:
> - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /* flags
> that can be set by user */
> + static const DWORD user_flags = DCX_PARENTCLIP | DCX_CLIPSIBLINGS |
> DCX_CLIPCHILDREN | DCX_WINDOW
> + | DCX_NORESETATTRS
t; Date: Mon Jan 15 13:01:42 2007 +0100
>
> oleaut32/tests: Replace some macros by functions to reduce code size and
> compile time.
Some compile stats for vartest.c on my P4 3GHz HT, 2 GB RAM, FC6,
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
-O0 -O1 -O2 -O3 -Os
as assembly shaders by the d3d9x library. The d3d9 dll never
> sees HLSL or assembly, just compiled shaders. Direct3D10 does contain
> a "D3D10CompileShader" function, but that's shader model 4.0.
> > I was curious as to whether it would be acceptable to provide a
compile-
l never
sees HLSL or assembly, just compiled shaders. Direct3D10 does contain
a "D3D10CompileShader" function, but that's shader model 4.0.
> I was curious as to whether it would be acceptable to provide a compile-time
> check for OpenGL 2.0?
No, and it's not required eith
t at the moment, shaders are parsed and converted to
AFP_FP/VP 1 and if a particular opcode is not supported, a FIXME states a
requirement for GLSL.
I was curious as to whether it would be acceptable to provide a compile-time
check for OpenGL 2.0? It would be no different than checking for any other
d
On Sunday 28 August 2005 15:31, Robert Lunnon wrote:
> wldap32.h seems to be missing a definition for LDAPSortKey and won't
> compile. I can't seem to find a definition anywhere. Is this a linuxism,
> does it borrow this definition from somewhere else under linux ?
Windows knows about that struc
wldap32.h seems to be missing a definition for LDAPSortKey and won't compile.
I can't seem to find a definition anywhere. Is this a linuxism, does it
borrow this definition from somewhere else under linux ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 15 February 2004 21:11, Alexandre Julliard wrote:
> > The compiler warning attracted my attention to code that if believe
> > would be better as a #if.
>
> No, using normal code is always better than #ifdefs. This way all the
> code gets comp
John Birrell <[EMAIL PROTECTED]> writes:
> Note that the code I am questioning does not produce a compiler
> warning. The warning comes from code in the if-true path.
>
> The compiler warning attracted my attention to code that if believe
> would be better as a #if.
No, using normal code is alway
t I am questioning is:
if (sizeof(st.st_dev) > sizeof(unsigned long) && st.st_dev > ~0UL)
sizeof() is evaluated at compile time based on the compiler and the
header files you are compiling the sources against. If, as you say,
"compile once, run on lots of distros", then t
On Sun, 15 Feb 2004 14:47:28 +1100, John Birrell wrote:
> If I had my way, this sort of thing should be coded as a compile
> time test and only the code for the appropriate size compiled in. Is there some
> sort of direction for/from Wine developers for this kind of thing?
We typical
an attempt to shift >= the number of bits
in the variable. If I had my way, this sort of thing should be coded as a compile
time test and only the code for the appropriate size compiled in. Is there some
sort of direction for/from Wine developers for this kind of thing?
--
John Birrell
Robert Lunnon <[EMAIL PROTECTED]> writes:
> There are quite a few patches in that kit, they are organised as separate
> patches for each file and a description to make application easy. After
> extracting you could construct a single liner that would apply the entire
> kit.
Actually it doesn't
On Wed, 14 Jan 2004, Robert Lunnon wrote:
> It would be relatively easy to send a dozen or so emails though, providing you
> don't want me to collect up the dependencies into a single e-mail
Well, a patch should be a logical atomic change, no matter how many files
it touches. You can't for examp
On Thursday 08 January 2004 17:51, Dimitrie O. Paun wrote:
> On January 8, 2004 01:22 am, Robert Lunnon wrote:
> > Here are a buch of Solais compatibility patches for wine (Some but not
> > all of them). Within the enclosed tarball the diffs are structured
> > according to the wine cvs tree. There
On January 8, 2004 01:22 am, Robert Lunnon wrote:
> Here are a buch of Solais compatibility patches for wine (Some but not all
> of them). Within the enclosed tarball the diffs are structured according to
> the wine cvs tree. There is a readme file accompanying each diff to explain
> what the chang
Le mar 25/11/2003 Ã 00:37, Alex Tribble a Ãcrit :
> Hi,
> When upgrading to Fedora Core 1 (the new RedHat release, sort of),
> wine stopped compiling for me. I was getting errors while parsing
> , et al. -DOPENSSL_NO_KRB5 makes these go away.
>
> Any thoughts? Please CC me, as I'm not subscribed
> Without knowing the rest of the systems (RAM, HD speed, present libs,
> compiler used, etc.) it's rather meaningless to compare compile times.
512MB ddr, gcc 3.3.1, all optional wine stuff compiled in, 7200rpms hd.
Le mer 10/09/2003 à 11:55, Ivan Leo Murray-Smith a écrit :
> >p.s.
> >For me (P-IV 1600MHZ) complete build compile takes 25 minutes. I've now
> >switched to ccache, hoping I can bring it down even lower.
> And my 1.4GHZ AMD Athlon XP takes 18:45, and some people still think intel can
> compete wit
>p.s.
>For me (P-IV 1600MHZ) complete build compile takes 25 minutes. I've now
>switched to ccache, hoping I can bring it down even lower.
And my 1.4GHZ AMD Athlon XP takes 18:45, and some people still think intel can
compete with AMD...
24 matches
Mail list logo
