[1/3] configure: Check for strtoll and redirect to _strtoi64 in the msvcrt block

Message ID 1469390253-2666-1-git-send-email-martin@martin.st
State Committed
Commit 56af0bc10f49654b5b5f3efe82c69a13bf15fc8b
Headers show

Commit Message

Martin Storsjö July 24, 2016, 7:57 p.m.
This allows doing this redirection, if building with clang against
old enough MSVC headers that lack strtoll (2012 and older).
---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Luca Barbato July 24, 2016, 10:39 p.m. | #1
On 24/07/16 21:57, Martin Storsjö wrote:


The set seems ok.
Diego Biurrun July 25, 2016, 9:06 a.m. | #2
On Sun, Jul 24, 2016 at 10:57:31PM +0300, Martin Storsjö wrote:
> This allows doing this redirection, if building with clang against
> old enough MSVC headers that lack strtoll (2012 and older).
> ---
>  configure | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

OK

Not directly related to this patch: What's the baseline MSVC headers
that we still support?

Diego
Martin Storsjö July 25, 2016, 9:17 a.m. | #3
On Mon, 25 Jul 2016, Diego Biurrun wrote:

> On Sun, Jul 24, 2016 at 10:57:31PM +0300, Martin Storsjö wrote:
>> This allows doing this redirection, if building with clang against
>> old enough MSVC headers that lack strtoll (2012 and older).
>> ---
>>  configure | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> OK
>
> Not directly related to this patch: What's the baseline MSVC headers
> that we still support?

2010 is the lowest version (the initial which we used for the MSVC support 
back when it was added), and it worked just fine (and has required almost 
zero maintainance since). The MSVCRT libc has got mostly the same quirks 
for all versions but the last (i.e. 2010, 2012, 2013), while the 2015 
version should be mostly C99 compliant for the libc part. (In 2013, the 
compiler itself became mostly C99 compliant.)

// Martin
Diego Biurrun July 25, 2016, 9:23 a.m. | #4
On Mon, Jul 25, 2016 at 12:17:21PM +0300, Martin Storsjö wrote:
> On Mon, 25 Jul 2016, Diego Biurrun wrote:
> > On Sun, Jul 24, 2016 at 10:57:31PM +0300, Martin Storsjö wrote:
> >> This allows doing this redirection, if building with clang against
> >> old enough MSVC headers that lack strtoll (2012 and older).
> >> ---
> >>  configure | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > OK
> >
> > Not directly related to this patch: What's the baseline MSVC headers
> > that we still support?
> 
> 2010 is the lowest version (the initial which we used for the MSVC support 
> back when it was added), and it worked just fine (and has required almost 
> zero maintainance since). The MSVCRT libc has got mostly the same quirks 
> for all versions but the last (i.e. 2010, 2012, 2013), while the 2015 
> version should be mostly C99 compliant for the libc part. (In 2013, the 
> compiler itself became mostly C99 compliant.)

Thanks for the info.  Do you think we should drop support for some of
the old versions at some point?  Since Microsoft recently (was it 2013?)
started selling MSVC for zero cost, the toolchain upgrade path has
become pretty compelling.

Diego
Martin Storsjö July 25, 2016, 9:50 a.m. | #5
On Mon, 25 Jul 2016, Diego Biurrun wrote:

> On Mon, Jul 25, 2016 at 12:17:21PM +0300, Martin Storsjö wrote:
>> On Mon, 25 Jul 2016, Diego Biurrun wrote:
>> > On Sun, Jul 24, 2016 at 10:57:31PM +0300, Martin Storsjö wrote:
>> >> This allows doing this redirection, if building with clang against
>> >> old enough MSVC headers that lack strtoll (2012 and older).
>> >> ---
>> >>  configure | 4 +++-
>> >>  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > OK
>> >
>> > Not directly related to this patch: What's the baseline MSVC headers
>> > that we still support?
>> 
>> 2010 is the lowest version (the initial which we used for the MSVC support 
>> back when it was added), and it worked just fine (and has required almost 
>> zero maintainance since). The MSVCRT libc has got mostly the same quirks 
>> for all versions but the last (i.e. 2010, 2012, 2013), while the 2015 
>> version should be mostly C99 compliant for the libc part. (In 2013, the 
>> compiler itself became mostly C99 compliant.)
>
> Thanks for the info.  Do you think we should drop support for some of
> the old versions at some point?

If they hinder work or progress, perhaps, but not "just because". I run a 
MSVC 2010 fate instance, and it hasn't really caused any headaches that 
the other MSVC versions wouldn't have.

> Since Microsoft recently (was it 2013?)

No, they've been available for free since 2005 actually. Previously it was 
a slimmed down "Express" version (which basically forced you to download 
it separately for C++ and C# etc, instead of a larger all-in-one IDE), but 
since 2013 you have the full deal for free as well. But the Express 
versions work just fine for our uses, that's what the 2010 fate instances 
run on anyway.

> started selling MSVC for zero cost, the toolchain upgrade path has
> become pretty compelling.

Well, upgrading in itself isn't too hard, but I wouldn't want to force 
users to it unless we actually gain something from it. And right now, we 
don't. (Upgrading the toolchain itself isn't hard or expensive, but often 
can result in loads of more work if you've got a larger build environment 
- imagine a setup with dozens and dozens of libraries, all with their own 
quirks.)

// Martin

Patch

diff --git a/configure b/configure
index 37c5611..d585560 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,9 @@  probe_libc(){
 #endif
 #endif
 EOF
+        if [ "$pfx" = "" ]; then
+            check_func strtoll || add_cflags -Dstrtoll=_strtoi64
+        fi
     elif check_${pfx}cpp_condition stddef.h "defined __KLIBC__"; then
         eval ${pfx}libc_type=klibc
     elif check_${pfx}cpp_condition sys/cdefs.h "defined __BIONIC__"; then
@@ -4978,7 +4981,6 @@  elif enabled_any msvc icl; then
 __declspec($_restrict) void* foo(int);
 EOF
     fi
-    check_func strtoll || add_cflags -Dstrtoll=_strtoi64
 fi
 
 for pfx in "" host_; do