On 1/27/2009 7:24 PM, Lorenzo Mancini wrote: > Giovanni Bajo wrote: >> On ven, 2009-01-23 at 17:02 +0100, Lorenzo Mancini wrote: >>> Hello guys, >>> >>> from Leopard on, the special name @executable_path cannot be used >>> anymore in library paths for runtime substitution; two new special names >>> (@rpath and @library_path) were introduced for similar purposes. >> The link you posted: >> http://www.codeshorts.ca/2007/nov/01/leopard-linking-making-relocatable-libraries-movin >> >> says that the ld flag "-executable_path" is gone, not the >> @executable_path special symbol within binaries. > > True. I was misled to my original conclusion by erroneously asserting > that one-file PyInstaller deploys were actually working in Mac OS X < > 10.5; I have since realized that I was just scratching the surface of > the real problem. > > After some experiments, this is my understanding so far about the > current state of PyInstaller under Mac OS X. > > * PyInstaller is able to produce one-dir deploys by prepending library > dependency paths the special name @executable_path (see bindepend.py, > function fixOsxPaths), which will be expanded during runtime to the > current one-dir workpath. > > * the same trick doesn't work for one-file deploys, because the > executable first extracts the binary content in a temporary dir (see > source/linux/main.c), then fork()s itself and the child starts running; > later, the runtime will expand @executable_path during the execution of > the child, to the directory of the original executable, *not* the > temporary dir. As a consequence, PyInstaller at present is not able to > produce working one-file deploys under Mac OS X. > > * it's not possible to set an arbitrary path for runtime substitution > of @executable_path; _NSGetExecutablePath exists for getting that value > during runtime, but I didn't find a setter. > > > A possible solution which doesn't use the @executable_path special name > neither @rpath consists in leaving the dependency path names as they are > (no more install_name_tool magic), therefore leaving the paths absolute, > and specifying the temporary dir path in DYLD_LIBRARY_PATH. > > See section "The Library Search Process" in document [1], which details > the searching process for a dynamic library when the pathname contains a > directory name: it specifies that DYLD_LIBRARY_PATH is the first place > where the runtime will search for libraries. Therefore, changing the > DYLD_LIBRARY_PATH during loader's execution will make sure that the > temporary dir libraries will be picked up. > > The major drawback of this approach is that the libraries in both > one-dir and one-file deploys will contain absolute paths, so analyzing > them with otool would erroneously suggest that they rely on system > libraries. > > The proposed patch is attached. It basically removes the > install_name_tool magic and inserts the workpath at the beginning of > DYLD_LIBRARY_PATH if we are running under Mac OS X. It should work for > both one-file and one-dir deploys.
The patch looks great and it's fine by me. Your analysys is compelling, too! The only doubt is what version of OSX is required for DYLD_LIBRARY_PATH to work. Was it introduced in 10.0, or is it a later feature? Because obviously our generated file would work only starting from that version. If it's not 10.0, we might setup a backup plan (eg: leave the install_name_tool magic for making one-dir installs work, at least). -- Giovanni Bajo Develer S.r.l. http://www.develer.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "PyInstaller" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/PyInstaller?hl=en -~----------~----~----~----~------~----~------~--~---
