Compilation issue: Missing strtod_l and locale_t

[AlbertoEAF]

Hello,

I'm using this library for LightGBM (microsoft/LightGBM#3405) and whilst I'm really happy with it, there are some CI environments where this does not compile. I don't understand why. CMakeLists claims strtod_l was found:

-- Looking for strtod_l - found
-- Configuring done

You can see the job error details here. See lines 704 and 708 for instance: https://travis-ci.org/github/microsoft/LightGBM/jobs/730024056

I first mistakenly added this issue at the fmt library which I'm also using and they suggested using this fmtlib/fmt#1901.

As strtod_l and locale_t are non-standard, how do you solve this usually?

[lemire]

Thanks for the report. It looks like it might be a bug on my end.

As strtod_l and locale_t are non-standard, how do you solve this usually?

You are using GNU GCC and it definitively supports it.

It even says so in your stream...

-- Looking for strtod_l
-- Looking for strtod_l - found

[lemire]

Let me investigate the issue a bit.

[lemire]

I think I understand what is going on.

[lemire]

@AlbertoEAF Can you try with this commit...
e09e5aa

My guess is not that you are missing the function but rather that, somehow, the include xlocale.h does not pan out. It is a complicated issue. If you are mixing and matching various runtime libraries and with various compilers, it gets a bit tricky.

I think my new heuristic should work.

(I looked at your CI and it a bit difficult to reproduce at the moment.)

[AlbertoEAF]

Great Lemire! I will test it Monday ;)

[lemire]

@AlbertoEAF Great. Please follow-up. This include code is something new, and I am eager to get it right.

[lemire]

It is really simply a matter of declaring the function which may involve including the right header. My backup plan is to kill strtod_l and go with @nigeltao proposal (which is to include our own fallback parser... thankfully something that is quite easy thanks to Nigel's pointers). It will fatten a bit the header, so I'd prefer if we could just use strtod_l especially since it is present on the systems you care about.

[AlbertoEAF]

By the way, the other library I'm using follows this approach:
https://github.com/fmtlib/fmt/blob/6cccdc24bcb8605965c1e2497c61504cd388bde9/include/fmt/os.h#L16-L24

Don't know if it helps, anyway I'll try your commit first ;)

[lemire]

@AlbertoEAF

On freebsd and apple platforms, we definitively should be including xlocale.h already.

This morning, I will see about adding more platform coverage on my end.

[lemire]

@AlbertoEAF I have just updated my CI to include many, many systems... Visit the README on github...

https://github.com/lemire/fast_double_parser

I cannot reproduce any build problems.

Did you get around to testing the issue further? E.g., you could just describe the system where you encounter the issue.

[lemire]

Note that my CI tests include FreeBSD. They do not include macos but I am a mac user myself, so mac support is never an issue.

[AlbertoEAF]

Hello @lemire, yes we had progress using that commit. ;)

It no longer fails on that job due to locale: https://travis-ci.org/github/microsoft/LightGBM/jobs/731344749.

Now it fails with internal LGBM build system issues alone.

I'd like to thank you for your work @lemire, it was a really quick turn-around time and effective ;)

Thanks for developing and maintaining this project!

[lemire]

Fantastic. I am closing this issue now. Please come back if there is more we can do.