PRINTF_LONG_DOUBLE option

[kripken]

Add a libc variation that supports full long double precision printing.
It turns out that adding this is not that hard, building on the existing
work we've already done there.

One thing I dislike here is that an additional libc variation means we
double the number of libc builds, and the size of the libc builds in
the emsdk, I believe? I wonder if maybe this should not be built by
embuilder by default or something like that.

[sbc100]

One option would be to make a separate libc-long-double.a that gets included on the link line before libc itself when the option is enabled.

[kripken]

How would that get built @sbc100 ?

[sbc100]

It could be a new library just includes libc/musl/src/stdio/vfprintf.c and always is built with long double support.

Then the main libc could be unchanged/shared.

[kripken]

I see, thanks @sbc100 - rewritten to be that way now, much better I think!

[sbc100]

If you can, I would put this on line 1577 right before libc (using the same add_library helper)

[sbc100]

I guess that same goes for jsmath too?

[kripken]

I don't follow? Line 1577 is

        for haz in has_syms:
          if haz in need_syms:
            # remove symbols that are supplied by another of the inputs
            need_syms.remove(haz) # This is 1577..?
        if shared.Settings.VERBOSE:
          logger.debug('considering %s: we need %s and have %s' % (lib.name, str(need_syms), str(has_syms)))

So I'm not sure where you are suggesting to put this. But maybe the bigger issue is that this can't be moved earlier - it has to be after the sort operation on line 1641.

[sbc100]

Maybe you need to sync to head?

This line should come just before: add_library(system_libs_map['libc']).. order is important for all of the add_library function here.

The sort operations are are only for specific cases.. they won't apply to libc or this library (I will try to remove them.. they are porbably not needed anymore since that most recent changes here).

[kripken]

Thanks, done.

(Oh, I assumed when you said line numbers they were relative to this PR... otherwise which HEAD would I look at..? it can keep changing outside. Is there a convention I'm not aware of?)

[sbc100]

I just just been lazy to looking at my local line numbers... Your are right its not a very accurate way to communicate file positions :)

[sbc100]

Nice!

[sbc100]

Yay!