gnuplot install failing, max OS 10.8.3 Xcode 4.6.1

[orren.saltzman@…]

summary pretty much says it, although I'm not sure these latest versions are really even supported yet. May just have to wait it out.

[orren.saltzman@…]

I should also add that I have already made sure I've agreed to the xcode license through "sudo xcodebuild -license".

[orren.saltzman@…]

and here's the terminal output:

sudo port install gnuplot
Password:
--->  Computing dependencies for gnuplot
--->  Staging gnuplot into destroot
Error: org.macports.destroot for port gnuplot returned: command execution failed
Please see the log file for port gnuplot for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_gnuplot/gnuplot/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnuplot failed

[ci42]

This was not a clean attempt. Run:

$ sudo port clean gnuplot
$ sudo port install gnuplot

and attach the log file if it fails again.

In the future please remember to Cc the maintainer and fill in the port field.

[orren.saltzman@…]

I've run it clean a few times after trying various other things. Just cleaned one more time and here's my result:

sudo port install gnuplot
--->  Computing dependencies for gnuplot
--->  Fetching archive for gnuplot
--->  Attempting to fetch gnuplot-4.6.2_0+aquaterm+luaterm+pangocairo+x11.darwin_12.x86_64.tbz2 from http://packages.macports.org/gnuplot
--->  Attempting to fetch gnuplot-4.6.2_0+aquaterm+luaterm+pangocairo+x11.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/gnuplot
--->  Attempting to fetch gnuplot-4.6.2_0+aquaterm+luaterm+pangocairo+x11.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gnuplot
--->  Fetching distfiles for gnuplot
--->  Verifying checksum(s) for gnuplot
--->  Extracting gnuplot
--->  Applying patches to gnuplot
--->  Configuring gnuplot
--->  Building gnuplot
--->  Staging gnuplot into destroot
Error: org.macports.destroot for port gnuplot returned: command execution failed
Please see the log file for port gnuplot for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_gnuplot/gnuplot/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnuplot failed

I've also attached a second log file for this new attempt.

[mojca (Mojca Miklavec)]

Here's what happens:

:info:destroot Making or updating menus in *doc2texi*...done
:info:destroot Done...updated all the menus.  You may save the buffer.
:info:destroot Saving file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_gnuplot/gnuplot/work/gnuplot-4.6.2/docs/gnuplot.texi...
:info:destroot Wrote /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_gnuplot/gnuplot/work/gnuplot-4.6.2/docs/gnuplot.texi
:info:destroot Compiling gnuplot-eldoc.el
:info:destroot End of file during parsing
:info:destroot make[1]: *** [gnuplot-eldoc.el] Error 255
:info:destroot make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_gnuplot/gnuplot/work/gnuplot-4.6.2/docs'
:info:destroot make: *** [install-recursive] Error 1

Oh, I think that I saw a similar problem once already, even though it was in a slightly different context. I think that I had problems when doing an out-of-source build.

This code comes from docs/Makefile.in which includes:

gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc: $(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc
  @echo "Creating texinfo and eldoc strings file"
  @if test "$(EMACS)" != no; then \
     test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \
     test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \
     $(EMACS) -batch -l $(srcdir)/doc2texi.el -f d2t-doc-to-texi ; \
     echo "Compiling gnuplot-eldoc.el" ; \
     $(EMACS) -batch --eval='(byte-compile-file "gnuplot-eldoc.el")' ; \
  else \
     echo "No emacs found - cannot create texinfo file" ; \
  fi

First of all, I have no idea why this fails. Second, independent of whether or not it fails, the code should not be executed as long as docs/gnuplot.texi is present.

But to start with, I believe that one of the problems might be that emacs is found (the one provided by the system, not the one provided by macports). Can you please try to set

export EMACS=no

then clean and reinstall gnuplot package just to see if this helps?

I once wrote the following patch to assist with out-of-source building without emacs, but I need to remember what it does and most probably I need to change it anyway.

--- a/docs/Makefile.in
+++ b/docs/Makefile.in
@@ -237,8 +237,8 @@ doc2ms.o: doc2ms.c $(BUILT_SOURCES)
 html: htmldocs/gnuplot.html
 
 # requires makeinfo (GNU texinfo) 4.0 or better
-# htmldocs/gnuplot.html: $(srcdir)/gnuplot.texi 
-#	$(MAKEINFO) --html -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+# htmldocs/gnuplot.html: gnuplot.texi
+#	$(MAKEINFO) --html -I$(srcdir) gnuplot.texi --no-split --output=$@
 
 # requires a working latex2html, which is hard to find these days
 # htmldocs/gnuplot.html: $(srcdir)/gnuplot.tex
@@ -389,18 +389,20 @@ wxhelp/doc2html: wxhelp/doc2html.o termdoc.o xref.o ../src/version.o
 ### GNU info format
 info: gnuplot.info
 
-gnuplot.info: $(srcdir)/gnuplot.texi
-	$(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+gnuplot.info: gnuplot.texi
+	$(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@
 
 # Thanks to Bruce Ravel for doc2texi.el!
 gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc: $(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc
 	@echo "Creating texinfo and eldoc strings file"
 	@if test "$(EMACS)" != no; then \
-	   @test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \
-	   @test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \
+	   test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \
+	   test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \
 	   $(EMACS) -batch -l $(srcdir)/doc2texi.el -f d2t-doc-to-texi ; \
 	   echo "Compiling gnuplot-eldoc.el" ; \
 	   $(EMACS) -batch --eval='(byte-compile-file "gnuplot-eldoc.el")' ; \
+	elif [ "$(top_srcdir)" != "$(top_builddir)" ] && [ -f $(srcdir)/gnuplot.texi ]; then \
+		cp $(srcdir)/gnuplot.texi . ; \
 	else \
 	   echo "No emacs found - cannot create texinfo file" ; \
 	fi

I'm not saying that it solves anything, in particular not in this situation, but it might ring a bell to someone trying to help diagnose the problem.

All-in-all: I'm confused.

[mojca (Mojca Miklavec)]

Or maybe I see (part of) the problem. It tries to compile files during make install (destroot) phase. I have a feeling that this should have happened earlier.

I also see that my non-emacs installation of gnuplot contains

  /opt/local/share/emacs/site-lisp/gnuplot-eldoc.el
  /opt/local/share/emacs/site-lisp/gnuplot-eldoc.elc

but it definitely shouldn't. There is a high chance that gnuplot works on my computer just because my "emacs" binary comes from macports. In any case, this needs some further diagnosis.

[orren.saltzman@…]

Tried exporting EMACS=no and doing a clean install, same result.

Might it help if I uninstalled emacs, reinstalled it through macports and tried again?

[mojca (Mojca Miklavec)]

Can you please attach the log from a build with EMACS=no? Or rather - can you please check that the following two lines are changed?

:info:configure checking for emacs... emacs
:info:configure checking for emacs... (cached) emacs

In case that they are changed and it still fails, please attach the log.

You could try to install emacs with macports (no need to uninstall the one provided by MacPorts) and see if that helps to get a working gnuplot binary, but then it would be helpful to uninstall emacs from macports again to test potential patches.

[orren.saltzman@…]

The log file still has these two lines, even after I say export EMACS=no. What am I doing wrong?

Thanks for all your help on this by the way.

[mojca (Mojca Miklavec)]

I don't think that you are doing anything wrong. I wouldn't be surprized if MacPorts would discard any ad-hoc environmental variables. Does adding

configure.env-append EMACS=no

somewhere (for example just below configure.args) help in any way?

[mojca (Mojca Miklavec)]

I just found:

• ​https://sourceforge.net/p/gnuplot/bugs/1219/ (Compilation of docs/gnuplot-eldoc.el fails with XEmacs)
• ​https://sourceforge.net/p/gnuplot/bugs/1226/ (gnuplot.texi fails to build)

Maybe those contain (part of) the answer.

[mojca (Mojca Miklavec)]

I also added ​https://sourceforge.net/p/gnuplot/bugs/1228/.

[mojca (Mojca Miklavec)]

A new version of gnuplot will be released very soon. Some tiny problem has been fixed in 4.6.3 (apparently make dist would always fail when --without-lisp-files is used), but I'm not sure if that patch actually solves the reported problem. I need more input/feedback/testing since I cannot reproduce the problem here.

[Ephaeton@…]

Uhm, comment redacted. My problem went away with updating and upgrading.

[mojca (Mojca Miklavec)]

Since I didn't get sufficient feedback, I'll upgrade gnuplot to 4.6.3 now. Please confirm that the problem is still there (or that it is gone) after upgrade. If I don't hear anything back, I'll close the ticket unless/until someone reopens it again. (Without being able to reproduce the bug myself and without getting enough feedback, there is no way that I can fix this.)

(Just to make it clear: I'm not able to reproduce the problem because I don't [want to] have 10.8. I'm not saying that the problem is not reproducible at all.)

[mojca (Mojca Miklavec)]

I'm closing the ticket for the lack of feedback. There is a tiny chance that 4.6.3 actually solved the problem, but I cannot know. If someone experiences the problem again, please leave more feedback and I will look into it again.