Opened 15 years ago
Closed 15 years ago
#1658 closed bug (fixed)
MacOS X universal 4-way binaries
| Reported by: | vince | Owned by: | nobody |
|---|---|---|---|
| Priority: | major: does not work as expected | Milestone: | Version 1.0.3 |
| Component: | Build/Install | Version: | Trunk |
| Keywords: | python universal mac | Cc: | |
| Must Fix for Release: | No | Platform: | OS X |
| Platform Version: | Awaiting user input: | no |
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)
Attachments (2)
Change History (13)
by , 15 years ago
| Attachment: | pyconf.diff added |
|---|
comment:1 by , 15 years ago
| Summary: | Python binding unavailable/MacOS X univeral binaries (two bugs) → Python binding unavailable/MacOS X universal binaries (two bugs) |
|---|
comment:2 by , 15 years ago
| Milestone: | → Version 1.0.3 |
|---|
follow-up: 4 comment:3 by , 15 years ago
comment:4 by , 15 years ago
Replying to 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.
by , 15 years ago
| Attachment: | configure.py.in.diff added |
|---|
comment:6 by , 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.
comment:7 by , 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.
comment:8 by , 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.
comment:9 by , 15 years ago
| Keywords: | python universal mac added |
|---|---|
| Summary: | Python binding unavailable/MacOS X universal binaries (two bugs) → MacOS X universal 4-way binaries |
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.
The attached patch to python/configure.py.in fixes both bugs.