src/history.cpp:273:29: error: 'bzero' was not declared in this scope on illumos

[Mno-hime]

Build of fish 3.0.0 on OpenIndiana 2018.10 (illumos kernel) fails with:

  CXX      obj/history.o
src/history.cpp: In static member function 'static bool history_file_contents_t::read_from_fd(int, void*, size_t)':
src/history.cpp:273:29: error: 'bzero' was not declared in this scope
         bzero(ptr, remaining);
                             ^

#include <strings.h> in src/history.cpp fixed it for me.

illumos bzero(3C) man page: https://illumos.org/man/3c/bzero.

[mqudsi]

I used to make it a point to periodically build fish on Solaris, but was forced to stop when the build system broke in the switch to CMake, then that was fixed and fish 3.0 was released before I had a chance to do so.
Is that typically sufficient for OpenIndiana?

[Mno-hime]

Is that typically sufficient for OpenIndiana?

I am sorry, I don't understand what you mean...

The easier way to get OpenIndiana is to get it via Vagrant (https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/vagrant.md) or install it to VM from ISO.

Then one can proceed to the build system: https://wiki.openindiana.org/oi/Building+with+oi-userland.

[mqudsi]

My question, simply put, if it builds on Solaris is that typically good enough to build on OpenIndiana?

[mqudsi]

(Also, bzero(3) is deprecated and there's no reason for us to be using it anyway. I changed this over to memset(3) instead, which presumably fixes the problem.)

[Mno-hime]

Core OSes do not share code for some 10 years, naturally they diverge, so, it's increasingly similar to building on FreeBSD and assuming it works on DragonFly BSD. It may work, it may not. We are happy if you test on any illumos distribution (e.g. OpenIndiana) and are ready to help you in this regard.

[Mno-hime]

The fix worked for me. Thanks!

[stellarpower]

This is still present on 3.0.2, I am building on OmniOS and using the CMake build system (configure/make failed but could have been a trivial problem). I am happy to ditch the 3.0 branch and build 3.1b1, but plan to make this into a package and contribute it, so wasn't sure if 3.1 breaks any compatibilities or may be more desireable to install for end users, esp. if currently still in beta stage.

Can the bzero call here be changed to a memset then, and if so, is it worth making this change in the 3.0 line at all?
EDIT: It can and should be replaced, so I guess my question is would a fix to the 3.0 branch be worthwhile, or is development purely on 3.1 now?

@mqudsi - within the illumos world, as far as I know, different distributions are more or less specialised, and have a greater or fewer number of packages that will build as-is, or with few modifications - @Mno-hime would know better than me, but I think certain illumos OSs are seen as better candidates as a reference OS for building software for the illumos kernel.

[zanchey]

There are no plans to release a 3.0.3; I'd definitely recommend waiting for 3.1.0 (which is imminent).

[stellarpower]

Fine by me, I started building 3.1 last night and hit some error so will look that up later, but if there's no reason for anyone not to want the newer version then am happy to get that rolling and when 3.1.0 is out, package that up. Actually, if all goes well with it, would it be desirable to aim for subsequent releases to be compatible for illumos without patching? If 3.1 builds nicely for me on Omni and also works for OpenIndiana and SmartOS as minimum, could perhaps run regressions against any new releases and see if they can be fixed in time for inclusion such that in the future it works out of the box?

[zanchey]

If 3.1 builds nicely for me on Omni and also works for OpenIndiana and SmartOS as minimum, could perhaps run regressions against any new releases and see if they can be fixed in time for inclusion such that in the future it works out of the box?

Yes, we would welcome that!