Octave & FLTK on OSX to compile with non-Apple G++ (64-bit) :-)

[Jarno Rajahalme]

Now that FLTK builds with 64 bit mode, I for the first time tried to compile Octave with FLTK. There were couple of problems:

1) FLTK draws in Objective-C (2.0) dependent OSX headers that do not compile with non-Apple versions of GCC, since no-one has implemented Objective-C 2.0 features for FSF-GCC.

2) Going back to Apple GCC 4.2 revealed that the gnulib bug redefining int64_t on 64-bit mode still exists: Octave fails to link. This can be fixed with patching the libgnu/stdint.h, but this patching is not needed for GCC >= 4.4.

3) OSX headers define a "Cell" symbol that conflicts with Octave's "Cell". (First) I got around this by "#define Cell __NS_Cell" before the FLTK includes in fltk_backend.cc, followed by an undefine before progressing after those includes.

With the above, I get the following, using macports fltk-devel (1.3.x-r7794):

octave:1> backend fltk

octave:2> plot([1 4 2 3 1])

2010-11-24 19:25:35.372 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072d9f70 of class NSObject autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.374 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072e4670 of class NSCFString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.375 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072c9240 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.375 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072e6470 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.375 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x107543680 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.376 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x107543680 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.376 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x107543680 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.377 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x107500b30 of class NSCFDictionary autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.380 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072f4c80 of class NSCalibratedRGBColor autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.380 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x107500b30 of class NSCFDictionary autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.381 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072318e0 of class NSConcreteMutableAttributedString autoreleased with no pool in place - just leaking

2010-11-24 19:25:35.381 octave[47278:617] *** __NSAutoreleaseNoPool(): Object 0x1072e4670 of class NSCFString autoreleased with no pool in place - just leaking

octave:3> 

However, I get the expected plot and everything seems to work. Maybe this is an issue with the 64-bit build of the devel FLTK version I happen to be using?

But...

... why should octave using fltk libraries draw in OSX Objective-C headers, fltk being cross-platform C++ library by design? Obviously FLTK needs to USE Objective-C to implement some of it's stuff, but that should not be exposed to the user of fltk, right? I found out that FLTK file FL/mac.H includes <Carbon/Carbon.h>, even though the definitions in that file only use a very, very small fraction of the stuff drawn in. In the same spirit that FL/mac.H already defined CGFloat (if needed), I tested if the few needed definitions could be extracted from the OSX includes, so that users of FLTK libraries would need no support for Objective-C 2.0.

Diffs from a recent tip FL/mac.H:

$ diff -c /opt/local/include/FL/mac.H-orig /opt/local/include/FL/mac.H

*** /opt/local/include/FL/mac.H-orig Mon Nov 22 22:22:31 2010

--- /opt/local/include/FL/mac.H Wed Nov 24 18:46:54 2010

***************

*** 50,56 ****

  #define MAC_OS_X_VERSION_10_6 1060

  #endif

  #ifndef MAC_OS_X_VERSION_MAX_ALLOWED

! #define MAC_OS_X_VERSION_MAX_ALLOWED MAC_OS_X_VERSION_10_3

  #endif

  

  #ifndef CGFLOAT_DEFINED //appears with 10.5 in CGBase.h

--- 50,56 ----

  #define MAC_OS_X_VERSION_10_6 1060

  #endif

  #ifndef MAC_OS_X_VERSION_MAX_ALLOWED

! #define MAC_OS_X_VERSION_MAX_ALLOWED MAC_OS_X_VERSION_10_6

  #endif

  

  #ifndef CGFLOAT_DEFINED //appears with 10.5 in CGBase.h

***************

*** 61,66 ****

--- 61,102 ----

  #endif

  #endif // CGFLOAT_DEFINED

  

+ #ifndef CGGEOMETRY_H_ // CoreGraphics/CGGeometry.h

+ struct CGPoint {

+   CGFloat x;

+   CGFloat y;

+ };

+ typedef struct CGPoint CGPoint;

+ struct CGSize {

+   CGFloat width;

+   CGFloat height;

+ };

+ typedef struct CGSize CGSize;

+ struct CGRect {

+   CGPoint origin;

+   CGSize size;

+ };

+ typedef struct CGRect CGRect;

+ #endif /* CGGEOMETRY_H_ */

+ 

+ #ifndef CGCONTEXT_H_ // CoreGraphics/CGContext.h

+ typedef struct CGContext *CGContextRef;

+ #endif /* CGCONTEXT_H_ */

+ 

+ #ifndef CGIMAGE_H_ // CoreGraphics/CGImage.h

+ typedef struct CGImage *CGImageRef;

+ #endif /* CGIMAGE_H_ */

+ 

+ #ifndef __QUICKDRAWTYPES__ // QD/QuickdrawTypes.h

+ typedef struct OpaqueWindowPtr* WindowPtr;

+ typedef WindowPtr WindowRef;

+ struct RGBColor {

+   unsigned short red;

+   unsigned short green;

+   unsigned short blue;

+ };

+ typedef struct RGBColor RGBColor;

+ #endif /* __QUICKDRAWTYPES__ */

  

  // Now make some fixes to the headers...

  #undef check // Dunno where this comes from...

I also needed to tweak configure.ac, since the test for FLTK OpenGL support did not work when FLTK was compiled with Apple's GCC, but Octave with GCC 4.5.1. The reason turned out to be the -arch argument returned by fltk-config, and included in both FLTK_CFLAGS and FLTK_LDFLAGS. This resulted in a failed test. I fixed this by mimicking the existing code for MINGW as follows (below). I also included -D__CARBON__ in the FLTK_CFLAGS, so that #include <Carbon/Carbon.h> would have no effect, and the additions to FL/mac.H (above) would kick in:

diff -r c5e6efdbcf67 configure.ac

--- a/configure.ac Mon Nov 22 03:29:44 2010 -0500

+++ b/configure.ac Wed Nov 24 19:14:11 2010 +0200

@@ -913,6 +913,12 @@

       *-*-mingw*)

         FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's/-mwindows//g'`"

       ;;

+      *-*-darwin*)

+## -arch XXXX option is not available in GCC 4.5...

+        FLTK_CFLAGS="`echo $FLTK_CFLAGS | sed -e 's/-arch [[^ ]]* /-D__CARBON__ /g'`"

+        FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's/-arch [[^ ]]* //g'`"

+      ;;

+

     esac

 

     AC_MSG_CHECKING([for OpenGL support in FLTK])

With these changes the above mentioned "Cell" symbol clash also disappears (as OSX headers are not included), and octave compiles and runs with FLTK backend, even when compiled with non-Apple GCC.

Now I have exactly the same behavior for FLTK as before using the Apple GCC 4.2, but now using the GCC 4.5.1 instead.

It appears that also other FLTK users might be interested in using non-Apple GCC versions, any ideas?

Regards,

  Jarno