Fri 10 Feb 2012 05:36:47 PM UTC, comment #13:
Closing bug as it applies to a release candidate before 3.4.0. It can be re-opened if the reporter can verify there is still a problem with a current release such as 3.6.0.
|
Sun 02 Oct 2011 02:33:09 PM UTC, comment #12:
It is up to jwe.
|
Wed 28 Sep 2011 07:23:13 PM UTC, comment #11:
Can this issue be closed? It applied to a development version before 3.4.0.
|
Sat 29 Jan 2011 11:19:39 AM UTC, comment #10:
Agreed, your patch works fine, so it's up to you.
|
Thu 27 Jan 2011 10:40:37 PM UTC, comment #9:
John, it would be fine with me to use the X_PATH_XTRA macro, but if my simpler change for you works now, I think I will go with that for now and reexamine this change after the release.
Guillaume, I think this is a separate issue from the detection of X11 libraries. But yes, you are right that we should not be calling _fltk_redraw_ unless the fltk toolkit is used, and we should probably not be calling any toolkit-specific code like this except from a generic function that dispatches to the toolkit-specific code... I will discuss that with the person who made that change.
|
Thu 27 Jan 2011 10:26:22 PM UTC, comment #8:
Following comment #6,
you were right, it worked only because -lX11 was already in
GRAPHICS_LIBS.
When configuring with --without-opengl --without-framework-opengl
GRAPHICS_LIBS is empty, no -lX11 at all, and the build fails.
So, as counterintuitive as it seems to me,
we have to add -lX11 to X_LIBS manually.
The attached patch corrects the configure.ac from comment #3.
(file #22540)
|
Thu 27 Jan 2011 01:21:35 PM UTC, comment #7:
Sorry to mention this again here as this is a diversion but when compiling with flags --without-opengl --without-framework-opengl and without having fltk, I get a crash at the end of compilation (when building the doc?) with:
Shouldn't this call to `__fltk_redraw__' be surrounded by:
|
Wed 26 Jan 2011 10:56:15 PM UTC, comment #6:
I didn't see -lX11 anywhere, and all the X_ variables were empty, so I didn't see how the build could work.
|
Wed 26 Jan 2011 10:07:23 PM UTC, comment #5:
Your patch works fine here, but
given the hours already spent on this AC_PATH_XTRA stuff
(comment #3), I would like to go further.
Here also the X_* variables are empty, except X_LIBS = -lSM -lICE
but the build is just fine, and the fltk backend plots correctly.
Did you have any error during the build/run or
did you stop after the configure step, because the X_* were empty ?
Maybe I should have added the display of X_DISPLAY_MISSING ?
|
Wed 26 Jan 2011 08:24:51 PM UTC, comment #4:
This change does not seem to work for me. The configure script does not seem to check for X, and I get empty values for all four of the new X_ variables.
To fix the original problem of the explicit -L/usr/X11R6/lib flag being added to the check for the GL library, I checked in the following change.
http://hg.savannah.gnu.org/hgweb/octave/rev/eceacb78aa7f
Does this work for you?
For now, if OpenGL headers and libraries are in a location not searched by default, then the directories can be added to CPPFLAGS and LDFLAGS when running the configure script.
|
Tue 25 Jan 2011 10:14:52 PM UTC, comment #3:
Following jwe comment #1, here is a patch for using the
AC_PATH_XTRA macro. some names have been changed to be consistent
with the autoconf manual for AC_PATH_XTRA:
http://www.gnu.org/software/autoconf/manual/autoconf.html
in the base directory,
patch -p1 < xtra.patch
./autogen.sh
./configure <options>
make
works for me, but please be careful...
(file #22516)
|
Tue 18 Jan 2011 11:32:40 AM UTC, comment #2:
Just to mention that I have the same error during compilation (OpenSuse 11.3 64bit).
In the meantime I compile with:
./configure --without-opengl --without-framework-opengl
which is working fine apart from this error at the end of compilation:
error: `__fltk_redraw__' undefined near line 40 column 5
error: called from:
error: /.../octave/scripts/plot/private/__axis_label__.m at line 40, column 5
error: /.../octave/scripts/plot/title.m at line 33, column 7
|
Mon 17 Jan 2011 10:47:04 PM UTC, comment #1:
I don't think the /usr/X11R6/lib path should be hardcoded like that. I guess we should be using the AC_PATH_XTRA macro instead of AC_PATH_X, and then using what it finds instead.
|
Mon 17 Jan 2011 10:13:23 PM UTC, original submission:
|