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