[120169] trunk/dports/devel
ryandesign at macports.org
ryandesign at macports.org
Sun May 18 05:04:12 PDT 2014
Revision: 120169
https://trac.macports.org/changeset/120169
Author: ryandesign at macports.org
Date: 2014-05-18 05:04:12 -0700 (Sun, 18 May 2014)
Log Message:
-----------
glib2, glib2-devel: fix g_get_monotonic_time on non-Intel processors (#43346)
Modified Paths:
--------------
trunk/dports/devel/glib2/Portfile
trunk/dports/devel/glib2-devel/Portfile
Added Paths:
-----------
trunk/dports/devel/glib2/files/patch-glib-gmain.c.diff
trunk/dports/devel/glib2-devel/files/patch-glib-gmain.c.diff
Modified: trunk/dports/devel/glib2/Portfile
===================================================================
--- trunk/dports/devel/glib2/Portfile 2014-05-18 06:03:17 UTC (rev 120168)
+++ trunk/dports/devel/glib2/Portfile 2014-05-18 12:04:12 UTC (rev 120169)
@@ -11,6 +11,7 @@
conflicts glib2-devel
set my_name glib
version 2.40.0
+revision 1
set branch [join [lrange [split ${version} .] 0 1] .]
categories devel
maintainers ryandesign openmaintainer
@@ -38,6 +39,7 @@
# See https://trac.macports.org/changeset/27148
patchfiles patch-configure.diff \
patch-glib-2.0.pc.in.diff \
+ patch-glib-gmain.c.diff \
patch-glib_gunicollate.c.diff \
patch-gi18n.h.diff \
patch-gio_xdgmime_xdgmime.c.diff \
Added: trunk/dports/devel/glib2/files/patch-glib-gmain.c.diff
===================================================================
--- trunk/dports/devel/glib2/files/patch-glib-gmain.c.diff (rev 0)
+++ trunk/dports/devel/glib2/files/patch-glib-gmain.c.diff 2014-05-18 12:04:12 UTC (rev 120169)
@@ -0,0 +1,73 @@
+Fix g_get_monotonic_time on non-Intel processors
+https://bugzilla.gnome.org/show_bug.cgi?id=728123
+https://bug728123.bugzilla-attachments.gnome.org/attachment.cgi?id=275596
+--- glib/gmain.c.orig
++++ glib/gmain.c
+@@ -2648,46 +2648,34 @@ gint64
+ g_get_monotonic_time (void)
+ {
+ static mach_timebase_info_data_t timebase_info;
++ static double absolute_to_micro;
+
+ if (timebase_info.denom == 0)
+ {
+- /* This is a fraction that we must use to scale
+- * mach_absolute_time() by in order to reach nanoseconds.
+- *
+- * We've only ever observed this to be 1/1, but maybe it could be
+- * 1000/1 if mach time is microseconds already, or 1/1000 if
+- * picoseconds. Try to deal nicely with that.
++ /* mach_absolute_time() returns "absolute time units", rather than
++ seconds; the mach_timebase_info_data_t struct provides a
++ fraction that can be used to convert these units into seconds.
+ */
+ mach_timebase_info (&timebase_info);
+-
+- /* We actually want microseconds... */
+- if (timebase_info.numer % 1000 == 0)
+- timebase_info.numer /= 1000;
+- else
+- timebase_info.denom *= 1000;
+-
+- /* We want to make the numer 1 to avoid having to multiply... */
+- if (timebase_info.denom % timebase_info.numer == 0)
+- {
+- timebase_info.denom /= timebase_info.numer;
+- timebase_info.numer = 1;
+- }
+- else
+- {
+- /* We could just multiply by timebase_info.numer below, but why
+- * bother for a case that may never actually exist...
+- *
+- * Plus -- performing the multiplication would risk integer
+- * overflow. If we ever actually end up in this situation, we
+- * should more carefully evaluate the correct course of action.
+- */
+- mach_timebase_info (&timebase_info); /* Get a fresh copy for a better message */
+- g_error ("Got weird mach timebase info of %d/%d. Please file a bug against GLib.",
+- timebase_info.numer, timebase_info.denom);
+- }
++ absolute_to_micro = 1e-3 * timebase_info.numer / timebase_info.denom;
+ }
+
+- return mach_absolute_time () / timebase_info.denom;
++ if (timebase_info.denom == 1 && timebase_info.numer == 1)
++ {
++ /* On Intel, the fraction has been 1/1 to date, so we can shortcut
++ the conversion into microseconds.
++ */
++ return mach_absolute_time () / 1000;
++ }
++ else
++ {
++ /* On ARM and PowerPC, the value is unpredictable and is hardware
++ dependent, so we can't guess. Both the units and numer/denom
++ are extremely large, so the conversion number is stored as a
++ double in order to avoid integer overflow.
++ */
++ return mach_absolute_time () * absolute_to_micro;
++ }
+ }
+ #else
+ gint64
Modified: trunk/dports/devel/glib2-devel/Portfile
===================================================================
--- trunk/dports/devel/glib2-devel/Portfile 2014-05-18 06:03:17 UTC (rev 120168)
+++ trunk/dports/devel/glib2-devel/Portfile 2014-05-18 12:04:12 UTC (rev 120169)
@@ -11,6 +11,7 @@
conflicts glib2
set my_name glib
version 2.40.0
+revision 1
set branch [join [lrange [split ${version} .] 0 1] .]
categories devel
maintainers ryandesign openmaintainer
@@ -38,6 +39,7 @@
# See https://trac.macports.org/changeset/27148
patchfiles patch-configure.diff \
patch-glib-2.0.pc.in.diff \
+ patch-glib-gmain.c.diff \
patch-glib_gunicollate.c.diff \
patch-gi18n.h.diff \
patch-gio_xdgmime_xdgmime.c.diff \
Added: trunk/dports/devel/glib2-devel/files/patch-glib-gmain.c.diff
===================================================================
--- trunk/dports/devel/glib2-devel/files/patch-glib-gmain.c.diff (rev 0)
+++ trunk/dports/devel/glib2-devel/files/patch-glib-gmain.c.diff 2014-05-18 12:04:12 UTC (rev 120169)
@@ -0,0 +1,73 @@
+Fix g_get_monotonic_time on non-Intel processors
+https://bugzilla.gnome.org/show_bug.cgi?id=728123
+https://bug728123.bugzilla-attachments.gnome.org/attachment.cgi?id=275596
+--- glib/gmain.c.orig
++++ glib/gmain.c
+@@ -2648,46 +2648,34 @@ gint64
+ g_get_monotonic_time (void)
+ {
+ static mach_timebase_info_data_t timebase_info;
++ static double absolute_to_micro;
+
+ if (timebase_info.denom == 0)
+ {
+- /* This is a fraction that we must use to scale
+- * mach_absolute_time() by in order to reach nanoseconds.
+- *
+- * We've only ever observed this to be 1/1, but maybe it could be
+- * 1000/1 if mach time is microseconds already, or 1/1000 if
+- * picoseconds. Try to deal nicely with that.
++ /* mach_absolute_time() returns "absolute time units", rather than
++ seconds; the mach_timebase_info_data_t struct provides a
++ fraction that can be used to convert these units into seconds.
+ */
+ mach_timebase_info (&timebase_info);
+-
+- /* We actually want microseconds... */
+- if (timebase_info.numer % 1000 == 0)
+- timebase_info.numer /= 1000;
+- else
+- timebase_info.denom *= 1000;
+-
+- /* We want to make the numer 1 to avoid having to multiply... */
+- if (timebase_info.denom % timebase_info.numer == 0)
+- {
+- timebase_info.denom /= timebase_info.numer;
+- timebase_info.numer = 1;
+- }
+- else
+- {
+- /* We could just multiply by timebase_info.numer below, but why
+- * bother for a case that may never actually exist...
+- *
+- * Plus -- performing the multiplication would risk integer
+- * overflow. If we ever actually end up in this situation, we
+- * should more carefully evaluate the correct course of action.
+- */
+- mach_timebase_info (&timebase_info); /* Get a fresh copy for a better message */
+- g_error ("Got weird mach timebase info of %d/%d. Please file a bug against GLib.",
+- timebase_info.numer, timebase_info.denom);
+- }
++ absolute_to_micro = 1e-3 * timebase_info.numer / timebase_info.denom;
+ }
+
+- return mach_absolute_time () / timebase_info.denom;
++ if (timebase_info.denom == 1 && timebase_info.numer == 1)
++ {
++ /* On Intel, the fraction has been 1/1 to date, so we can shortcut
++ the conversion into microseconds.
++ */
++ return mach_absolute_time () / 1000;
++ }
++ else
++ {
++ /* On ARM and PowerPC, the value is unpredictable and is hardware
++ dependent, so we can't guess. Both the units and numer/denom
++ are extremely large, so the conversion number is stored as a
++ double in order to avoid integer overflow.
++ */
++ return mach_absolute_time () * absolute_to_micro;
++ }
+ }
+ #else
+ gint64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-changes/attachments/20140518/7e95fcfd/attachment.html>
More information about the macports-changes
mailing list