Bug report #1658
MacOS X universal 4-way binaries
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  nobody - | ||
| Category: | Build/Install | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | OS X | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 11718 |
Description
For an unknown reason, the python/configure.py.in line 22 has a hardcoded universal architecture (ppc, i386), so it cannot build four ways universal binaries (Leopard types).
For the macports port, I've totally disabled the test (see the joined patchfile). It works but for this:
the core.so and gui.so library which is dependant to libcore and libgui retains the build location of these files instead of their final installed location, so it is not possible to launch core.so once the build directory has been erased:
otool -L Contents/MacOS/share/qgis/python/qgis/core.so
Contents/MacOS/share/qgis/python/qgis/core.so:
/usr/pkg/var/macports/build/_Users_vincent_Developpement_ports_gis_qgis/work/qgis-1.1.0/build/src/core/libqgis_core.1.1.0.dylib (compatibility version 1.1.0, current version 1.1.0)
[...]
otool -L Contents/MacOS/share/qgis/python/qgis/gui.so
Contents/MacOS/share/qgis/python/qgis/gui.so:
/usr/pkg/var/macports/build/_Users_vincent_Developpement_ports_gis_qgis/work/qgis-1.1.0/build/src/core/libqgis_core.1.1.0.dylib (compatibility version 1.1.0, current version 1.1.0)
pyconf.diff 
(474 Bytes)
configure.py.in.diff
(1.69 KB)
History
#1
Updated by vince - over 15 years ago
The attached patch to python/configure.py.in fixes both bugs.
#2
Updated by vince - over 15 years ago
Replying to [comment:3 vince]:
The attached patch to python/configure.py.in fixes both bugs.
The patch is Apple specific. But it is not very hard to generalize: it is enough to instanciate another variable in configure.py.in reflecting the OS type and then enclose the modification in ifs-elses. This way you could achieve best of both worlds.
#3
Updated by Giovanni Manghi over 15 years ago
Hi,
has this patch been applied?
#4
Updated by William Kyngesburye over 15 years ago
the core.so and gui.so library which is dependant to libcore and libgui retains the build location of these files instead of their final installed location, so it is not possible to launch core.so once the build directory has been erased:
Ah, this is the problem in bug #768. The patch may fix it for OSX, but it's not conditionalizing on OSX, and the -dylib_file flag is only valid on OSX.
#5
Updated by John Tull over 15 years ago
Who can work in this patch? It would be nice to not have to run the post-build fixes when building with cmake on OS X. This is a frequent problem for those that build on OS X as they have no idea why the python plugins do not work. You can see my comment in #768 as an example of what you need to do after an install with the cmake build method.
#6
Updated by William Kyngesburye about 15 years ago
Just starting to take a second look at this. There isn't much we can do, really. The architectures is meaningless here, because sipconfig only takes the 'universal' SDK option, which triggers it to add the arch flags hardwired into SIP (universal 32bit only). So, if you want a 64bit Qgis python module, you need to hack and compile SIP 64bits.
#7
Updated by William Kyngesburye about 15 years ago
OK, I partially applied the patch - I made the universal apply if 2 or more arches are specified. The rest is up to SIP.
The other bug is a duplicate of #768, and install_name_tool should be applied at install, like the rest of Qgis, not in the Python compilation.
#8
Updated by William Kyngesburye about 15 years ago
oh, , for reference.
#9
Updated by William Kyngesburye about 15 years ago
- Resolution set to fixed
- Status changed from Open to Closed
And fixed in 1.0 at .