[MacPorts] #46571: xulrunner @1.9.2.16 does not work on Tiger

MacPorts noreply at macports.org
Thu Jan 15 08:33:55 PST 2015


#46571: xulrunner @1.9.2.16 does not work on Tiger
-------------------------------+--------------------------------
 Reporter:  csanchezdll@…      |      Owner:  macports-tickets@…
     Type:  defect             |     Status:  new
 Priority:  Normal             |  Milestone:
Component:  ports              |    Version:  2.3.3
 Keywords:  haspatch, powerpc  |       Port:  xulrunner
-------------------------------+--------------------------------
 xulrunner seems to have been broken in Tiger for some time. According to
 #28272, Tiger is unsupported. Also, mozjs17 and policykit compilation
 problems prevented xulrunner to build. With those fixed (#46567 and
 #45832) xulrunner can be get to build and run correctly on Tiger PPC.

 1. python in Tiger is 2.3.5, whereas xulrunner requires 2.4. Attached
 patch uses python27.
 2. freetype2 changed header location (see #41593).
 3. xulrunner decides which gfx headers to export based on default toolkit,
 but this is not consistent in gfx source code. As a result, it will not
 compile with --enable-default-toolkit=cairo-gtk2 if cairo has quartz
 support (as MacPorts version does). A small patch in gfxASurface.cpp fixes
 this (maybe it it should be tried to use cairo-quartz toolkit?).
 4. NSPR link functions (PR_FindSymbolAndLibrary and friends) are unable to
 locate symbols from linked libraries on Darwin PPC. This makes xulrunner
 fail on detecting pango version and use an incorrect mechanism for setting
 fontmap property. This lead to runtime failed assertions:

   GLib-GObject:ERROR:gobject.c:4270:g_weak_ref_set: assertion failed:
 (weak_locations != NULL)

   As pango port is well above version 124.04, attached patch forces
 xulrunner to assumes a higher version instead of checking.
 5. Fixed in-tree libffi as per #21401

 I reckon some of those should be applied upstream, but I woulld not expect
 new releases of 1.9 series, and 2.0 break PPC support. So I think it is
 sensible to apply them at MacPorts level.

-- 
Ticket URL: <https://trac.macports.org/ticket/46571>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list