fltk problems

[Stefan Bruda]

Hi,

At 14:22 -0400 on 2007-4-20 Yves de Champlain wrote:
 >
 > > Still on bugs, am I the only one for whom the JPEG handling is broken
 > > in FLTK?  I am using only one FLTK application (flPhoto), but I had to
 > > replace or eliminate all the code for (a) JPEG generation, and (b)
 > > EXIF data readout.  Otherwise I would get a bus error every time such
 > > a code was being executed.
 > 
 > I can't even get it to compile :
 > 
 > Compiling export.cxx...
 > g++ -I/opt/local/include -O2  -fno-rtti  -Wall -Wno-return-type -O - 
 > fno-exceptions -DHAVE_CONFIG_H -I. -I. -c export.cxx
 > /System/Library/Frameworks/CoreServices.framework/Frameworks/ 
 > OSServices.framework/Headers/OpenTransportProviders.h:108: error:  
 > expected identifier before numeric constant
 > /System/Library/Frameworks/CoreServices.framework/Frameworks/ 
 > OSServices.framework/Headers/OpenTransportProviders.h:108: error:  
 > expected `}' before numeric constant
 > /System/Library/Frameworks/CoreServices.framework/Frameworks/ 
 > OSServices.framework/Headers/OpenTransportProviders.h:108: error:  
 > expected unqualified-id before numeric constant
 > /System/Library/Frameworks/CoreServices.framework/Frameworks/ 
 > OSServices.framework/Headers/OpenTransportProviders.h:575: error:  
 > expected declaration before ‘}’ token
 > make: *** [export.o] Error 1

Sorry, I forgot to mention two things:

First, I am running flPhoto 1.2, I have some in-house patches to this
version which are not yet applicable to 1.3.

Secondly, I needed to patch the application before compiling it.  I
actually have a unified patch (that fixed Mac OS compilation issues
and also tweaks the functionality of the application).  Instead of
giving you the whole thing I will try to select only those diffs that
re necessary for compilation:

--- flphoto-1.2/Makefile.in  2003-09-13 19:00:35.000000000 -0400
+++ flphoto-1.2-sb/Makefile.in      2007-03-16 15:19:12.000000000 -0400
@@ -22,7 +22,7 @@
 
 CC		=	@CC@
 CP		=	@CP@
-CXX		=	@CXX@
+CXX		=	g++
 FLTKCONFIG	=	@FLTKCONFIG@
 MKDIR		=	@MKDIR@ -p
 MSGFMT		=	@MSGFMT@

--- flphoto-1.2/configure	2004-01-04 12:45:55.000000000 -0500
+++ flphoto-1.2-sb/configure	2007-03-16 15:54:23.000000000 -0400
@@ -4420,7 +4420,7 @@
  	SUPC="`$CXX -print-file-name=libsupc++.a 2>/dev/null`"
  	if test -n "$SUPC" -a "$SUPC" != "libsupc++.a"; then
  		# This is gcc 3.x, and it knows of libsupc++, so we need it
- 		LIBS="$LIBS -lsupc++"
+ 		LIBS="$LIBS"
 		echo "$as_me:$LINENO: result: yes" >&5
 echo "${ECHO_T}yes" >&6
 	else
--- flphoto-1.2/configure.in	2003-12-20 11:08:20.000000000 -0500
+++ flphoto-1.2-sb/configure.in	2007-03-16 15:54:37.000000000 -0400
@@ -178,7 +178,7 @@
  	SUPC="`$CXX -print-file-name=libsupc++.a 2>/dev/null`"
  	if test -n "$SUPC" -a "$SUPC" != "libsupc++.a"; then
  		# This is gcc 3.x, and it knows of libsupc++, so we need it
- 		LIBS="$LIBS -lsupc++"
+ 		LIBS="$LIBS"
 		AC_MSG_RESULT(yes)
 	else
 		AC_MSG_RESULT(no)


These are of course terrible hacks (but hey, they work!).  There are
essentially two build issues: (a) CXX is incorrectly set, and (b)
libsupc++ is not only unneeded but it is harmful (-lsupc++ will result
in the linker complaining about symbols being multiply defined).

As I see you already have the g++ change, I have no idea but I hope
1.2 builds now.  Next, when running the application I note two issues:

In export.cxx, export_jpeg() will crash at the first opportunity.
This function is supposed t generate a JPEG image out of a previously
filled Fl_Shared_Image structure.  I replaced this function to a call
to convert to go around the problem.

Secondly, Fl_EXIF_Data.cxx the following piece of code causes a bus
error.

    for (marker = cinfo.marker_list; marker; marker = marker->next)
    {
      switch (marker->marker)
      {
        case JPEG_COM :
            parse_comment(marker->data, marker->data_length);
            break;
        case JPEG_APP0 + 1 :
            if (memcmp(marker->data, "Exif", 4) == 0)
              parse_exif(marker->data, marker->data_length);
            break;
      }
    }

The code does not say much in isolation (I tried to follow it but I
failed due to lack of time).  The essence however is that cinfo (of
type struct jpeg_decompress_struct) does not look as the program
expects it to look (I believe that mrker_list turns out to be 0 but I
am not very sure).  The result of this is that the first time flPhoto
attempts to read EXIF data from a JPEG image that has such data
available the program crashes.

I did not replace this with anything, I just commented the EXIF code
out (I keep EXIF data in a separate file anyway and I usualy handle
PNGs instead of JPEGs).

I am not sure whether this has anything to do with FLTK, but I believe
it does, as I have been using the program for a very long time under
Linux.

Thanks for takiing the time to look into it.

Stefan

P.S.  Any idea by any chance on how to begin in the quest of
convincing FLTK to use X instead of Aqua?

-- 
If it was so, it might be; and if it were so, it would be; but as
it isn't, it ain't.  That's logic.
    --Lewis Carroll, Through the Looking-Glass