Bug report #1658

MacOS X universal 4-way binaries

Added by vince - over 11 years ago. Updated almost 11 years ago.

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 Magnifier (474 Bytes) vince -, 2009-04-27 06:27 AM

configure.py.in.diff Magnifier (1.69 KB) vince -, 2009-04-29 01:39 AM

History

#1 Updated by vince - over 11 years ago

The attached patch to python/configure.py.in fixes both bugs.

#2 Updated by vince - over 11 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 about 11 years ago

Hi,

has this patch been applied?

#4 Updated by William Kyngesburye about 11 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 about 11 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 almost 11 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 almost 11 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 almost 11 years ago

oh, , for reference.

#9 Updated by William Kyngesburye almost 11 years ago

  • Resolution set to fixed
  • Status changed from Open to Closed

And fixed in 1.0 at .

Also available in: Atom PDF