On Fri, 7 Apr 2017, Dan Fandrich wrote:
Indeed, my fix was totally lame. I've submitted a PR now for a better fix:
https://github.com/curl/curl/pull/1397
That PR fixes my tcc build (on x86, anyway).
Thanks, that's at least a step forward so I merged it just now.
--
/ daniel.haxx.se
On Fri, Apr 07, 2017 at 08:28:09AM +0200, Daniel Stenberg wrote:
> Indeed, my fix was totally lame. I've submitted a PR now for a better fix:
> https://github.com/curl/curl/pull/1397
>
> It'd be great if you could give it a shot, or else we can just merge this
> and work it out with the
On Fri, 7 Apr 2017, Dan Fandrich wrote:
Race condition... But there's a new and different error in that build this
morning!
Indeed, my fix was totally lame. I've submitted a PR now for a better fix:
https://github.com/curl/curl/pull/1397
It'd be great if you could give it a shot, or else
On Thu, 6 Apr 2017, Dan Fandrich wrote:
My 32-bit tcc autobuild is still failing, with error: 'CURLSYS_SIZEOF_LONG'
undeclared: https://curl.haxx.se/dev/log.cgi?id=20170406065050-13464#prob1
Hehe, I'm ahead of you for once! :-)
commit ae485279a189c4047802386e12dc2d0c043af8ef
Author: Daniel
On Wed, Apr 05, 2017 at 03:08:12PM +0200, Daniel Stenberg wrote:
> I'll revert that and instead loosen the 1541 check to ignore the exact
> variable type name as long as the sizes and format strings are the same.
My 32-bit tcc autobuild is still failing, with error: 'CURLSYS_SIZEOF_LONG'
On Wed, 5 Apr 2017, Marcel Raad wrote:
there are 11 new warnings about unknown format specifiers when using
CURL_FORMAT_CURL_OFF_T in the MinGW autobuilds since this morning, this is
probably related?
Thanks for pointing this out, it clearly is. My change caused not only 'long
long' to be
Hi Daniel,
> I propose we fix this by checking for long long before we check for int64_t in
> configure. I can't come up with any system where changing this will cause any
> problems but I'm all ears if someone else does!
there are 11 new warnings about unknown format specifiers when using
On Tue, 4 Apr 2017, Daniel Stenberg wrote:
I propose we fix this by checking for long long before we check for int64_t
in configure. I can't come up with any system where changing this will cause
any problems but I'm all ears if someone else does!
Come to think of it. We could also consider
On Tue, 4 Apr 2017, Dan Fandrich wrote:
If anyone experiences problems with test 1541, speak up!
All my autobuilds from last night failed on this test, and one didn't even
compile.
Thanks!
I see that curlbuild.h favors int64_t before 'long long' (for 32bit systems)
and system.h does not:
On Mon, Apr 03, 2017 at 11:45:27PM +0200, Daniel Stenberg wrote:
> If anyone experiences problems with test 1541, speak up!
All my autobuilds from last night failed on this test, and one didn't even
compile.
---
Unsubscribe:
On Thu, 30 Mar 2017, Daniel Stenberg wrote:
[2] = https://github.com/curl/curl/pull/1373
This has now landed in git master. The new include file is used in parallel
with the old one that is still being used. There's a new test (number 1541)
that verifies that the new header comes to the
On Fri, 31 Mar 2017, Daniel Stenberg wrote:
I'll try get something like that working...
There. My updated version now defines symbols with a different prefix in
parallel with the old header file, and I've added test 1541 that verifies that
both headers came to the same conclusions or else
On Thu, 30 Mar 2017, Florian Weimer wrote:
I think you could write run-time tests for most of the macro values. The
formats could probably be checked using sscanf and sprintf. For the type
sizes and type definitions, it should even be possible to write compile-time
tests.
This would
* Daniel Stenberg:
> I'm looking for comments and feedback on the general approach and
> feasability.
It doesn't look too bad so far.
I think you could write run-time tests for most of the macro values.
The formats could probably be checked using sscanf and sprintf. For
the type sizes and type
14 matches
Mail list logo
