Is gnulib still necessary for Octave?

What was the historical reason that Octave uses gnulib in the first place? Are those reasons still applicable or have recent standard libraries made them redundant?

I’m genuinely curious whether gnulib is adding any functionality not already covered by standard libc implementations for example.

I don’t know the fulll extent of gnulib that we use but we at least used some of the filesystem stuff that would require C++17.

Historical reason is that even standard implementations contained bugs or were platform dependent though the standard said they shouldn’t be. Thus, gnulib worked around bugs in libc itself. Over time the implementations of libc and libstdc++ tend to approach the standard, but then the standard itself changes every so often (C++11, C++14, C++17, etc.) so there can be discrepancies. I don’t know how good current implementations are, but my feeling when I posted before is that this isn’t a good use of Octave programmer’s time.

Agreed that it wouldn’t be a good use of Octave development time to babysit libraries. I was thinking whether it’s viable for us to drop gnulib (one fewer item to maintain) if libc / libm are good enough, or if that will only bring back old problems. If I understand correctly, right now the benefits of gnulib outweigh the cost of having to maintain it?

Which costs of maintaining gnulib are you alluding to? Gnulib is maintained upstream for us…

I was referring to e.g. having to bundle gnulib with Octave, so running the bootstrap script downloads an additional 50 MB of gnulib sources each time the Octave source is cloned. In an ideal world with libc & libm being reliably standards-compliant across platforms we wouldn’t need to carry that extra baggage, but I acknowledge that the current solution is still necessary as of now.

My thinking was prompted by rik’s question about whether we can outsource more things to libraries that we can expect the user to already have.

Good point. I’m not sure what’s the rationale for the fonts. Gnulib doesn’t make releases and it was only meant to be copied into whatever project uses it. I wonder if we’d do it if it was now. Anyway, that’s not the case with Boost. Boost makes releases that can be installed just fine which others can use.

2 Likes

I think we include a few fonts so there is something available that we know will work.

Gnulib attempts to provide a set of POSIX functions that will work correctly on all the systems that gnulib supports and also some other utility functions that are not part of the POSIX spec.

For the replacement/bug fix functions, it is true that modern Linux systems probably don’t need much but I think Windows needs more fixes and/or replacements for missing functions.

Using gnulib was a big improvement from trying to work around bugs or missing functions individually in every project, many of which used convoluted #ifdef blocks in many places (see gnuplot sources, for example).

I’m in favor of moving to standard C++ functions where possible. But we still have the problem that some C++ implementations may provide buggy libraries. We still may need configure tests and replacements for those problems.

As far as I know, gnulib doesn’t provide a lot of fixes for deficient math functions.

Using Boost might be OK, but I’d like to consider each case individually.

Also remember that fixing a call to any function (whether it is using gnulib to work around buggy POSIX implementations using something like boost::math::acosh (x) as shown in an earlier comment) only fixes the calls from Octave where we specifically set things up so that the replacements are used. It doesn’t do anything to fix the bad results from those functions when they are called from other libraries.