Hi! Running the code you offered (in a container, though), I've got:

lib/locale ..................................................... FAILE
+D at test 427
lib/locale_threads ............................................. skipp
+ed
[download]

Here is my %Config, as obtained by cd t; ./perl -I../lib -MData::Dumper -MConfig -e'print Dumper \%Config':

¹Yes, it has bitten me in the past when I wrote a library to talk to a device using standard C string formatting functions, then something else in the process called setlocale(LC_ALL, "") and everything got broken.

UPDATE: Since writing this post, I've managed to reproduce the lib/locale.t failure on my Ubuntu-16.04 box by switching locale to LANG=de_DE.UTF-8.
I now just need to make sense of what I'm seeing.

The failures might be related to the fact the my locale (like some European ones) uses a comma (,) as decimal separator, unlike a dot (.) as expected by "C" locale

Then I wonder if I might be able to strike the same issues on my Ubuntu-16.04 box by messing with its locale settings. I'll have to at least give that a try.
I've no experience with messing with locale settings - but I expect that google has lots of advice to offer on how to do this.

I'm sure that my patches affect only the values that are assigned - they change nothing about the way that values are displayed.
If C's strtod() doesn't honor the locale when parsing the input string, then that would cause breakage. However, in such a case I would expect more extensive breakage than just a lib/locale.t failure.
And, of course, such a perl would have no business in defining Perl_strtod in the first place - and the default that allows the defining of $Config{d_strtod} ought to be changed.

Could you test one more thing for me, please ?
When (if) you have the time, could you rebuild that source with the addition of -Ud_strtod to the configure args. That is:

make distclean
sh Configure -des -Dusedevel -Duse64bitall -Ud_strtod && make && make 
+test
[download]

I'm hopeful that will allow the lib/locale.t tests to pass without introducing more breakage elsewhere.
Thank you very much for the trouble you've taken and the information you've provided.

Cheers,
Rob

I've been a little despondent about the lib/locale.t failures ever since I became aware of them a few days ago.
But, tonight, I think I've found the correct way to deal with them.
Under make test there seems to be only the one failing test in lib/locale.t, but there's an additional 4 tests that fail if one runs ./perl -I./lib -T locale.t
There's no problem with those 5 tests on quadmath builds, irrespective of locale ... why is that ? ... it's because they're skipped on quadmath builds.

It then dawned upon me that if it's ok for quadmath builds to skip those tests, then it's ok for my patched approach to also skip them. (Like the quadmath builds, my approach also assigns NVs using the underlying C compiler via Perl_strtod.)
Having just modified lib/locale.t to skip those tests whenever Perl_strtod is defined, I find that all tests now pass !!

I just need to provide patches against current blead, and hope that I can get Karl and/or Jim to create another smoke-me branch for more testing.
If I can just get those patches into blead .....

Cheers,
Rob

I've managed to reproduce the lib/locale.t failure on my Ubuntu-16.04 box by switching locale to LANG=de_DE.UTF-8.

I wonder if it's possible to force a particular LC_NUMERIC which has decimal_point   "<U002C>" in /usr/share/i18n/locales/$locale for the lib/locale.t test set, while keeping it C for other categories as a way of verifying the cause of the failures.

make distclean
sh Configure -des -Dusedevel -Duse64bitall -Ud_strtod && make && make 
+test
[download]

lib/locale.t passes, but other tests don't:

Failed 2 tests out of 2458, 99.92% okay.
        ../ext/POSIX/t/posix.t
        run/locale.t
[download]

But that's not too mysterious:
Read more... (5 kB)
In particular, with those patches:
Read more... (1495 Bytes)
all tests pass.