getting GDCM to work (on Mac)
mike
Below is the patch file (everything in between the starred lines) to
get the Python bindings for GDCM (http://sourceforge.net/apps/
mediawiki/gdcm/index.php) to work with PyInstaller. In this case, I
added '/usr/local/lib' to the fwpaths, which is used to determine
whether the results from otool should be included.
In this case, I believe that /usr/local/lib is a common install
location for 3rd party applications and libraries on the mac, so
should be included.
Cheers
Mike
********************************
Index: PyInstaller/bindepend.py
===================================================================
--- PyInstaller/bindepend.py (revision 1406)
+++ PyInstaller/bindepend.py (working copy)
@@ -462,7 +462,7 @@
This implementation is for otool platforms"""
# dyld searches these paths for framework libs
# we ignore DYLD_FALLBACK_LIBRARY_PATH for now (man dyld)
- fwpaths = ['/Library/Frameworks', '/Network/Library/Frameworks',
'/System/Library/Frameworks']
+ fwpaths = ['/Library/Frameworks', '/Network/Library/Frameworks',
'/System/Library/Frameworks', '/usr/local/lib']
for p in reversed(os.environ.get('DYLD_FRAMEWORK_PATH',
'').split(':')):
if p:
fwpaths.insert(0, p)
********************************
Hartmut Goebel
> In this case, I believe that /usr/local/lib is a common install
> location for 3rd party applications and libraries on the mac, so
> should be included.
IMHO these applications do not honor the OS X coding style (same for
pyside). /usr/lib and /usr/local/lib are typical Unix paths, while OS X
used pathes like /Library/Frameworks.
Nevertheless it looks as if we need to support these paths :-(
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de
mike
> > In this case, I believe that /usr/local/lib is a common install
> > location for 3rd party applications and libraries on the mac, so
> > should be included.
>
> IMHO these applications do not honor the OS X coding style (same for
> pyside). /usr/lib and /usr/local/lib are typical Unix paths, while OS X
> used pathes like /Library/Frameworks.
libraries, but as OS X is BSD based, its support of such paths is in
addition to its support of common Unix paths used by generic Unix
libraries.
> Nevertheless it looks as if we need to support these paths :-(
exclude the libraries that the current implementation is trying to
excluded, eg libstdc++.6.dylib and libSystem.B.dylib
Cheers
Mike
Hartmut Goebel
> If that's the decision, then there will also need to be a list to
> exclude the libraries that the current implementation is trying to
> excluded, eg libstdc++.6.dylib and libSystem.B.dylib
So we should try first to find another solution.
Did you try a hook which adds the pyside/gdmc files fro /usr/local/lib,
/usr/lib as `data` files to the pyinstaller archive? Something like:
datas = [
("/usr/lib/pyside.so", ""),
]
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de/blog
mike
OS X developer has them, which is why the assumption to exclude
everything in /usr/lib and /usr/local/lib has worked so far.
> Did you try a hook which adds the pyside/gdmc files fro /usr/local/lib,
> /usr/lib as `data` files to the pyinstaller archive? Something like:
there are some things to consider
* This is only required on OS X, ie both PySide and gdcm work on
Windows w/o hooks
* The libraries have names like /usr/lib/libpyside-
python2.6.1.0.2.dylib, usr/lib/libpyside-python2.6.1.0.dylib, /usr/lib/
libpyside-python2.6.dylib, of which 2 are simlinked to the 3rd. That
and because there may be version differences (eg 2.6 vs 2.7), we can't
hardcode it
* Even if we knew which version of the software, we don't know which
version of the dylib is actually needed, so otool is still the command
to call to determine which one to copy over.
* If we're going to use otool anyway, it seems like too much of an
overhead to do the same thing in the hook, except to exclude/include
different things than what's happening in bindepend.py
Cheers
Mike
Martin Zibricky
> * Even if we knew which version of the software, we don't know which
> version of the dylib is actually needed, so otool is still the command
> to call to determine which one to copy over.
> * If we're going to use otool anyway, it seems like too much of an
> overhead to do the same thing in the hook, except to exclude/include
> different things than what's happening in bindepend.py
What exclude/include list does py2app use?
mike
> What exclude/include list does py2app use?
the heavy lifting
http://svn.pythonmac.org/py2app/py2app/trunk/py2app/filters.py
macholib
http://packages.python.org/macholib/
Cheers
Mike
Martin Zibricky
> the heavy lifting
> http://svn.pythonmac.org/py2app/py2app/trunk/py2app/filters.py
>
> macholib
> http://packages.python.org/macholib/
How much work would it be to start using macholib for some mac specific
stuff?
mike
> stuff?
knowledge that person has about PyInstaller and macholib. If that
person were me, the answer would be "a lot of work and a long time",
because I know not much about either :)
Cheers
Mike
Martin Zibricky
> I guess it depends on who will be doing the work and how much
> knowledge that person has about PyInstaller and macholib. If that
> person were me, the answer would be "a lot of work and a long time",
> because I know not much about either :)
Could you please investigate what macholib can be used in pyinstaller
for?
We already know that it could replace calling the otool (similar to ldd
on linux). Could it be use for anything else?
mike
for the due diligence required for such an investigation. I also
think we are getting sidetracked. The problem today isn't with any of
the tools that PyInstaller is using.
Going back to the original issue for PySide, GDCM, etc, otool reports
the dependency libraries just fine. It's PyInstaller that's
improperly filtering out libraries in /usr/lib and /usr/local/lib.
That would still be a problem if PyInstaller switches to macholib.
So, my opinion of what really needs to be changed is how PyInstaller
filters the dependency libraries.
Cheers
Mike
Hartmut Goebel
> Going back to the original issue for PySide, GDCM, etc, otool reports
> the dependency libraries just fine. It's PyInstaller that's
> improperly filtering out libraries in /usr/lib and /usr/local/lib.
> So, my opinion of what really needs to be changed is how PyInstaller
> filters the dependency libraries.
AS you may know, bindepend already include an exclude/include mechanism
for filtering. So your proposed changes will come down to:
1) Add /usr/lib and /usr/local/lib the the lib-search-path (fwpath) with
ootool. Okay for me.
2) Do some "hacks" with pyside and shiboken. As far as I understood,
this includes all libs which's name contains pyside or shiboken. We
should use the already implemented include mechanism for that. Simply
add a regex to the (yet empty) "includes" dict.
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
michael j pan
AS you may know, bindepend already include an exclude/include mechanism
for filtering. So your proposed changes will come down to:1) Add /usr/lib and /usr/local/lib the the lib-search-path (fwpath) with
ootool. Okay for me.