bugGNU Octave - Bugs: bug #47886, Do not link against libraries...


bug #47886: Do not link against libraries without OpenGL

Submitter:  None
Submitted:  Tue 10 May 2016 01:19:47 PM UTC
Category:  Configuration and Build System Severity:  4 - Important
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Marcus Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Fri 11 Nov 2016 04:04:30 AM UTC, comment #14: 

I pushed a changeset for this bug here (http://hg.savannah.gnu.org/hgweb/octave/rev/dc828d9a7f3a).  The thing you were looking for was octave_unused_arg() to suppress the compilation warning message for a particular input.

Rik <rik5>
Project Administrator
Thu 10 Nov 2016 11:14:52 PM UTC, comment #13: 

OK, got it.  (How quickly I forget... I also remember some type of buffer mechanism being introduced to OpenGl that might accomplish what OSMesa does, but it wasn't far along when I had read that.)

Anyway, as for the TeX error, here's more verbose:

/home/sebald/octave/octave/octave/doc/interpreter/octave.texi:99: epsf.tex not
found, images will be ignored.
@image ...f.tex not found, images will be ignored}
                                                  @global @warnednoepsftrue ...
l.99 @flushright @image{octave_logo,2.1in}

I saw octave_logo.* files being produced.  Hold on, "epsf.tex", let's see if I'm missing that on my system...

Octave successfully built.  Now choose from the following:


I'm seeing some figures in the interpreter/octave.pdf file.  They aren't the most crisp images that gnuplot can produce, but that's for some other time.

So, Rik's change seems adequate to make compile succeed.  Thanks.

Dan Sebald <sebald>
Thu 10 Nov 2016 10:21:40 PM UTC, comment #12: 

They are related but not intrinsically. Gl2ps is used to turn OpenGL into Postscript, whether the figure is on-screen or off-screen. OSMesa is used as an alternative GL buffer mechanism to render OpenGL off-screen, and then gl2ps is used to print it to Postscript.

If you never use the print() or saveas() functions to print a figure to a file, you don't need gl2ps. If you only print() plots when they are visible on the screen with a working video card and OpenGL stack, then you don't need OSMesa at all.

Mike Miller <mtmiller>
Project Administrator
Thu 10 Nov 2016 10:14:59 PM UTC, comment #11: 

There are two locations, so I used:

@ ~/octave/octave/octave $ hg diff
diff --git a/libinterp/corefcn/gl2ps-print.cc b/libinterp/corefcn/gl2ps-print.cc
--- a/libinterp/corefcn/gl2ps-print.cc
+++ b/libinterp/corefcn/gl2ps-print.cc
@@ -28,7 +28,7 @@ along with Octave; see the file COPYING.
 #include "errwarn.h"
 #include "gl2ps-print.h"

-#if defined (HAVE_GL2PS_H)
+#if defined (HAVE_GL2PS_H) && defined (HAVE_OPENGL)

 #include <cstdio>

@@ -802,7 +802,7 @@ namespace octave
   gl2ps_print (const graphics_object& fig, const std::string& stream,
                const std::string& term)
-#if defined (HAVE_GL2PS_H)
+#if defined (HAVE_GL2PS_H) && defined (HAVE_OPENGL)

     // FIXME: should we have a way to create a file that begins with the
     // character '|'?

This does create an unused variable within the gl2ps_print function:

/home/sebald/octave/octave/octave/libinterp/corefcn/gl2ps-print.cc:802:3: warning: unused parameter 'fig' [-Wunused-parameter]
   gl2ps_print (const graphics_object& fig, const std::string& stream,

What command is used to touch the 'fig' parameter to get rid of the warning?

Anyway, it's running and I don't see any doc/ segfaults... texi files... eps files... ohhh, had my hopes up there.  OK, seeing this error:

  TEXI2DVI doc/interpreter/octave.dvi
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [doc/interpreter/octave.dvi] Error 1
make[2]: Leaving directory `/usr/local/src/octave/octave/build1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/octave/octave/build1'
make: *** [all] Error 2

I'll investigate what that issue is.

Mike, "--without-OSMesa" would be fine with me, but I must have forgotten about it.  I will try.  Aren't OSMesa and gl2ps ultimately tied together?

Dan Sebald <sebald>
Thu 10 Nov 2016 09:52:41 PM UTC, comment #10: 

Aren't gl2ps functions used in just a single file: gl2ps-print.cc?  If that is the case then I think this would be easy to address this as Mike suggested in comment #7 by adding an extra #ifdef check.

The current code is

// Both header files are required outside of HAVE_GLP2S_H
#include "errwarn.h"
#include "gl2ps-print.h"

#if defined (HAVE_GL2PS_H)

@Dan: Try changing this line to

#if defined (HAVE_GL2PS_H) && defined (HAVE_OPENGL)

and see if that works.

Rik <rik5>
Project Administrator
Thu 10 Nov 2016 09:51:06 PM UTC, comment #9: 

If the problem is with building documentation, I think the option you want is "--without-OSMesa" (note mixed case). Octave will still be built with support for on-screen figures with OpenGL, just not printing of invisible figures, and the documentation plots will be built using gnuplot.

Mike Miller <mtmiller>
Project Administrator
Thu 10 Nov 2016 09:41:14 PM UTC, comment #8: 

For me, as I recall, the issue with building documentation lies with the gl2ps (Nvidia driver issue?).  So #1 is fine with me, but I'm sure others might not be happy.  What I was trying to do here was simply disable the OpenGL/gl2ps to achieve a "make install" (so the short and easy "octave-cli" works with valid documentation), and then rebuild with everything active for development/debugging purposes.

I would think that --without-opengl might imply --without-gl2ps in the make environment.

Dan Sebald <sebald>
Thu 10 Nov 2016 09:09:55 PM UTC, comment #7: 

As I re-read what I posted earlier, I think that I thought that the original patch provided here is unsuitable.

We used to have a configure script that had dependencies on various libraries. If configure did not detect OpenGL, then it wouldn't bother checking for FLTK, and so on. We changed the configure script for 4.2 to eliminate those hierarchical dependencies and make the logic more flat and straightforward, and I think we want to preserve that approach.

With that in mind, a couple approaches that might work here:

1. add a "--without-gl2ps" option to configure
2. add more #if conditionals in the code to avoid compiling sections of code that require both OpenGL and gl2ps, instead of just checking for HAVE_GL2PS

Other ideas?

Mike Miller <mtmiller>
Project Administrator
Thu 10 Nov 2016 09:02:49 PM UTC, comment #6: 

I don't see the

+if test "$opengl_graphics" = yes; then

conditionals in the current development code.  This patch must not have been applied.  The first code hunk fails (the removing of the code) while the second succeeds:

@ ~/octave/octave/octave $ patch -p0 --dry-run < ~/octave/bug_47886/patch-configure.diff
checking file configure.ac
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 1266.
Hunk #2 succeeded at 528 with fuzz 1 (offset -1124 lines).
1 out of 2 hunks FAILED

The subtract/add code ends up in two different hunks in the patch, which typically isn't the case.  I suppose some small change was made recently in the configure.ac file.

If this patch is fixed and applied, will it solve the problem?  From the sounds of it, there may still be a remaining issue.

Dan Sebald <sebald>
Mon 08 Aug 2016 07:28:34 PM UTC, comment #5: 

No, this is not fixed. I just built Octave with `--without-opengl --without-qt --without-fltk`, and it still links with libgl2ps.so which implicitly links with libGL.so. This can be checked with either

$ ldd libinterp/.libs/liboctinterp.so | grep libGL
        libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f63503a5000)

or with

$ ./run-octave -cli
octave:1> getpid
ans =  13622
octave:2> ^Z
[1]+  Stopped                 ./run-octave -cli
$ grep libGL /proc/13622/maps
7f0f60c5d000-7f0f60cca000 r-xp 00000000 fe:01 6820492                    /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
7f0f60cca000-7f0f60ec9000 ---p 0006d000 fe:01 6820492                    /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
7f0f60ec9000-7f0f60ecc000 r--p 0006c000 fe:01 6820492                    /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
7f0f60ecc000-7f0f60ecd000 rw-p 0006f000 fe:01 6820492                    /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0

I also hit a build failure with this configuration, reported now as bug #48724.

Mike Miller <mtmiller>
Project Administrator
Mon 08 Aug 2016 01:20:12 AM UTC, comment #4: 

@Mike: Has this been fixed?  And is there an easy way to check the resulting binary to verify that LibGL is not linked in?

Rik <rik5>
Project Administrator
Tue 10 May 2016 06:41:06 PM UTC, comment #3: 

I meant that the liboctinterp.so library is not linked against libGL.so directly, because --without-opengl was stated, but it is indirectly linked via libgl2ps.so for example.

Hmm, I suppose that's another level to this bug, that even if we make the code conditional on HAVE_OPENGL and have no unresolved symbols as the OP reports, we will still be linking with GL2PS_LIBS, which may still force a link with libGL if the system is configured that way.

Mike Miller <mtmiller>
Project Administrator
Tue 10 May 2016 06:37:57 PM UTC, comment #2: 

Mike, do you mean that the final link command for libinterp doesn't include the fltk, gl2ps, freetype, and fontconfig libraries, but that they are still somehow linked with Octave (when examining what is actually linked using ldd, for example)?  Or are these libraries still listed in the linker command?

We should probably have --without-LIB options for all optional libraries.

John W. Eaton <jwe>
Project Administrator
Tue 10 May 2016 06:21:58 PM UTC, comment #1: 

I can confirm that building Octave with --without-opengl still links with fltk, gl2ps, freetype, and fontconfig, and libGL indirectly through one or more of these libraries.

I do not get the error shown here because on my system the OpenGL libraries are pulled in via gl2ps or fltk, so no unresolved symbols. But the end result is linked with libGL.

The provided patch attempts to put the logic back into configure to bypass checking for things that may depend on OpenGL.

I think we should fix this in the code, if possible, if there is a code module that depends on both gl2ps and OpenGL, then more conditionals should be added to ensure that it isn't built without both of them enabled. The module that fails to link that you've shown does indeed have OpenGL calls in the code, so maybe it should be conditioned against both HAVE_GL2PS and HAVE_OPENGL.

Mike Miller <mtmiller>
Project Administrator
Tue 10 May 2016 01:19:47 PM UTC, original submission:  

I maintain the development version of Octave for the MacPorts Project.
We offer users the option of turning off support for FLTK or QT and plotting with gnuplot.
Turning off FLTK or Qt is easy (--without-fltk or --without-qt).
Without FLTK and Qt, there seems to be no reason to link against OpenGL.
Indeed, there is code to that effect in configure.ac

if test $build_qt_graphics = no && test $build_fltk_graphics = no; then

Without OpenGL, there seems to be no need for GL2PS, Fontconfig, or FreeType (or Xft or OSMesa, but they are not needed on OS X).
Turning off OpenGL is easy (--without-opengl), but there seems to be no way of stopping configure.ac from looking for GL2PS, Fontconfig, or FreeType.

If the user happens to have these libraries, then Octave unnecessarily links against them.
More problematic, if --without-opengl is given and GL2PS is found, then the file
libinterp/corefcn/gl2ps-print.cc causes an error at link time
HAVE_GL2PS_H is 1, so glGetIntegerv and glRasterPos3d (and perhaps others) are called but cannot be found since the OpenGL libraries are not linked in.

  CXXLD    libinterp/liboctinterp.la
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
  "_glGetIntegerv", referenced from:
      gl2ps_renderer::draw_axes(axes::properties const&) in libcorefcn.a(libinterp_corefcn_libcorefcn_la-gl2ps-print.o)
  "_glRasterPos3d", referenced from:
      gl2ps_renderer::render_text(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, double, double, double, int, int, double) in libcorefcn.a(libinterp_corefcn_libcorefcn_la-gl2ps-print.o)
ld: symbol(s) not found for architecture x86_64

I am building with the latest development version on OS X version 10.11.4 with the clang compiler, but I believe this issue would affect all users.
Attached is a proposed solution, but concerns were expressed about a previous version.



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

Attach Files:

Attached Files
file #37119:  patch-configure.diff added by None (5KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-11 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-07-01 rik5 Severity3 - Normal 4 - Important
    2016-05-10 mtmiller StatusNone Confirmed
    2016-05-10 None Attached File- Added patch-configure.diff, #37119

    Back to the top

    Powered by Savane 3.9