Anyway, I guess it is not so important for clean checkouts...
On Sun, Dec 27, 2009 at 7:45 PM, Alon Bar-Lev wrote:
> Hello,
>
> Even if it is exact the same, the timestamp is older the the source
> files, so build tries to rebuild it.
>
> Thanks,
> Alon.
>
> On Sun, Dec 27, 2009 at 7:44 PM, Kai T
Hello,
Even if it is exact the same, the timestamp is older the the source
files, so build tries to rebuild it.
Thanks,
Alon.
On Sun, Dec 27, 2009 at 7:44 PM, Kai Tietz wrote:
>
> Hello Alon,
>
> 2009/12/24 Alon Bar-Lev :
> > I don't understand why you keep generated files in svn...
> > But you
Hello Alon,
2009/12/24 Alon Bar-Lev :
> I don't understand why you keep generated files in svn...
> But you should also checkin an updated version of aclocal.m4.
Well, this is a decision we made, that we want to provide the use of
configure without the need of having proper autotools installed. So
I don't understand why you keep generated files in svn...
But you should also checkin an updated version of aclocal.m4.
On Thu, Dec 24, 2009 at 10:49 AM, Kai Tietz wrote:
> 2009/12/24 Alon Bar-Lev :
>> On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
>>> Ok, I see. I added to the comment that t
2009/12/24 Alon Bar-Lev :
> On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
>> Ok, I see. I added to the comment that this just happens on
>> cross-compile. Btw gendef should work as native build on linux, too.
>> There shouldn't be any dependencies to Windows specific runtime.
>
> Almost true..
On Thu, Dec 24, 2009 at 9:55 AM, Alon Bar-Lev wrote:
> On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
>> Ok, I see. I added to the comment that this just happens on
>> cross-compile. Btw gendef should work as native build on linux, too.
>> There shouldn't be any dependencies to Windows specifi
On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
> Ok, I see. I added to the comment that this just happens on
> cross-compile. Btw gendef should work as native build on linux, too.
> There shouldn't be any dependencies to Windows specific runtime.
Almost true... :)
Attached a patch.
Alon.
diff
2009/12/23 Alon Bar-Lev :
> Oh... For the comment I understand that you did not fully understand
> the reason for failure...
>
> For testing if the malloc is gnu malloc or not a autoconf must try to
> *RUN* a program...
> ---
> int
> main ()
> {
> return ! malloc (0);
> ;
> return 0;
> }
> ---
>
Oh... For the comment I understand that you did not fully understand
the reason for failure...
For testing if the malloc is gnu malloc or not a autoconf must try to
*RUN* a program...
---
int
main ()
{
return ! malloc (0);
;
return 0;
}
---
The problem is that when you cross compile autoconf
2009/12/23 Alon Bar-Lev :
> On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
>> The change about malloc isn't used AFAICS, but well I want to keep it,
>> as we plan to improve the conditional header includes in future.
>> Does this line leads to an build error for you?
>
> Yes... It is needed.
>
2009/12/23 Alon Bar-Lev :
> Great!
> It works.
Thanks for testing. I will apply it to v1.0 branch and trunk.
> But... Why there is a huge difference between lib64 and lib32 libraries?
> I see that lib32 contains only 142 libraries while lib64 contains 2042.
>
> For example libpdh is missing in li
Great!
It works.
But... Why there is a huge difference between lib64 and lib32 libraries?
I see that lib32 contains only 142 libraries while lib64 contains 2042.
For example libpdh is missing in lib32.
On Wed, Dec 23, 2009 at 12:57 PM, Kai Tietz wrote:
> 2009/12/22 Kai Tietz :
>> 2009/12/22 Alo
On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
> The change about malloc isn't used AFAICS, but well I want to keep it,
> as we plan to improve the conditional header includes in future.
> Does this line leads to an build error for you?
Yes... It is needed.
Once the autoconf detects that gnu m
2009/12/23 Alon Bar-Lev :
> OK.
> Thanks.
>
> I had to fixup the gendef...
>
> 1. You check for gnu compliant malloc but not define the rpl_malloc,
> so I removed this check.
> 2. You treat warnings as errors and do not eliminate unused parameters.
Thanks for reporting this warning. I committed an
OK.
Thanks.
I had to fixup the gendef...
1. You check for gnu compliant malloc but not define the rpl_malloc,
so I removed this check.
2. You treat warnings as errors and do not eliminate unused parameters.
Attached is a patch.
Alon
On Wed, Dec 23, 2009 at 2:28 PM, Kai Tietz wrote:
> 2009/12/2
2009/12/22 Kai Tietz :
> 2009/12/22 Alon Bar-Lev :
>> On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
>>> 2009/12/22 Alon Bar-Lev :
Hi,
I think that i686-w64-mingw32 should be supported, right?
At least it would be great if it is as this project is much more
maintained a
2009/12/22 Alon Bar-Lev :
> On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
>> 2009/12/22 Alon Bar-Lev :
>>> Hi,
>>>
>>> I think that i686-w64-mingw32 should be supported, right?
>>> At least it would be great if it is as this project is much more
>>> maintained and complete than mingw32.
>>>
>>
On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
> 2009/12/22 Alon Bar-Lev :
>> Hi,
>>
>> I think that i686-w64-mingw32 should be supported, right?
>> At least it would be great if it is as this project is much more
>> maintained and complete than mingw32.
>>
>> While trying to do so, I get the f
2009/12/22 Alon Bar-Lev :
> Hi,
>
> I think that i686-w64-mingw32 should be supported, right?
> At least it would be great if it is as this project is much more
> maintained and complete than mingw32.
>
> While trying to do so, I get the following... And indeed the
> declaration is duplicated.
> I
Hi,
I think that i686-w64-mingw32 should be supported, right?
At least it would be great if it is as this project is much more
maintained and complete than mingw32.
While trying to do so, I get the following... And indeed the
declaration is duplicated.
I tested both v1.0 and trunk snapshots, gcc
20 matches
Mail list logo
