On May 26, 2005, at 1:56 PM, has wrote: > Nicholas Riley wrote: > > >>> Obviously the extension needs to be built on Tiger to provide sdef >>> support, but what should I do to ensure that, say, applications >>> containing that binary extension will still work OK when run on >>> earlier OSes? >>> >> >> You can use weak linking if you don't need to support 10.1.x or >> earlier, >> > > Ah, thanks. nm says OSACopyScriptingDefinition is weak, so I've > added the appropriate 'OSACopyScriptingDefinition != NULL' check to > OSATerminology.c and recompiled it for Tiger's Apple-installed > Python. No problems using it there there, of course, but I do get > the following (unrelated) error when trying to import it into user- > installed Python 2.3.5 on 10.2.8 (I don't have a copy of Panther so > dunno if it works on that): > > ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: > dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/Python can't open library: /usr/lib/ > libmx.A.dylib (No such file or directory, errno = 2)
gcc 4.0 automatically adds a reference to /usr/lib/libmx.A.dylib for all C++ code (and to make it more annoying, in more than a few cases, it doesn't actually directly reference anything in it - you'd think the linker would skip adding the link record). Switching to gcc 3.3 will make this problem go away. Glenn Andreas [EMAIL PROTECTED] <http://www.gandreas.com/> wicked fun! Widgetarium | the quickest path to widgets _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
