bugGNU Octave - Bugs: bug #55273, mkfifo returns "Function not...


bug #55273: mkfifo returns "Function not implemented" error

Submitted by:  Carlo de Falco <cdf>
Submitted on:  Sun 23 Dec 2018 04:02:11 PM UTC  
Category:  Configuration and Build System Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  5.0.0 Operating System:  Mac OS

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 30 Dec 2018 11:52:52 AM UTC, comment #23:

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Sun 30 Dec 2018 01:56:22 AM UTC, comment #22:


Thanks for the gnulib update and the merge to default. Gnuplot now works for me on macOS.

Ben Abbott <bpabbott>
Project Member
Sat 29 Dec 2018 07:05:34 AM UTC, comment #21:

I'm in Singapore this week. I get a time-out when pulling the gnulib repo.

Ben Abbott <bpabbott>
Project Member
Fri 28 Dec 2018 10:07:17 PM UTC, comment #20:

I have updated the gnulib subrepo to fix this bug on the stable branch. Please comment if you can update and verify that this is fixed now.


Mike Miller <mtmiller>
Project Administrator
Fri 28 Dec 2018 07:27:50 PM UTC, comment #19:

Yeah, I reported the bug upstream to Gnulib and they put in a fix: http://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00147.html

Andrew Janke <apjanke>
Fri 28 Dec 2018 06:30:39 PM UTC, comment #18:

I built using a local copy of gnulib's master branch and HAVE_MKFIFO is now again defined in config.h.

I think we should do a gnulib update on the stable branch to fix this bug, but I'm having troubles with the gnulib mirror, so it may take a little doing.

If you want to test locally on macOS, you can use git to clone the gnulib repository anywhere on your system, and run Octave's bootstrap with the --gnulib-srcdir option. On my system, this looks like

Mike Miller <mtmiller>
Project Administrator
Fri 28 Dec 2018 04:57:54 PM UTC, comment #17:

The quickest fix for this will be to add 'mkfifo' to the list of functions tested by AC_CHECK_FUNCS here: https://hg.savannah.gnu.org/hgweb/octave/file/44670b45ff3b/configure.ac#l1187

Maybe with a comment to point out that this will be fixed by a gnulib update at some point.

In the meantime I see that Andrew has reported this to gnulib and this may be fixed there quickly, in which case Octave can update its gnulib pointer. https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00147.html

Mike Miller <mtmiller>
Project Administrator
Fri 28 Dec 2018 07:14:19 AM UTC, comment #16:


macOS spell check ("contour" -> "configure").


I did have file #45382 applied. While I got a seg-fault, Octave did not hang. However, at your suggesting, I decided a clean build was in order. With a clean build I now have a functioning gnuplot and no seg-fault!

2) Apply file #45382 from bug #50025.

Ben Abbott <bpabbott>
Project Member
Fri 28 Dec 2018 12:49:22 AM UTC, comment #15:


I'd assumed that CPPFLAGS=-DHAVE_MKFIFO told contour that I already have mkfifo, and that the one from gnulib isn't needed.

Thanks for clearing that up.

Ben Abbott <bpabbott>
Project Member
Thu 27 Dec 2018 09:06:42 PM UTC, comment #14:

@Ben: maybe your segfault is #50025 rearing its head? I'm also getting segfaults during the doco-building stage:

But when I apply patch https://savannah.gnu.org/support/download.php?file_id=45382 from #50025, they go away.

Andrew Janke <apjanke>
Thu 27 Dec 2018 07:36:04 PM UTC, comment #13:


Adding CPPFLAGS=-DHAVE_MKFIFO fixes it for me too.

And I can confirm that on macOS, for me, the gnulib trailing-slash-bug fix is being used. I put debugging statements into the libgnu mkfifo.c:

and the rpl_mkfifo() is showing up in the `make` output:

I was also able to get it to build by sticking an AC_DEFINE in configure.ac before the gl_INIT call:

But I don't know how that will behave on systems that don't have mkfifo.

Andrew Janke <apjanke>
Thu 27 Dec 2018 06:42:17 PM UTC, comment #12:

You are using mkfifo from gnulib. If you want to avoid using it (which has never been the case in any of your previous builds either), you would have to do some deeper autoconf surgery to disable the check that sets REPLACE_MKFIFO.

Mike Miller <mtmiller>
Project Administrator
Thu 27 Dec 2018 10:13:22 AM UTC, comment #11:

Opps, just noticed a new seg-fault when exiting.

Is there a way to do the reverse and force the use of mkfifo from gnulib?

Ben Abbott <bpabbott>
Project Member
Thu 27 Dec 2018 09:42:10 AM UTC, comment #10:


Yes. Adding CPPFLAGS=-DHAVE_MKFIFO fixes the problem.


Ben Abbott <bpabbott>
Project Member
Thu 27 Dec 2018 07:02:13 AM UTC, comment #9:

Thank you for the details and confirmation that on macOS, Octave should be using the gnulib mkfifo shim function.

I have just compared my config.h from 4.4.1 against config.h from 5.0.1, and HAVE_MKFIFO is no longer declared in config.h. I think this is most likely the piece that is missing. Since my system has a fully functional mkfifo, REPLACE_MKFIFO is false, and libgnu/mkfifo.c is not compiled at all.

I think this bug is due to this change: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=b24b6bbf9cf4cdc0d5d011b20dd74916507a6153

With AC_CHECK_FUNC no longer called, HAVE_MKFIFO is no longer declared as a preprocessor macro to be listed in config.h. This breaks the gnulib mkfifo.c source file. I think this is probably worth reporting to the gnulib project for a fix. In the meantime, Octave can work around this by adding to configure.ac:

Can someone check whether CPPFLAGS=-DHAVE_MKFIFO fixes this bug?

Mike Miller <mtmiller>
Project Administrator
Thu 27 Dec 2018 04:33:21 AM UTC, comment #8:

I think the REPLACE_MKFIFO might be a red herring: it looks to me like the way it works is that when activated, instead of defining a `mkfifo` function, it defines `rpl_mkfifo` function in mkfifo.c, which works in conjunction with a `mkfifo` macro in gnulib's `sys_stat.h` header, so that you end up calling that instead of the system mkfifo.

The error we're seeing here looks more symptomatic of HAVE_MKFIFO being set to 0, and thus a mkfifo function defined in gnulib's mkfifo.c, and that's shadowing the system mkfifo.

Now, I don't see a HAVE_MKFIFO defined in the config.h present after doing a configure. (I see it in config.status, but not config.h. And it's not in the lower part of config.status that looks like it generates config.h) Maybe that's the issue? I don't see how the HAVE_MKFIFO C macro would make its way down to libgnu's mkfifo.c otherwise.

config.in.h also does not have HAVE_MKFIFO there for substitution. So maybe the problem boils down to the autoheader step of configure not emitting some of those names?

Though weirdly, the built mkfifo.o in libgnu does not had a mkfifo symbol; it has a rpl_mkfifo.

So I don't know where the error-raising mkfifo implementation is coming from then. Confusing: after a build, none of the resulting .o files contains a mkfifo function:

Andrew Janke <apjanke>
Thu 27 Dec 2018 02:43:54 AM UTC, comment #7:

Maybe just naive, but I tried copying mkfifo.c from 4.2.1 to the default branch, and ran configure/make.

The "Function not implemented" is still present when using the gnuplot toolkit.

Ben Abbott <bpabbott>
Project Member
Thu 27 Dec 2018 02:27:19 AM UTC, comment #6:


With 4.2.1, in config.status

With the current default branch

Ben Abbott <bpabbott>
Project Member
Wed 26 Dec 2018 11:15:28 PM UTC, comment #5:

On my system (macOS 10.13.6, dependencies installed via Homebrew, building from a recent-ish checkout of the octave Hg repo), it looks like REPLACE_MKFIFO is getting set.

In libgnu/Makefile, after doing the configure, there is this at line 2005:

As to how the values get passed, I think the gnulib configure process is setting it rather than it being passed in from Octave's configure process. (Or maybe the check is still being done, but Octave's configuration results then override it?) In my `configure` output, I see this:

It does that mkfifo check twice, so I assume the second one is the one in gnulib. (Maybe that's what the "configure:NNNN:" prefix means, too?)

Maybe REPLACE_MKFIFO is getting set because configure detects the "mkfifo trailing slash bug" on my system. In octave's configure, I see this:

which I think is from `m4/mkfifo.m4` here:

I think that means that MKFIFO_TRAILING_SLASH_BUG enables REPLACE_MKFIFO.

And in my configure output, it looks like it got set:

I wonder how it's getting set? Since that configure result for "rejects trailing slashes" was "no", maybe that is the buggy state? I can't read auctoconf stuff to work out exactly what the logic in mkfifo.m4 is.

Andrew Janke <apjanke>
Wed 26 Dec 2018 10:49:40 PM UTC, comment #4:

To be clear, I am still hoping for some more information from someone affected by this bug.

The values of both HAVE_MKFIFO and REPLACE_MKFIFO from config.log. Both for a previous version of Octave that worked (4.4.1? even earlier?) and the current stable branch 5.0.1 that doesn't work.

It would also be helpful to confirm whether mkfifo.lo exists in the libgnu build directory, both in a previous version of Octave where mkfifo worked and in the current broken release.

Mike Miller <mtmiller>
Project Administrator
Tue 25 Dec 2018 01:19:39 AM UTC, comment #3:

A quick check of the changelog entries didn't help. The gnuplot backend worked for me in 2016 and 2017.

Ben Abbott <bpabbott>
Project Member
Mon 24 Dec 2018 01:15:39 AM UTC, comment #2:

Until mid-late 2017, I favored running gnuplot via the current state of the default branch. I expect someone with bisect experience could automate tracking down the reversion. Unfortunately, there were a few months when macOS was broken. Hence, bisecting may be more hassle than help.

Since this is libbnu, is there a way to switch which libbnu is being used? Maybe try bisecting libgnu releases?

Ben Abbott <bpabbott>
Project Member
Sun 23 Dec 2018 09:02:21 PM UTC, comment #1:

I would also check the value of REPLACE_MKFIFO, this determines whether libgnu/mkfifo.c is compiled in or not. If it is true, then you should check whether HAVE_MKFIFO is being passed in to that module correctly. I'm not sure I understand how some of the HAVE_foo macros get passed in to gnulib's source files, since they are not all in Octave's config.h.

If REPLACE_MKFIFO is true on your system, but the module is somehow being compiled without HAVE_MKFIFO, then that would explain where the ENOSYS error is coming from (libgnu/mkfifo.c line 32).

Mike Miller <mtmiller>
Project Administrator
Sun 23 Dec 2018 04:02:11 PM UTC, original submission:

running mkfifo on macos returns an error

this is strange as mkfifo appears to be detected as present by configure, as shown by the following lines in config.log

a consequence of this is that the gnuplot graphics backend is not working

Carlo de Falco <cdf>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by apjanke
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by cdf (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-30 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2018-12-28 mtmiller StatusIn Progress => Ready For Test
    2018-12-28 mtmiller Severity3 - Normal => 4 - Important
        StatusNeed Info => In Progress
    2018-12-26 apjanke Carbon-Copy- => Added -email is unavailable-
    2018-12-23 mtmiller StatusNone => Need Info

    Back to the top

    Powered by Savane 3.4