🌐 Mailman 3 November 2005 - Pythonmac-SIG - python.org

Loading modules on MacOS
by jurem＠flextronics.si Nov. 2, 2005

Nov. 2, 2005

Hi all, I'm porting some software from Linux/Python to MacOS/Python. Core modules are written in C++ and are loaded in Python as modules. On Linux those core modules are linked as shared libraries (.so). It looks something like: core_module1.so <-- 'standalone' core module, does not link any other lib high_module2.so <-- higher level module which is using core_module1.so Problem on MacOS is, that Python modules are bundles not shared libraries, so I've made it like: core_module1.dylib <-- dynamic library (using -dynamiclib gcc option) core_module1.so <-- bundle, created from .dylib high_module2.so <-- bundle, which also links .dylib I'm symlinking core_module1.dylib to libcore_module1.dylib. Link options for both bundles are: -W1,-F. -bundle -framework Python -lstdc++ -L. -lcore_module1 If I create only core_module1.so (as bundle, without dynamic library) it loads properly, but if I do it this way Python 'hangs' when I try to load module. I'm using dlcompat library (Mach-O wrapper) for loading dynamic library (dlopen, dlysm, ...) and it should work fine. Python version is 2.3, GCC is 3.3 (if I try to compile it on Linux with same versions works without problems) Does anyone have any idea, what could be wrong? I think this would be the cleanest way to port this software, am I wrong? Thanks for any ideas/suggestions, regards, Jure

4 4

py2app generated app, not acting as a stand-alone app
by Richard Rodriguez Nov. 2, 2005

Nov. 2, 2005

I created a python cgi-server, and generate web pages with python. After getting past the main mac issues, I'm down to the last 1, a stand-alone app. My "py2app" generated app works, except that it is looking at the installed python for something. I didn't notice until I tried on a mac without python, and after renaming the folder where I have python installed. here's my error: localhost - - [01/Nov/2005 13:00:06] dyld: /Users/mayu/Desktop/dist_win_10_25_05/webdemo.app/Contents/Frameworks/Python.framework/Versions/2.4/bin/python can't open library: /Library/Frameworks/Python.framework/Versions/2.4/Python (No such file or directory, errno = 2) The library it's trying to open is the version installed locally, when it should be looking at the library inside "webdemo.app". Most likly a path problem. My guess is that I can fix this by modifying my py2app setup script, but don't understand how. Any help would be great. Below is the rest of my setup and errors: ------ file info ------ "webdemo.app" - the cgi web-server cgi-bin/test_real3.py - generates html page /Library/Frameworks/Python.framework - this is the locally installed python /Users/mayu/Desktop/dist_win_10_25_05/ - this is where the py2app generated mac app is located ------- my simple setup script for py2app ---------- # setup.py from distutils.core import setup import py2app setup(app=["webdemo.py"]) ------- full list of console messages ---------- serving at port 1770 localhost - - [01/Nov/2005 13:00:05] "GET /cgi-bin/test_real3.py HTTP/1.1" 200 - localhost - - [01/Nov/2005 13:00:05] Trying to execute scriptfile /Users/mayu/Desktop/dist_win_10_25_05/webdemo.app/Contents/Resources/cgi-bin/test_real3.py localhost - - [01/Nov/2005 13:00:05] command: /Users/mayu/Desktop/dist_win_10_25_05/webdemo.app/Contents/Frameworks/Python.framework/Versions/2.4/bin/python -u /Users/mayu/Desktop/dist_win_10_25_05/webdemo.app/Contents/Resources/cgi-bin/test_real3.py "" localhost - - [01/Nov/2005 13:00:06] dyld: /Users/mayu/Desktop/dist_win_10_25_05/webdemo.app/Contents/Frameworks/Python.framework/Versions/2.4/bin/python can't open library: /Library/Frameworks/Python.framework/Versions/2.4/Python (No such file or directory, errno = 2) localhost - - [01/Nov/2005 13:00:06] CGI script exited OK

1 0

In Mac/Modules/file/_Filemodule.c dataLogicalSize, etc., should be UInt64 ("L")
by Laura McColm Nov. 1, 2005

Nov. 1, 2005

Greetings All! I am moving a document management app from C++/OS9 to Python/OSX Carbon and I am delighted with the functionality I'm finding in the MacOS specific extension modules. Just what I needed! But I was dismayed to be unable to get anything but the value 0L for the file sizes (dataLogicalSize, dataPhysicalSize, rsrcLogicalSize, rsrcPhysicalSize) in the catinfo structure returned by FSRef.FSGetCatalogInfo(). Python 2.3 and 2.4.2 (and 2.5!) on MacOS 10.3.9 returns 0L for the various file size values and correct values for other elements in the structure such as parentDirID: >>> fsRef = FSRef('LICENSE') >>> catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L) >>> catinfo.dataPhysicalSize 0 >>> catinfo.parentDirID 2026177 I'm new to the mechanisms inside the extensions themselves, but it looks to me that the routines building the return values (such as FSCatalogInfo_get_dataLogicalSize() in source file Mac/Modules/file/_Filemodule.c) should specify UInt64 instead of UInt32. static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoObject *self, void *closure) { return Py_BuildValue("l", self->ob_itself.dataLogicalSize); } Should change the "l" to "L" in each of the four routines: static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoObject *self, void *closure) { return Py_BuildValue("L", self->ob_itself.dataLogicalSize); } Works fine now: manny:~/dev/python/dist/src donb$ ./python.exe Python 2.5a0 (#1, Oct 31 2005, 01:18:46) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from Carbon.File import FSRef >>> fsRef = FSRef('LICENSE') >>> catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L) >>> catinfo.dataLogicalSize 13423L >>> ^D But my questions are: Has anyone else seen this? The os.stat() function returns a "unix-like" file size, i.e. data fork only, and I needed the "Mac-like" size (catinfo.dataLogicalSize+catinfo.rsrcLogicalSize) Does this seem like the right fix? Am I catching all the implications? There is another routine in _Filemodule.c: static int FSCatalogInfo_tp_init(PyObject *_self, PyObject *_args, PyObject *_kwds) { static char *kw[] = { [...] "dataLogicalSize", "dataPhysicalSize", "rsrcLogicalSize", "rsrcPhysicalSize", [...] , 0}; if (!PyArg_ParseTupleAndKeywords(_args, _kwds, "|HhllO&O&O&O&O&llllllb", kw, &((FSCatalogInfoObject *)_self)->ob_itself.nodeFlags, [...] This also seems to hold information about parameter size. Should these four "l"'s be changed as well? (My intuition/luck is running out here, guess I'll have to read up on what all of these mechanisms are actually doing :-) If this is a good patch, what's the best place to submit this? Sourceforge? This mailing list? Since I'm porting a MacOS9 application from C++ to Python I'm prepared to spend some time with Python and the extension mechanisms in the near future! Thanks for any help Don

2 1