GNOME Bugzilla – Bug 555525
64 Bit Build on Mac OS X Leopard fails because of TWAIN interface
Last modified: 2016-04-17 23:07:36 UTC
Please describe the problem: The configure script detects Mac OSX Twain and Carbon as usable but this should not be the fact in case one is compiling gimp as a 64 bit application. ( Carbon doesn't support 64 bit ) Steps to reproduce: Compile GTK and gimp dependencies in 64 bit I. Set CFLAGS=CXXFLAGS=LDFLAGS="-arch x86_64" 2. run configure 3. run make Actual results: make fails because it tries to use carbon functions in TWAIN Expected results: configure detects to be on leopard 64 bit and disables the twain module or uses an apropriate code replacement Does this happen every time? yes Other information: Right now a workaround is to create a /plugins/twain/tw_mac.c file with dummy functions containing actually nothing ( this allowed me to build gimp on 64 bit leopard )
Good to know, we should add a configure check that disables all carbon code on 64 bit then.
Is this confirmed? It wouldn't be difficult to add the necessary checks, but I find it hard to believe that Carbon and 64bit doesn't work together.
At has been said on Apple WWDC 2007, and I cite http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6 "Fast-forward to WWDC 2007, this time in the 64-bit session, and the other shoe dropped. Though several non-GUI parts of the Carbon API that are shared with Cocoa will be supported in 64-bit mode in Leopard, the GUI portions of the Carbon API will not. Yep, it's (finally) the end of the line for Carbon GUI applications in Mac OS X. Oh, sure, they'll be around for years and years to come, but the lack of 64-bit support is a long-term death sentence."
It would help if you could paste the exact error message from the failed build. That should allow me to add the required test to configure.in.
I have done some cleanups to the configure script in trunk and in the gimp-2-6 branch in preparation of fixing this. The check for Carbon that we used to use to identify a Mac OS X system is now replaced. So the only place left that still checks for Carbon is the check for the TWAIN API. We need to extend this check to not only test for the availability of the Carbon headers, but to also test if a Carbon application can actually be linked.
haschka, please answer my question (comment #4) and provide the information we need to get this fixed for the next release.
Setting to NEEDINFO.
Sorry for the delay... Here's the info requested: Remarques: I used a custom build gcc-4.3.1 compilied in 64 bit that only gernerates 64 bit code. My GCC is portable375:gimp-2.6.0 haschka$ /opt/gcc4/bin/gcc -v Utilisation des specs internes. Target: x86_64-apple-darwin9 Configuré avec: ./configure --prefix=/opt/gcc4 --build=x86_64-apple-darwin9 --target=x86_64-apple-darwin9 --enable-languages=c,objc,c++,obj-c++,fortran --disable-multilibs --disable-bootstrap Modèle de thread: posix gcc version 4.3.1 (GCC) Configure command: ./configure --disable-mmx --prefix=/opt/gimp --host=x86_64-apple-darwin9.5.0 --target=x86_64-apple-darwin9.5.0 --disable-python Messages that twain was found: checking for perl5... no checking for perl... /usr/bin/perl checking checking for Mac OS X TWAIN support... yes checking checking for Mac OS X Carbon support... yes checking for xmllint... /usr/bin/xmllint checking for xsltproc... /usr/bin/xsltproc Compilation in twain with errors: Making all in twain /opt/gcc4/bin/gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -D_REENTRANT -I/opt/gimp/include/glib-2.0 -I/opt/gimp/lib/glib-2.0/include -I/opt/gimp/include -I/opt/gimp/include -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -O2 -march=core2 -ftree-loop-linear -ftree-vectorize -ftree-vectorizer-verbose=1 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -MT tw_func.o -MD -MP -MF .deps/tw_func.Tpo -c -o tw_func.o tw_func.c /opt/gcc4/bin/gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -D_REENTRANT -I/opt/gimp/include/glib-2.0 -I/opt/gimp/lib/glib-2.0/include -I/opt/gimp/include -I/opt/gimp/include -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -O2 -march=core2 -ftree-loop-linear -ftree-vectorize -ftree-vectorizer-verbose=1 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -MT tw_util.o -MD -MP -MF .deps/tw_util.Tpo -c -o tw_util.o tw_util.c /opt/gcc4/bin/gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -D_REENTRANT -I/opt/gimp/include/glib-2.0 -I/opt/gimp/lib/glib-2.0/include -I/opt/gimp/include -I/opt/gimp/include -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -O2 -march=core2 -ftree-loop-linear -ftree-vectorize -ftree-vectorizer-verbose=1 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -MT twain.o -MD -MP -MF .deps/twain.Tpo -c -o twain.o twain.c tw_func.c:106: attention : no previous prototype for ‘FloatToFIX32’ mv -f .deps/tw_util.Tpo .deps/tw_util.Po /opt/gcc4/bin/gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -D_REENTRANT -I/opt/gimp/include/glib-2.0 -I/opt/gimp/lib/glib-2.0/include -I/opt/gimp/include -I/opt/gimp/include -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -O2 -march=core2 -ftree-loop-linear -ftree-vectorize -ftree-vectorizer-verbose=1 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -MT tw_mac.o -MD -MP -MF .deps/tw_mac.Tpo -c -o tw_mac.o tw_mac.c tw_func.c:135: note: twain.c:209: attention : no previous prototype for ‘scanImage’ twain.c: In function ‘getAppIdentity’: twain.c:236: attention : pointer targets in passing argument 1 of ‘strcpy’ differ in signedness twain.c:240: attention : pointer targets in passing argument 1 of ‘strcpy’ differ in signedness twain.c:241: attention : pointer targets in passing argument 1 of ‘strcpy’ differ in signedness tw_func.c:154: note: twain.c:242: attention : pointer targets in passing argument 1 of ‘strcpy’ differ in signedness twain.c: Hors de toute fonction : twain.c:256: attention : no previous prototype for ‘initializeTwain’ tw_func.c:781: note: twain.c:871: note: mv -f .deps/tw_func.Tpo .deps/tw_func.Po mv -f .deps/twain.Tpo .deps/twain.Po tw_mac.c: In function ‘twainSetupCallback’: tw_mac.c:106: attention : transtypage d'un pointeur vers un entier de taille différente tw_mac.c:106: attention : assignment makes pointer from integer without a cast tw_mac.c: Hors de toute fonction : tw_mac.c:124: attention : no previous prototype for ‘unloadTwainLibrary’ tw_mac.c:150: attention : no previous prototype for ‘twainQuitApplication’ tw_mac.c: In function ‘twainQuitApplication’: tw_mac.c:151: attention : old-style function definition tw_mac.c:152: attention : implicit declaration of function ‘QuitApplicationEventLoop’ tw_mac.c: In function ‘twainSetupMacUI’: tw_mac.c:170: attention : old-style function definition tw_mac.c:180: attention : ISO C90 forbids mixed declarations and code tw_mac.c:187: attention : pointer targets in passing argument 2 of ‘CFURLCreateFromFileSystemRepresentation’ differ in signedness tw_mac.c:190: attention : ISO C90 forbids mixed declarations and code tw_mac.c:196: attention : implicit declaration of function ‘BeginQDContextForApplicationDockTile’ tw_mac.c:196: attention : initialization makes pointer from integer without a cast tw_mac.c:197: attention : implicit declaration of function ‘EndQDContextForApplicationDockTile’ tw_mac.c:199: attention : implicit declaration of function ‘SetApplicationDockTileImage’ tw_mac.c: Hors de toute fonction : tw_mac.c:203: attention : no previous prototype for ‘twainMain’ tw_mac.c: In function ‘twainMain’: tw_mac.c:204: attention : old-style function definition tw_mac.c:225: attention : implicit declaration of function ‘RunApplicationEventLoop’ mv -f .deps/tw_mac.Tpo .deps/tw_mac.Po /bin/sh ../../libtool --tag=CC --mode=link /opt/gcc4/bin/gcc -O2 -march=core2 -ftree-loop-linear -ftree-vectorize -ftree-vectorizer-verbose=1 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -framework Carbon -framework TWAIN -L/opt/gimp/lib -o twain tw_func.o tw_util.o twain.o tw_mac.o ../../libgimp/libgimp-2.0.la ../../libgimpcolor/libgimpcolor-2.0.la ../../libgimpbase/libgimpbase-2.0.la -L/opt/gimp/lib -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lintl mkdir .libs /opt/gcc4/bin/gcc -O2 -march=core2 -ftree-loop-linear -ftree-vectorize -ftree-vectorizer-verbose=1 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -framework Carbon -framework TWAIN -o .libs/twain tw_func.o tw_util.o twain.o tw_mac.o -L/opt/gimp/lib ../../libgimp/.libs/libgimp-2.0.dylib /Users/haschka/Desktop/gimp-2.6.0/libgimpconfig/.libs/libgimpconfig-2.0.dylib /Users/haschka/Desktop/gimp-2.6.0/libgimpmath/.libs/libgimpmath-2.0.dylib /Users/haschka/Desktop/gimp-2.6.0/libgimpcolor/.libs/libgimpcolor-2.0.dylib /Users/haschka/Desktop/gimp-2.6.0/libgimpbase/.libs/libgimpbase-2.0.dylib ../../libgimpcolor/.libs/libgimpcolor-2.0.dylib -lm ../../libgimpbase/.libs/libgimpbase-2.0.dylib /opt/gimp/lib/libgobject-2.0.dylib /opt/gimp/lib/libgthread-2.0.dylib /opt/gimp/lib/libglib-2.0.dylib /opt/gimp/lib/libiconv.dylib /opt/gimp/lib/libintl.dylib /usr/lib/libiconv.dylib -lc Undefined symbols: "_SetApplicationDockTileImage", referenced from: _twainMain in tw_mac.o "_QuitApplicationEventLoop", referenced from: _doGetImage in tw_mac.o _twainQuitApplication in tw_mac.o "_EndQDContextForApplicationDockTile", referenced from: _twainMain in tw_mac.o "_BeginQDContextForApplicationDockTile", referenced from: _twainMain in tw_mac.o ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [twain] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I hope I provided all you need.
I can add some confirmation that this is a problem... macports ticket 21011: http://trac.macports.org/ticket/21011#comment:6 Unfortunately the first part of that ticket is about something else, but it includes discussion of problems with carbon in tw_mac.c
If the patch that is mentioned there really fixes this problem and does not just disable the build of the twain plug-in, then it would be nice if you contributed it here. Preferably in git format.
I guess I'll look into doing that (sorry, haven't used git before). But IMHO the "patch" is just a removal of the lines of code that cause problems. I'm not sure if that is really the best way to go about solving this problem. But I guess those lines were described as "voodoo magic" so perhaps they weren't the best to begin with. I asked on the macports thread if removing those lines just causes the problem they were initially trying to solve to come back and no one had a definitive answer.
Created attachment 145898 [details] [review] Patch to remove carbon functions in tw_mac.c Ok, here's a git patch that removes the problematic functions from tw_mac.c. This allows me to build gimp in my macports environment, but I haven't been able to test the build outside of that. I can open the file-create-scanner/camera dialog but I don't actually have a device to try this with. Hopefully I did everything correctly with the patch generating procedure, but presumably someone should check it over. Not sure if this solves all the problems of this bug or just some...
Review of attachment 145898 [details] [review]: If you remove SetApplicationDockTileImage (icon), then, as far as I can see, the whole code to create an icon can be removed as the icon is never used. But then, as the comments suggest, it may be nicer to have an icon. This patch needs a review from somone who knows his/her way around the Mac OS X APIs.
http://developer.apple.com/mac/library/DOCUMENTATION/Carbon/Conceptual/customizing_docktile/docktasks_cocoa/docktasks_cocoa.html#//apple_ref/doc/uid/TP30000986-CH3-SW1 is the new cocoa way to set a Dock icon.
Review of attachment 145898 [details] [review]: Setting to needs-work as per comment #13.
Created attachment 163883 [details] [review] New patch to remove all dock image code in tw_mac.c Here is another patch that I think removes all the code to do with setting the dock image, which should be a bit cleaner. The link to the cocoa way of setting the dock image doesn't make it look so hard, but maybe just dropping cocoa code in here isn't so straightforward. This is beyond my knowledge.
I doubt just removing the dock icon is the right thing to do, must be better to port to the new API. Disabling the entire plug-in doesn't seem like a good solution either.
Review of attachment 163883 [details] [review]: Rejecting, we should port to new API instead of removing the calls completely.
Regarding Comment #17, seems poor to reject the whole approaches contained in the only solutions that anyone has managed to cook up over two years, leaving gimp unbuildable for that long. Better to have a relatively small feature disabled (this is all really just about a custom UI icon rather than a generic one????) until someone can actually reimplement it. Or if nobody cares to reimplement it, maybe nobody thinks this UI tidbit really is important enough to bother with? How about a ./configure test for the necessary carbon function, and then protect the codeblock with #ifdef HAVE_SETAPPLICATIONDOCTILEIMAGE so those that can use it still get it (vs Comment #18's objection to removing it completely) but those who can't use that call don't have to disable the plugin (vs Comment #17's objection) or give up on this program entirely.
A configure check and #ifdef sounds like a good short-term solution
You need to do more than fix the Dock icon to build 64-bit on mac. You should rip out your (ancient) ige-mac-integration code and use the gtk-osxapplication version at git://github.com/jralls/ige-mac-integration. That will provide you with Cocoa-based menu integration, Dock integration, and rudimentary support for quit and file open notifications.
For the time being, I disabled the plugin so things build again: commit b40e1c44b6f0eeeab023eb12ea3d05e5bc0c4e88 Author: Michael Natterer <mitch@gimp.org> Date: Thu Sep 1 21:17:26 2011 +0200 configure: let the test for TWAIN fail on 64 bit OSX Somebody needs to port the stuff to not using the parts of Carbon that are not there on 64 bit, or preferrably not use Carbon at all. configure.ac | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
I ported the TWAIN support to Mac OS X long long ago when Carbon still ruled the earth. :) On quick inspection of my current OS X 10.9 system, the TWAIN framework still exists and has both i386 and x86_64 versions in the library, so updating the plugin should be possible. There may be better, more modern Mac OS X-ish ways to do scanning though. (I think I have a scanner *somewhere* to test.)
You are free to do whatever you like to the TWAIN plug-in, there is no change that wouldn't improve it :)
I got the TWAIN plugin to build on 64-bit on my machine and it appears to properly start up. I will need to test with a scanner (should have access to one at university) before I will commit. (In reply to Brion Vibber from comment #23) > There may be better, more modern Mac OS X-ish ways to do scanning though. (I > think I have a scanner *somewhere* to test.) Apparently there are image capture capabilities in ImageKit / ImageCaptureCore since Snow Leopard, so we probably want to start using that at some point.
I've spoken to Mitch and we seem to agree that it's better to remove the TWAIN code for Mac and simply write a new plugin that uses native Mac APIs. As I mentioned we can do this using the ImageKit / ImageCaptureCore APIs. Essentially, there are two possibilities: (1) We use ImageKit, which has Cocoa UI pre-defined. (2) We use ImageCaptureCore, which allows us to write our own UI and even allow us to do this in GTK+. I would say that a benefit of (2) is that we are fully in control of the UI and that we can write the UI in GTK+. This way, it will "feel" better integrated with the rest of GIMP. Mitch, what do you think?
Kris, I completely agree.
From what I remember of using the old TWAIN interface in PowerPC days, I would agree that having a fully integrated UI in GTK+ should be more user-friendly (and ought to still work with both X11 and Quartz builds).
Kristian, you have assigned this bug to yourself. Did you get around to solve this?
(In reply to Michael Schumacher from comment #29) > Kristian, you have assigned this bug to yourself. Did you get around to > solve this? In the process of solving this bug, we decided it is a better idea to drop the current TWAIN code for Mac OS X and write a new plugin using the ImageCaptureCore API. I have been working on this new plugin on and off during the last months and it is getting into shape. Once it's ready for testing and review I will probably publish a branch with the code somewhere.
Bah, just dump it in git master in plug-ins/common, or plug-ins/whatever (if it has more than one file). A plug-in is trivial to disable and the sooner it's in git the sooner it will get some testing. Setting 2.10 as milestone because nobody is going to fix this stuff in 2.8.
"Fixed" in master, actually obsoleted: commit 8bb48ac5de915cf5b6f2136541c403101ddee52a Author: Michael Natterer <mitch@gimp.org> Date: Mon Apr 18 00:05:41 2016 +0100 Bug 555525 - 64 Bit Build on Mac OS X Leopard fails... ...because of TWAIN interface Remove all Mac TWAIN stuff, we will get proper OS X scanner support pretty soon. configure.ac | 23 ------- plug-ins/Makefile.am | 4 -- plug-ins/twain/Makefile.am | 12 +--- plug-ins/twain/tw_mac.c | 228 ------------------------------------------------------------- plug-ins/twain/tw_platform.h | 24 ------- 5 files changed, 1 insertion(+), 290 deletions(-)