Tag a new release - 0.5

[ViralBShah]

With the ppc support, I think we should tag a new release - 0.5. Is there anything else we need to do before we tag?

[tkelman]

We should probably run julia's tests against it on a variety of platforms.

[ViralBShah]

What's the best way to do so? The changes here are minor and there are no api changes - so I think this is pretty safe.

[StefanKarpinski]

Is it likely that there will be and API changes in the future? If not, then a 1.0 release may be warranted. Bugfixes would go into 1.0.x releases; new exported functions would go in 1.x releases, and any breaking API changes (including deleting exported functions) would require a 2.0 release.

[tkelman]

What's the best way to do so?

Prepare the Julia PR that changes the openlibm.version and checksum files first, run it through CI before doing the tag here?

Is it likely that there will be and API changes in the future?

Not necessarily API changes, but in terms of code #108 will be pretty big and still needs some cleanup. I also think we should look carefully at what musl has done with their libm since they started from pretty much the same code bases we did, but have been better at maintaining and pulling in bug fixes.

[ViralBShah]

Can you point to the musl implementation? The issue we have faced is that we never automated the migration from msun. It needs a bunch of sed scripts really, and unfortunately I didn't save that in #108. I'll have to do it once more carefully.

[ViralBShah]

By definition, there should be no major API changes, since the goal is to be a libm replacement. I would like to sort out #108 and keeping up with msun before tagging 1.0.

[tkelman]

http://git.musl-libc.org/cgit/musl/tree/src/math - looks like they don't have powerpc support (edit: at least not as optimized assembly) at the moment though

[ViralBShah]

That code looks quite clean! Do they maintain a record of what all they pull in from msun and how frequently?

[tkelman]

http://git.musl-libc.org/cgit/musl/log/src/math

[ViralBShah]

I meant tracking the msun logs. Looks like it started from msun, but has significantly changed, and ongoing fixes are manually tracked. I'll try this out to see if there is merit in following musl instead of msun before refreshing msun.

[ViralBShah]

Detailed notes on the musl approach - http://nsz.repo.hu/libm/

Many functions have been completely rewritten in musl since the original checkin.

[tkelman]

The numpy maintainers have also brought up bionic's libm, used on android: https://github.com/android/platform_bionic/tree/master/libm

[ViralBShah]

Bionic looks nice in that it does closely follow msun.

[ViralBShah]

I think at the very least, we should follow the bionic model here, and maintain a set of patches external to msun that we need in openlibm. With that we can be 1.0.

I love what the musl guys have done, but need to check with them on long term maintenance plans and understand the community momentum, before we adopt that as the way forward. What Szabolcs Nagy has done there, is what I wanted to do with openlibm in the first place, but he's done really amazing stuff.

[nalimilan]

I've just checked that building a RPM works with GCC6, and that's OK. But tests fail on i686:

+ make -C test test-float
make: Entering directory '/builddir/build/BUILD/openlibm-master/test'
gcc  -O2   test-float.c -D__BSD_VISIBLE -I ../include -I../src -L.. -lopenlibm -Wl,-rpath=/builddir/build/BUILD/openlibm-master -o test-float
../libopenlibm.so: undefined reference to `fpsetprec'
../libopenlibm.so: undefined reference to `fpgetprec'
collect2: error: ld returned 1 exit status
Makefile:18: recipe for target 'test-float' failed

test-float used to pass on i686, though test-double failed. (Tests also fail on ARMv7 but that was already the case with 0.4.)

Also, do we actually need to bump the SOVERSION to 2? Did the API really break?