Path: utzoo!attcan!uunet!midway!ux1.cso.uiuc.edu!uwm.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!decwrl!argosy!freeman From: freeman@argosy.UUCP (Jay R. Freeman) Newsgroups: comp.sys.mac.programmer Subject: 68881 / no-68881 MPW C library linker problem Message-ID: <624@argosy.UUCP> Date: 26 Jul 90 23:31:12 GMT Sender: news@argosy.UUCP Reply-To: freeman@cleo.UUCP (Jay R. Freeman) Distribution: na Organization: MasPar Computer Corporation, Sunnyvale, CA Lines: 43 I support a shareware application with two versions. One -- the "plain" version --runs on a Mac-Plus-or-better; the other -- the "fancy" version -- needs a 68020-or-better and a 68881-or-better. Both are written in MPW C, presently in version 3.1 thereof. I want the "fancy" version to shut itself down gracefully when some poor user ignores the "READ ME" file and tries to run it on a Mac with no 68020/68881. I know to set the MPW C compiler flags to generate plain vanilla 68000 code when compiling the files related to startup, but there is a problem with MPW C library routines: What I want to do is use library routines from the "plain vanilla" C libraries for exiting gracefully, but use library routines from the libraries compiled to use 68881 hardware during the rest of the program. (After all, the purpose of having a "fancy" version of the application is to use all that good stuff.) I can't figure out a way to do this with the linker. Am I missing something obvious? Something subtle? Let me explain in more detail. The Right Thing To Do would be to have the "fancy" routine put up a dialog box explaining why it has to exit, politely asking the user to use the "plain" version on that Mac. So I thought "gee, surely the glue for dialog-box routines won't use 68881 calls", but when I wrote code to put one up and tried to run it on a Mac Plus, it crashed with an "unimplemented instruction" error. The same code ran fine on my Mac II. After a little experimenting, I found that (evidently) the glue for "SysBeep" does not use any non-68000 instructions, so what my "fancy" program does now is to beep three times and exit, with no message. The user has to read the (*gasp*) documentation to find out what's going on. This "solution" is an unaesthetic kludge. Clarus would surely disapprove. I could always write my own glue in assembler, and perhaps I will get around to doing that sooner or later, but I thought the problem might be sufficiently generic that someone on the net would have a way to solve it from MPW C or from the MPW linker. (For the record, I would also be curious as to whether Think C provides a way around this kind of problem.) -- Jay Freeman, Crufteur Magnifique