rxvt-unicode: fix ECB_MEMORY_FENCE
Remove stupid hack and sync with devel/libev.
OK?
Index: Makefile
===
RCS file: /cvs/ports/x11/rxvt-unicode/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile16 Apr 2012 18:08:09 - 1.19
+++ Makefile29 Aug 2012 08:13:26 -
@@ -3,7 +3,7 @@
COMMENT = clone of rxvt with Unicode and Xft support
DISTNAME = rxvt-unicode-9.15
-REVISION = 0
+REVISION = 1
CATEGORIES = x11
EXTRACT_SUFX = .tar.bz2
Index: patches/patch-libev_ev_c
===
RCS file: /cvs/ports/x11/rxvt-unicode/patches/patch-libev_ev_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-libev_ev_c
--- patches/patch-libev_ev_c23 Jan 2012 08:10:41 - 1.2
+++ patches/patch-libev_ev_c29 Aug 2012 08:13:26 -
@@ -1,11 +1,18 @@
$OpenBSD: patch-libev_ev_c,v 1.2 2012/01/23 08:10:41 dcoppa Exp $
--- libev/ev.c.origThu Jan 19 18:55:00 2012
-+++ libev/ev.c Sun Jan 22 18:04:25 2012
-@@ -921,7 +921,6 @@ ecb_function_ ecb_bool ecb_little_endian (void) { retu
- * alternatively, you can remove this #error and link against libpthread,
- * which will then provide the memory fences.
- */
--# error memory fences not defined for your architecture, please report
libev/ev.c Wed Aug 29 10:04:02 2012
+@@ -562,6 +562,14 @@ struct signalfd_siginfo
+ #define ECB_MEMORY_FENCE __asm__ __volatile__ (membar
#LoadStore | #LoadLoad | #StoreStore | #StoreLoad | : : : memory)
+ #define ECB_MEMORY_FENCE_ACQUIRE __asm__ __volatile__ (membar
#LoadStore | #LoadLoad : : : memory)
+ #define ECB_MEMORY_FENCE_RELEASE __asm__ __volatile__ (membar
#LoadStore | #StoreStore)
++#elif defined(__s390__) || defined(__s390x__)
++ #define ECB_MEMORY_FENCE __asm__ __volatile__ (bcr 15,0 : : :
memory)
++#elif defined(__mips__)
++ #define ECB_MEMORY_FENCE __asm__ __volatile__ (sync : : :
memory)
++#elif defined(__alpha__)
++ #define ECB_MEMORY_FENCE __asm__ __volatile__ (mb : : :
memory)
++#elif defined(__hppa__)
++ #define ECB_MEMORY_FENCE __asm__ __volatile__ (sync : : :
memory)
+ #endif
+ #endif
#endif
-
- #ifndef ECB_MEMORY_FENCE
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: Remove stupid hack and sync with devel/libev. OK? This should be using devel/libev not an internal copy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith b...@comstyle.com wrote: On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: Remove stupid hack and sync with devel/libev. OK? This should be using devel/libev not an internal copy. You're saying I should hack urxvt to use the external libev from devel/libev? I could give a try, but I fear it would be invasive...
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 03:17:07PM +0200, David Coppa wrote: On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith b...@comstyle.com wrote: On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: Remove stupid hack and sync with devel/libev. OK? This should be using devel/libev not an internal copy. You're saying I should hack urxvt to use the external libev from devel/libev? I could give a try, but I fear it would be invasive... That's fine. This is far from the first time ports have been modified to use external copies of libraries because upstream didn't do things properly. Since this is still a maintained and active project the port maintainer can work with the authors upstream to have them add a proper autoocnf option to allow building with a system copy of libev. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 3:30 PM, Brad Smith b...@comstyle.com wrote: On Wed, Aug 29, 2012 at 03:17:07PM +0200, David Coppa wrote: On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith b...@comstyle.com wrote: On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: Remove stupid hack and sync with devel/libev. OK? This should be using devel/libev not an internal copy. You're saying I should hack urxvt to use the external libev from devel/libev? I could give a try, but I fear it would be invasive... That's fine. This is far from the first time ports have been modified to use external copies of libraries because upstream didn't do things properly. Since this is still a maintained and active project the port maintainer can work with the authors upstream to have them add a proper autoocnf option to allow building with a system copy of libev. https://bugzilla.redhat.com/show_bug.cgi?id=672396
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 03:36:14PM +0200, David Coppa wrote: On Wed, Aug 29, 2012 at 3:30 PM, Brad Smith b...@comstyle.com wrote: On Wed, Aug 29, 2012 at 03:17:07PM +0200, David Coppa wrote: On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith b...@comstyle.com wrote: On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: Remove stupid hack and sync with devel/libev. OK? This should be using devel/libev not an internal copy. You're saying I should hack urxvt to use the external libev from devel/libev? I could give a try, but I fear it would be invasive... That's fine. This is far from the first time ports have been modified to use external copies of libraries because upstream didn't do things properly. Since this is still a maintained and active project the port maintainer can work with the authors upstream to have them add a proper autoocnf option to allow building with a system copy of libev. https://bugzilla.redhat.com/show_bug.cgi?id=672396 Incredibly stupid, especially when the projects with the incompatible internal copies are from the author of the library. Taking that into consideration I'm OK with the diff until a sane and more ideal solution can be implemented. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 4:22 PM, Brad Smith b...@comstyle.com wrote: Incredibly stupid, especially when the projects with the incompatible internal copies are from the author of the library. yes I know :( Taking that into consideration I'm OK with the diff until a sane and more ideal solution can be implemented.
