[fxruby-users] Installing RubyFX on MacOS X 10.4.3

Jeroen van der Zijp jeroen at fox-toolkit.org
Sat Nov 19 14:52:52 EST 2005


On Saturday 19 November 2005 10:50, Lyle Johnson wrote:
> One of my users just discovered a problem with FXRuby that was 
> surprising to me and so I thought I'd mention it here.
> 
> If your FOX application's source code has references to the 
> fxcheckJPG() function, it will always compile correctly against the FOX 
> header files; but if you link your application against a FOX library 
> that wasn't built with JPEG support, you're going to find that 
> fxcheckJPG() is an unresolved symbol. That is to say, there's no 
> "stubbed in" version of fxcheckJPG() for a FOX library that's built 
> without JPEG support.
> 
> This is different from the pattern previously established in FOX for, 
> say, the FXJPGIcon class. If your source code has references to the 
> FXJPGIcon class, it will compile and link correctly against a FOX 
> library built without JPEG support. The resulting application will even 
> construct an FXJPGIcon object, and just display a placeholder icon in 
> place of the actual image.
> 
> So... I'd like to request that future FOX libraries provide stubbed-in, 
> "do nothing" version of the fxcheckJPG(), fxcheckGIF() and fxcheckPNG() 
> functions. I understand that they won't do the right thing, but it 
> seems like that's OK given the precedents I've mentioned.

Indeed, you are right.  The idea with stubbing out if no image support
is available is to allow programs to continue to compile [and function!].

I've looked things over and we have this problem in three different
places:- for JPEG, PNG and TIFF support.  The other image types are
OK as they are always compiled in [no external libraries are required].

I've fixed these and one other minor problem and dropped the fixed sources
at:

	ftp://fox-toolkit.org/pub/fox-1.4.25.tar.gz


Hopefully, that takes care of the problem!


	Regards,

			Jeroen



More information about the fxruby-users mailing list