Re: devel/sdl2 bug since update to 2.0.5
On Thu, Dec 08, 2016 at 07:18:57PM -0800, Ryan Freeman wrote: > On Fri, Dec 02, 2016 at 10:46:32AM -0800, Ryan Freeman wrote: > > I wish I had noticed this sooner when the update was posted... > > > > For whatever reason, certain applications with SDL2 2.0.5 are receving > > duplicate keyboard events. Mouse seems unaffected, but the menus of some > > games are very hard to navigate. > > > > If the Esc key opens a menu, instead what happens is it opens and closes > > before you can do anything. If you happen to be in a menu, arrow keys > > for navigation move the selector up or down two spaces at a time. Trying > > to open a console, would make it open and close immediately as well. > > > > Gameplay-type keys would work normally in my testing. > > > > games/quakespasm shows this problem. > > I have updated to today's snapshot (Dec 8th) and unfortunately the problem > still persists, albeit only within gnome3. > > I haven't had anyone reply to this thread yet that is running gnome3 with > sdl2 games, so I can't be sure yet I am not the only one. and of course I missed a reply from Toby on Dec 6th who did try this within Gnome. Maybe best to just let this rest for now, sorry for the noise everyone. > > Any window manager I try outside of gnome3 does NOT exhibit this issue, > so I am enjoying cwm again for now for these things. > > I have tried the following within gnome to try and resolve the issue > - alternate keyboard > - create fresh account with fresh/default gnome setup > - update snapshot + packages > > No luck thus far, I can't seem to find anyone else running this combination > of things on OpenBSD yet, so if anyone has, please chime in! > > Cheers, > -ryan > > OpenBSD 6.0-current (GENERIC.MP) #23: Thu Dec 8 16:00:49 MST 2016 > bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16357261312 (15599MB) > avail mem = 15856967680 (15122MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf06e0 (71 entries) > bios0: vendor American Megatrends Inc. version "1206" date 04/16/2009 > bios0: ASUSTeK Computer INC. P5K3 Deluxe > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR > acpi0: wakeup devices P0P2(S4) P0P1(S4) UAR1(S4) PS2K(S4) EUSB(S4) USBE(S4) > P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) GBEC(S4) USB0(S4) > USB1(S4) USB2(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.97 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF > cpu0: 3MB 64b/line 8-way L2 cache > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 333MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.63 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF > cpu1: 3MB 64b/line 8-way L2 cache > cpu2 at mainbus0: apid 1 (application processor) > cpu2: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.63 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF > cpu2: 3MB 64b/line 8-way L2 cache > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.63 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF > cpu3: 3MB 64b/line 8-way L2 cache > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (P0P2) > acpiprt2 at acpi0: bus 4 (P0P1) > acpiprt3 at acpi0: bus 3 (P0P4) > acpiprt4 at acpi0: bus -1 (P0P6) > acpiprt5 at acpi0: bus -1 (P0P7) > acpiprt6 at acpi0: bus -1 (P0P8) > acpiprt7 at acpi0: bus 2 (P0P9) > acpicpu0 at acpi0: C1(@1 halt!), PSS > acpicpu1 at acpi0: C1(@1 halt!), PSS > acpicpu2 at acpi0: C1(@1 halt!), PSS > acpicpu3 at acpi0: C1(@1 halt!), PSS > aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM > "PNP0501" at acpi0 not configured > "PNP0303" at acpi0 not configured > "PNP0C32" at acpi0 not configured > acpibtn0 at acpi0: PWRB > cpu0: Enhanced SpeedStep 2504 MHz: speeds: 2497, 1998 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0
Re: devel/sdl2 bug since update to 2.0.5
On Fri, Dec 02, 2016 at 10:46:32AM -0800, Ryan Freeman wrote: > I wish I had noticed this sooner when the update was posted... > > For whatever reason, certain applications with SDL2 2.0.5 are receving > duplicate keyboard events. Mouse seems unaffected, but the menus of some > games are very hard to navigate. > > If the Esc key opens a menu, instead what happens is it opens and closes > before you can do anything. If you happen to be in a menu, arrow keys > for navigation move the selector up or down two spaces at a time. Trying > to open a console, would make it open and close immediately as well. > > Gameplay-type keys would work normally in my testing. > > games/quakespasm shows this problem. I have updated to today's snapshot (Dec 8th) and unfortunately the problem still persists, albeit only within gnome3. I haven't had anyone reply to this thread yet that is running gnome3 with sdl2 games, so I can't be sure yet I am not the only one. Any window manager I try outside of gnome3 does NOT exhibit this issue, so I am enjoying cwm again for now for these things. I have tried the following within gnome to try and resolve the issue - alternate keyboard - create fresh account with fresh/default gnome setup - update snapshot + packages No luck thus far, I can't seem to find anyone else running this combination of things on OpenBSD yet, so if anyone has, please chime in! Cheers, -ryan OpenBSD 6.0-current (GENERIC.MP) #23: Thu Dec 8 16:00:49 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16357261312 (15599MB) avail mem = 15856967680 (15122MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf06e0 (71 entries) bios0: vendor American Megatrends Inc. version "1206" date 04/16/2009 bios0: ASUSTeK Computer INC. P5K3 Deluxe acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR acpi0: wakeup devices P0P2(S4) P0P1(S4) UAR1(S4) PS2K(S4) EUSB(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) GBEC(S4) USB0(S4) USB1(S4) USB2(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.97 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu0: 3MB 64b/line 8-way L2 cache mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.63 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu1: 3MB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.63 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu2: 3MB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, 2504.63 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu3: 3MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P2) acpiprt2 at acpi0: bus 4 (P0P1) acpiprt3 at acpi0: bus 3 (P0P4) acpiprt4 at acpi0: bus -1 (P0P6) acpiprt5 at acpi0: bus -1 (P0P7) acpiprt6 at acpi0: bus -1 (P0P8) acpiprt7 at acpi0: bus 2 (P0P9) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS acpicpu2 at acpi0: C1(@1 halt!), PSS acpicpu3 at acpi0: C1(@1 halt!), PSS aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM "PNP0501" at acpi0 not configured "PNP0303" at acpi0 not configured "PNP0C32" at acpi0 not configured acpibtn0 at acpi0: PWRB cpu0: Enhanced SpeedStep 2504 MHz: speeds: 2497, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x02: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 4870" rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 48xx HD Audio" rev 0x00: msi azalia0: no supported codecs uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 uhci1 at pci0 dev 2
Re: Kernel panic on 6.0-stable
On Thu Dec 08, 2016 at 11:11:33PM +0100, Frank Groeneveld wrote:
> On Sun, Dec 04, 2016 at 07:17:44PM +0100, Jeremie Courreges-Anglas wrote:
> >
> > Hi,
> >
> > Frank Groeneveld writes:
> >
> > > On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote:
> > >> On 20/11/16(Sun) 13:58, Frank Groeneveld wrote:
> > >> > A few week back there was an outage at my ISP. Afterwards, I kept
> > >> > getting crashed on igmpproxy after changing channels on the tv a few
> > >> > times:
> > >>
> > >> This has been fixed in -current.
> > >
> > > Thanks for the pointer. Does it fix both the igmpproxy crash and the
> > > kernel crash? Or just the igmpproxy crash?
> >
> > This igmpproxy crash would probably be trivial to solve, if we had
> > a backtrace. If you're on -current,
> >
> > make clean repackage reinstall DEBUG=-g
> >
> > would install an igmpproxy package with debug symbols. Then running
> > igmpproxy under gdb and typing 'bt' once you hit the crash would give us
> > a helpful backtrace, which you could then send (to ports@ or to me).
> >
> > --
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
> That would be great! I've not upgraded to -current yet, but I captured
> the backtrace on 5.9. I've also included some debugging output from
> before the crash.
>
> Let me know how I can help resolve this.
>
> Frank
Just for fun, diff below updates igmpproxy from beta2 (2005-09-13) to final
(2009-10-05). I deleted all undocumented patches. Maybe this is a
mistake, maybe not.
Frank, maybe it helps you.
Rafael
Index: Makefile
===
RCS file: /cvs/ports/net/igmpproxy/Makefile,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile
--- Makefile4 Dec 2016 20:20:44 - 1.14
+++ Makefile8 Dec 2016 23:29:25 -
@@ -2,11 +2,10 @@
COMMENT = multicast router utilizing IGMP forwarding
-VERSION = 0.1-beta2
-DISTNAME = igmpproxy-src-${VERSION}
-PKGNAME = igmpproxy-${VERSION:S/-beta/b/}
-REVISION = 8
+DISTNAME = igmpproxy-0.1
+REVISION = 9
CATEGORIES = net
+
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=igmpproxy/}
HOMEPAGE = http://igmpproxy.sourceforge.net/
@@ -18,20 +17,13 @@ PERMIT_PACKAGE_CDROM = Yes
WANTLIB = c
-USE_GMAKE =Yes
-
-MAKE_FLAGS = LDFLAGS="${LDFLAGS}"
+CONFIGURE_STYLE = gnu
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/igmpproxy/src
-
-do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/igmpproxy ${PREFIX}/sbin
- ${INSTALL_MAN} ${WRKSRC}/../doc/igmpproxy.8 ${PREFIX}/man/man8
- ${INSTALL_MAN} ${WRKSRC}/../doc/igmpproxy.conf.5 ${PREFIX}/man/man5
+post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/igmpproxy
${INSTALL_DATA} ${WRKSRC}/igmpproxy.conf \
- ${PREFIX}/share/examples/igmpproxy
+ ${PREFIX}/share/examples/igmpproxy
.include
Index: distinfo
===
RCS file: /cvs/ports/net/igmpproxy/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- distinfo18 Jan 2015 03:14:40 - 1.2
+++ distinfo8 Dec 2016 23:29:25 -
@@ -1,2 +1,2 @@
-SHA256 (igmpproxy-src-0.1-beta2.tar.gz) =
f25UhuhIJxUMjKQClnyWM0u9Yrn3hRlcTuhNoSGKu0A=
-SIZE (igmpproxy-src-0.1-beta2.tar.gz) = 35103
+SHA256 (igmpproxy-0.1.tar.gz) = 7hj/PYw646KdzLfl7t8zIzczACAWi9laEc7OjX1+5q4=
+SIZE (igmpproxy-0.1.tar.gz) = 140159
Index: patches/patch-Makefile
===
RCS file: patches/patch-Makefile
diff -N patches/patch-Makefile
--- patches/patch-Makefile 8 Feb 2008 19:30:52 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,28 +0,0 @@
-$OpenBSD: patch-Makefile,v 1.1.1.1 2008/02/08 19:30:52 sthen Exp $
Makefile.orig Sat Aug 20 13:34:18 2005
-+++ Makefile Sat Jan 26 13:16:23 2008
-@@ -6,12 +6,11 @@ MANDIR=/usr/share/man
-
-
- # CFLAGS=-g
--CFLAGS=-O
-+CFLAGS?=-O
-+CFLAGS+=-Wall
-
--default : build.h igmpproxy
-+all : build.h igmpproxy
-
--all : igmpproxy
--
- clean :
- rm -f *.o *.asm build.h igmpproxy
-
-@@ -21,7 +20,7 @@ install :
- cp ../doc/igmpproxy.conf.5 ${MANDIR}/man5
- if [ ! -e ${ETCDIR}/igmpproxy.conf ]; then cp igmpproxy.conf ${ETCDIR};
fi
-
--igmpproxy : igmpproxy.o config.o confread.o request.o udpsock.o mcgroup.o
rttable.o \
-+igmpproxy : igmpproxy.o config.o confread.o request.o mcgroup.o rttable.o \
- igmp.o ifvc.o callout.o kern.o syslog.o lib.o
mroute-api.o
-
- build.h :
Index: patches/patch-config_c
===
RCS file: patches/patch-config_c
diff -N patches/patch-config_c
--- patches/patch-config_c 7 Jun 2013 20:06:03 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,54 +0,0 @@
-$OpenBSD: patch-config_c,v 1.2 2013/06/07 20:06:03 dcoppa Exp $
config.c.orig
Re: Kernel panic on 6.0-stable
On Thu, Dec 08, 2016 at 11:11:33PM +0100, Frank Groeneveld wrote: > On Sun, Dec 04, 2016 at 07:17:44PM +0100, Jeremie Courreges-Anglas wrote: > > > > Hi, > > > > Frank Groeneveld writes: > > > > > On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote: > > >> On 20/11/16(Sun) 13:58, Frank Groeneveld wrote: > > >> > A few week back there was an outage at my ISP. Afterwards, I kept > > >> > getting crashed on igmpproxy after changing channels on the tv a few > > >> > times: > > >> > > >> This has been fixed in -current. > > > > > > Thanks for the pointer. Does it fix both the igmpproxy crash and the > > > kernel crash? Or just the igmpproxy crash? > > > > This igmpproxy crash would probably be trivial to solve, if we had > > a backtrace. If you're on -current, > > > > make clean repackage reinstall DEBUG=-g > > > > would install an igmpproxy package with debug symbols. Then running > > igmpproxy under gdb and typing 'bt' once you hit the crash would give us > > a helpful backtrace, which you could then send (to ports@ or to me). > > > > -- > > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > > That would be great! I've not upgraded to -current yet, but I captured > the backtrace on 5.9. I've also included some debugging output from > before the crash. > > Let me know how I can help resolve this. > > Frank > Forgot the attachment... Current routing table (Remove route); - Debu: #0: Dst: 224.3.2.6, Age:2, St: A, OutVifs: 0x0002 Debu: #0: Origin: 213.75.167.58 floodIf -1 pktcnt 224 Debu: #1: Dst: 224.0.251.124, Age:2, St: A, OutVifs: 0x0002 Debu: #1: Origin: 213.75.167.6 floodIf -1 pktcnt 12686 Debu: #2: Dst: 224.0.251.126, Age:2, St: A, OutVifs: 0x0002 Debu: #2: Origin: 213.75.167.6 floodIf -1 pktcnt 6384 Debu: #3: Dst: 239.255.255.250, Age:2, St: A, OutVifs: 0x0002 Debu: #3: Origin: 192.168.1.2 floodIf 2 pktcnt 368 Debu: #3: Origin: 192.168.2.10 floodIf 1 pktcnt 26 Debu: - Debu: About to call timeout 15 (#1) Debu: Aging Origin 213.75.167.6 Dst 224.0.251.124 PktCnt 12686 -> 12686 Debu: Origin 213.75.167.6 Vif bits : 0x0002 Debu: Setting TTL for Vif 1 to 1 Debu: Identified VIF #2 as upstream. Note: Removing MFC: 213.75.167.6 -> 224.0.251.124, InpVIf: 2 igmpproxy(26355) in free(): error: use after free 0xee1e9c3adc0 Program received signal SIGABRT, Aborted. 0x0ee1e7a5487a in thrkill () at :2 2 : No such file or directory. in Current language: auto; currently asm (gdb) bt #0 0x0ee1e7a5487a in thrkill () at :2 #1 0x0ee1e7a4ff39 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52 #2 0x0ee1e7a32279 in wrterror (msg=0xee1e7b5b378 "use after free", p=0xee1e9c3adc0) at /usr/src/lib/libc/stdlib/malloc.c:283 #3 0x0ee1e7a3384c in ofree (p=0xee1e9c3adc0) at /usr/src/lib/libc/stdlib/malloc.c:1235 #4 0x0ee1e7a338ee in free (ptr=0xee19f72fac0) at /usr/src/lib/libc/stdlib/malloc.c:1340 #5 0x0edeecb03f4e in internAgeRoute (croute=0xee16d3c9cc0) at rttable.c:614 #6 0x0edeecb04118 in lastMemberGroupAge (group=Variable "group" is not available. ) at rttable.c:483 #7 0x0edeecb03070 in sendGroupSpecificMemberQuery (argument=0xee1e9c3c500) at request.c:156 #8 0x0edeecb05880 in age_callout_queue (elapsed_time=0) at callout.c:91 #9 0x0edeecb01e06 in igmpProxyRun () at igmpproxy.c:378 #10 0x0edeecb02321 in main (ArgCn=2, ArgVc=0x7f7e32c8) at igmpproxy.c:181
Re: Kernel panic on 6.0-stable
On Sun, Dec 04, 2016 at 07:17:44PM +0100, Jeremie Courreges-Anglas wrote: > > Hi, > > Frank Groeneveld writes: > > > On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote: > >> On 20/11/16(Sun) 13:58, Frank Groeneveld wrote: > >> > A few week back there was an outage at my ISP. Afterwards, I kept > >> > getting crashed on igmpproxy after changing channels on the tv a few > >> > times: > >> > >> This has been fixed in -current. > > > > Thanks for the pointer. Does it fix both the igmpproxy crash and the > > kernel crash? Or just the igmpproxy crash? > > This igmpproxy crash would probably be trivial to solve, if we had > a backtrace. If you're on -current, > > make clean repackage reinstall DEBUG=-g > > would install an igmpproxy package with debug symbols. Then running > igmpproxy under gdb and typing 'bt' once you hit the crash would give us > a helpful backtrace, which you could then send (to ports@ or to me). > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE That would be great! I've not upgraded to -current yet, but I captured the backtrace on 5.9. I've also included some debugging output from before the crash. Let me know how I can help resolve this. Frank
Re: pkg_add netsurf not pulling in libnspsl
On Thu, Dec 08, 2016 at 04:41:23PM +, Stuart Henderson wrote:
> On 2016/12/08 17:04, Marc Espie wrote:
> > On Thu, Dec 08, 2016 at 12:54:05PM +, Stuart Henderson wrote:
> > > On 2016/12/07 16:09, Bryan Vyhmeister wrote:
> > > > Adding libnspsl manually solved the problem. A quick look at the
> > > > Makefile for www/netsurf/browser seems to indicate that libnspsl should
> > > > have been pulled in but perhaps I was looking at the wrong thing. Any
> > > > idea what the issue might be that is causing libnspsl to be left out
> > > > when installing netsurf and its dependencies?
> > >
> > > Anthony fixed it, but here's some more info. At the end of build you see
> > > this:
> > >
> > > ===> Building package for netsurf-3.6p0
> > > Create /usr/ports/packages/amd64/all/netsurf-3.6p0.tgz
> > > LIB_DEPENDS STEM->=0.1.0:www/netsurf/libnspsl not needed for
> > > www/netsurf/browser ?
> > > Link to /usr/ports/packages/amd64/ftp/netsurf-3.6p0.tgz
> > > Link to /usr/ports/packages/amd64/cdrom/netsurf-3.6p0.tgz
> > >
> > > This indicates that libnspsl is in LIB_DEPENDS but no library from that
> > > package is listed in WANTLIB. I wonder if we should turn this into a hard
> > > error.
> > > bsd.port.mk(5) says:
> > >
> > > : LIB_DEPENDS not needed for There doesn't seem to
> > > be
> > > : any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS
> > > won't
> > > : turn into a @depends line in the created package. This is often
> > > because of
> > > : confusion between LIB_DEPENDS and RUN_DEPENDS: RUN_DEPENDS is needed
> > > for
> > > : dlopen'd libraries.
> > > :
> > > : Might be intentional sometimes, if some compile flavors create static
> > > : binaries, for instance.
> > >
> > > People can cope with flavours by setting LIB_DEPENDS conditionally.
> > >
> > > : Also, will happen for multi-packages, where
> > > one
> > > : sets LIB_DEPENDS to have a given build dependency (and corresponding
> > > WANTLIB
> > > : for a given SUBPACKAGE).
> > >
> > > I don't understand this case, if something is in LIB_DEPENDS then there
> > > should be a WANTLIB, if there isn't a need for a WANTLIB entry then there
> > > isn't a need for a LIB_DEPENDS entry either.
> >
> > You are forgetting about static libraries.
> > Even though we no longer have static-only architectures, keeping the
> > possibility to work with static libraries (for instance in flavors) is
> > still desireable.
>
> If it's for a static FLAVOR, is there a reason why we can't just have it
> like this?
>
> .if ${FLAVOR:Mstatic}
> BUILD_DEPENDS+= foo
> .else
> LIB_DEPENDS+= foo
> WANTLIB+= foo
> .endif
>
> (Although I sometimes specifically add an "Extra" LIB_DEPENDS/WANTLIB
> for a static FLAVOR - if e.g. libc has a major bump because a kernel
> interface changed, it's nice to get the static package updated without
> having to manually bump REVISION)
>
> When somebody sees that message, it usually means there was a mistake.
Should probably have a look see how many times this is used and whether
it's worth retiring.
It was obviously making a lot more sense back when we had static
architectures, I decided to leave it in for now because there was already
a lot of churn when we removed support.
Like many things in the ports tree, we need to check whether removing this
will affect a lot of remaining things or not. I would err on the side of
caution.
[NEW] devel/gcovr
Gcovr provides a utility for managing the use of the GNU gcov utility and generating summarized code coverage results. This command is inspired by the Python coverage.py package, which provides a similar utility in Python. The gcovr command produces either compact human-readable summary reports, machine readable XML reports (in Cobertura format) or simple HTML reports. Thus, gcovr can be viewed as a command-line alternative to the lcov utility, which runs gcov and generates an HTML-formatted report. Personally I found it more convenient than popular lcov. Sergey gcovr.tgz Description: application/tar-gz
Re: pkg_add netsurf not pulling in libnspsl
On 2016/12/08 17:04, Marc Espie wrote:
> On Thu, Dec 08, 2016 at 12:54:05PM +, Stuart Henderson wrote:
> > On 2016/12/07 16:09, Bryan Vyhmeister wrote:
> > > Adding libnspsl manually solved the problem. A quick look at the
> > > Makefile for www/netsurf/browser seems to indicate that libnspsl should
> > > have been pulled in but perhaps I was looking at the wrong thing. Any
> > > idea what the issue might be that is causing libnspsl to be left out
> > > when installing netsurf and its dependencies?
> >
> > Anthony fixed it, but here's some more info. At the end of build you see
> > this:
> >
> > ===> Building package for netsurf-3.6p0
> > Create /usr/ports/packages/amd64/all/netsurf-3.6p0.tgz
> > LIB_DEPENDS STEM->=0.1.0:www/netsurf/libnspsl not needed for
> > www/netsurf/browser ?
> > Link to /usr/ports/packages/amd64/ftp/netsurf-3.6p0.tgz
> > Link to /usr/ports/packages/amd64/cdrom/netsurf-3.6p0.tgz
> >
> > This indicates that libnspsl is in LIB_DEPENDS but no library from that
> > package is listed in WANTLIB. I wonder if we should turn this into a hard
> > error.
> > bsd.port.mk(5) says:
> >
> > : LIB_DEPENDS not needed for There doesn't seem to be
> > : any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS won't
> > : turn into a @depends line in the created package. This is often because
> > of
> > : confusion between LIB_DEPENDS and RUN_DEPENDS: RUN_DEPENDS is needed for
> > : dlopen'd libraries.
> > :
> > : Might be intentional sometimes, if some compile flavors create static
> > : binaries, for instance.
> >
> > People can cope with flavours by setting LIB_DEPENDS conditionally.
> >
> > : Also, will happen for multi-packages, where one
> > : sets LIB_DEPENDS to have a given build dependency (and corresponding
> > WANTLIB
> > : for a given SUBPACKAGE).
> >
> > I don't understand this case, if something is in LIB_DEPENDS then there
> > should be a WANTLIB, if there isn't a need for a WANTLIB entry then there
> > isn't a need for a LIB_DEPENDS entry either.
>
> You are forgetting about static libraries.
> Even though we no longer have static-only architectures, keeping the
> possibility to work with static libraries (for instance in flavors) is
> still desireable.
If it's for a static FLAVOR, is there a reason why we can't just have it
like this?
.if ${FLAVOR:Mstatic}
BUILD_DEPENDS+= foo
.else
LIB_DEPENDS+= foo
WANTLIB+= foo
.endif
(Although I sometimes specifically add an "Extra" LIB_DEPENDS/WANTLIB
for a static FLAVOR - if e.g. libc has a major bump because a kernel
interface changed, it's nice to get the static package updated without
having to manually bump REVISION)
When somebody sees that message, it usually means there was a mistake.
Re: pkg_add netsurf not pulling in libnspsl
On Thu, Dec 08, 2016 at 12:54:05PM +, Stuart Henderson wrote: > On 2016/12/07 16:09, Bryan Vyhmeister wrote: > > Adding libnspsl manually solved the problem. A quick look at the > > Makefile for www/netsurf/browser seems to indicate that libnspsl should > > have been pulled in but perhaps I was looking at the wrong thing. Any > > idea what the issue might be that is causing libnspsl to be left out > > when installing netsurf and its dependencies? > > Anthony fixed it, but here's some more info. At the end of build you see this: > > ===> Building package for netsurf-3.6p0 > Create /usr/ports/packages/amd64/all/netsurf-3.6p0.tgz > LIB_DEPENDS STEM->=0.1.0:www/netsurf/libnspsl not needed for > www/netsurf/browser ? > Link to /usr/ports/packages/amd64/ftp/netsurf-3.6p0.tgz > Link to /usr/ports/packages/amd64/cdrom/netsurf-3.6p0.tgz > > This indicates that libnspsl is in LIB_DEPENDS but no library from that > package is listed in WANTLIB. I wonder if we should turn this into a hard > error. > bsd.port.mk(5) says: > > : LIB_DEPENDS not needed for There doesn't seem to be > : any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS won't > : turn into a @depends line in the created package. This is often because of > : confusion between LIB_DEPENDS and RUN_DEPENDS: RUN_DEPENDS is needed for > : dlopen'd libraries. > : > : Might be intentional sometimes, if some compile flavors create static > : binaries, for instance. > > People can cope with flavours by setting LIB_DEPENDS conditionally. > > : Also, will happen for multi-packages, where one > : sets LIB_DEPENDS to have a given build dependency (and corresponding > WANTLIB > : for a given SUBPACKAGE). > > I don't understand this case, if something is in LIB_DEPENDS then there > should be a WANTLIB, if there isn't a need for a WANTLIB entry then there > isn't a need for a LIB_DEPENDS entry either. You are forgetting about static libraries. Even though we no longer have static-only architectures, keeping the possibility to work with static libraries (for instance in flavors) is still desireable.
How to incoporate the rust ecosystem inside ports ?
Hi, I started to discuss, mainly with landry@, on how to properly use Rust ecosystem inside ports. First, some terms: - Rust : the programming language. - rustc: the "official" compiler of Rust. - cargo: the rust packaging system. It will download "crates", build them and make a binary. - crate: a piece of source code in Rust. It could be (with some simplification) a library or a program. At this moment, devel/cargo is the sole program based on crates inside ports. The devel/cargo port is done in way that all required crates (near to 70) are extra distfiles. During build, there are placed inside particular directory, and cargo is configured to look at this directory (instead of network). Recently, danj@ told me about ripgrep (https://github.com/BurntSushi/ripgrep), another program written using Rust. It needs 35 crates (direct and indirect dependencies). Several are used by cargo too. So I would like to open the discussion on the "proper" way to manage crates inside OpenBSD ports tree. In fact, I see mostly two differents ways to deal with them. I also implemented the two in order to experiment a bit. In order to precise my mind: - I don't want to copy the whole Rust ecosystem inside ports. - I don't want to deal with end-users that want to develop in Rust and use ports instead of directly use cargo (fetching crate over network). I place myself in a specific context: we have some programs we want in ports, and there are written in Rust and use cargo and crates. How to deal with that ? The first possibility is what devel/cargo do for now: embedding the crate list inside the port itself, doing some magic (with help from a module for example), and build it (or eventually only a part) using cargo. This way is relatively simple, but doesn't scale very well: Pros: - distfiles are shared between ports. - version management is done by upstream (cargo ensures reproductible build, so it generates a file with crate+version list: Cargo.lock file). Cons: - if patching a crate is required (OpenBSD adaptation, security patch...) it should be done everywhere this crate is used. As multiversion is common with cargo, several patches for differentes versions has to be done, for each port using it. - local configuration for proper crate use has to be done for each crate. For example, libgit2-sys crate (binding for libgit2) could be configured to use system-wide library instead of rebuilding a local copy of libgit2. This configuration has to be done everywhere this crate would be in use. As example: - devel/cargo port using module: https://github.com/semarie/mystuff/tree/master/devel/cargo - sysutils/ripgrep port using module: https://github.com/semarie/mystuff/blob/master/sysutils/ripgrep The module (devel/cargo/cargo.port.mk) is WIP. It is an early version. I work on other version which respects more port-modules(5). What should be looked at for now is devel/cargo and sysutils/ripgrep. As pratical problem, libc-0.2.17 (crate for the binding of libc) doesn't known about openbsd i386. A patch is needed for proper build under i386. The next version (libc-0.2.18, published now, but not when the Cargo.lock was generated) know better about i386, but is only partial (it was published between my 2 patches for complete support). The complete supports isn't published (only lives in master branch of libc). The second possibility is to create a port for each crate. Due to multiversion use in crate (actually devel/cargo is build with bitflags-0.1.1 *and* bitflags-0.7.0 due to indirect dependencies), it implies to use multiversion in ports: having ports for bitflags like: "devel/bitflags/0.1" and "devel/bitflags/0.7". The purpose isn't to build a binary (program or library). Else we would have to completely bypass cargo, and rewrite the logic to build crate and link them together inside ports framework (but it could be doable). The package would contains: - the Rust source code of the crate (cp + chmod) installed in a specific directory of LOCALBASE (saying share/cargo-vendor). - a metadata file, used by cargo when using the "vendor" feature (replacing the network registry by a local source in a directory). This way is more robust and scale better, but would require more human power on openbsd side. Pros: - patching, configuration is done once. - building the port is just: generating a proper source code suitable for openbsd (no binary code so PKG_ARCH=*). - using the cargo test framework would be possible: running "make test" for each crate would told us if something break and where. - version management will be done by us. better control on versions used. Cons: - lot of ports to manage, so lot of man power required. as already mentionned, cargo requires near to 70 crates. if we add test suite, more crates will be needed. - version management will be done by us. more things could break
Re: bsd.port.mk: support for MODFOO_post-extract
On Thu, Dec 08, 2016 at 02:28:24PM +0100, Antoine Jacoutot wrote: > On Thu, Dec 08, 2016 at 02:26:21PM +0100, Sebastien Marie wrote: > > > > .Bl -tag -width do-configure > > +.It Cm extract > > +There is a > > +.Cm post-extract > > +hook that can be activated by defining > > +.Ev MODFOO_post-extract . > > +It will be run right after > > +.Cm post-patch . > > s/post-patch/post-extract no ? > yes. copy/paste error, sorry. -- Sebastien Marie Index: port-modules.5 === RCS file: /cvs/src/share/man/man5/port-modules.5,v retrieving revision 1.210 diff -u -p -r1.210 port-modules.5 --- port-modules.5 29 Oct 2016 18:27:34 - 1.210 +++ port-modules.5 8 Dec 2016 13:47:45 - @@ -141,6 +141,13 @@ to be needed were added. If several modules define the same hook, hook behaviors will be invoked in sequence. .Bl -tag -width do-configure +.It Cm extract +There is a +.Cm post-extract +hook that can be activated by defining +.Ev MODFOO_post-extract . +It will be run right after +.Cm post-extract . .It Cm patch There is a .Cm post-patch
Re: bsd.port.mk: support for MODFOO_post-extract
On Thu, Dec 08, 2016 at 02:26:21PM +0100, Sebastien Marie wrote:
> On Tue, Dec 06, 2016 at 05:27:46PM +0100, Marc Espie wrote:
> > On Sun, Dec 04, 2016 at 06:27:16PM +0100, Sebastien Marie wrote:
> > >
> > > Index: bsd.port.mk
> > > ===
> > > RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> > > retrieving revision 1.1324
> > > diff -u -p -r1.1324 bsd.port.mk
> > > --- bsd.port.mk 31 Oct 2016 11:08:34 - 1.1324
> > > +++ bsd.port.mk 4 Dec 2016 15:22:52 -
> > > @@ -310,7 +310,7 @@ TARGETS += ${_s}-${_t}
> > > .endif
> > > . endfor
> > > .endfor
> > > -.for _t in post-patch pre-configure configure pre-fake post-install
> > > +.for _t in post-extract post-patch pre-configure configure pre-fake
> > > post-install
> > > . for _m in ${MODULES:T:U}
> > > .if defined(MOD${_m}_${_t})
> > > TARGETS += MOD${_m}_${_t}
> > > @@ -2492,6 +2492,11 @@ ${_EXTRACT_COOKIE}: ${_WRKDIR_COOKIE}
> > > .if target(post-extract)
> > > @${_MAKESYS} post-extract
> > > .endif
> > > +.for _m in ${MODULES:T:U}
> > > +. if defined(MOD${_m}_post-extract)
> > > + @${MOD${_m}_post-extract}
> > > +. endif
> > > +.endfor
> > > @${_MAKE_COOKIE} $@
> > >
> > > .if !target(do-extract)
> > Requires documentation (port-modules) but okay.
>
> Here the documentation part.
>
> I don't merge it with previous patch as documentation is under src/ and
> the makefile part under ports/.
>
> Thanks.
> --
> Sebastien Marie
>
>
> Index: port-modules.5
> ===
> RCS file: /cvs/src/share/man/man5/port-modules.5,v
> retrieving revision 1.210
> diff -u -p -r1.210 port-modules.5
> --- port-modules.529 Oct 2016 18:27:34 - 1.210
> +++ port-modules.58 Dec 2016 13:06:40 -
> @@ -141,6 +141,13 @@ to be needed were added.
> If several modules define the same hook, hook behaviors will be
> invoked in sequence.
> .Bl -tag -width do-configure
> +.It Cm extract
> +There is a
> +.Cm post-extract
> +hook that can be activated by defining
> +.Ev MODFOO_post-extract .
> +It will be run right after
> +.Cm post-patch .
s/post-patch/post-extract no ?
--
Antoine
Re: bsd.port.mk: support for MODFOO_post-extract
On Tue, Dec 06, 2016 at 05:27:46PM +0100, Marc Espie wrote:
> On Sun, Dec 04, 2016 at 06:27:16PM +0100, Sebastien Marie wrote:
> >
> > Index: bsd.port.mk
> > ===
> > RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> > retrieving revision 1.1324
> > diff -u -p -r1.1324 bsd.port.mk
> > --- bsd.port.mk 31 Oct 2016 11:08:34 - 1.1324
> > +++ bsd.port.mk 4 Dec 2016 15:22:52 -
> > @@ -310,7 +310,7 @@ TARGETS += ${_s}-${_t}
> > .endif
> > . endfor
> > .endfor
> > -.for _t in post-patch pre-configure configure pre-fake post-install
> > +.for _t in post-extract post-patch pre-configure configure pre-fake
> > post-install
> > . for _m in ${MODULES:T:U}
> > .if defined(MOD${_m}_${_t})
> > TARGETS += MOD${_m}_${_t}
> > @@ -2492,6 +2492,11 @@ ${_EXTRACT_COOKIE}: ${_WRKDIR_COOKIE}
> > .if target(post-extract)
> > @${_MAKESYS} post-extract
> > .endif
> > +.for _m in ${MODULES:T:U}
> > +. if defined(MOD${_m}_post-extract)
> > + @${MOD${_m}_post-extract}
> > +. endif
> > +.endfor
> > @${_MAKE_COOKIE} $@
> >
> > .if !target(do-extract)
> Requires documentation (port-modules) but okay.
Here the documentation part.
I don't merge it with previous patch as documentation is under src/ and
the makefile part under ports/.
Thanks.
--
Sebastien Marie
Index: port-modules.5
===
RCS file: /cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.210
diff -u -p -r1.210 port-modules.5
--- port-modules.5 29 Oct 2016 18:27:34 - 1.210
+++ port-modules.5 8 Dec 2016 13:06:40 -
@@ -141,6 +141,13 @@ to be needed were added.
If several modules define the same hook, hook behaviors will be
invoked in sequence.
.Bl -tag -width do-configure
+.It Cm extract
+There is a
+.Cm post-extract
+hook that can be activated by defining
+.Ev MODFOO_post-extract .
+It will be run right after
+.Cm post-patch .
.It Cm patch
There is a
.Cm post-patch
Re: pkg_add netsurf not pulling in libnspsl
On 2016/12/07 16:09, Bryan Vyhmeister wrote: > Adding libnspsl manually solved the problem. A quick look at the > Makefile for www/netsurf/browser seems to indicate that libnspsl should > have been pulled in but perhaps I was looking at the wrong thing. Any > idea what the issue might be that is causing libnspsl to be left out > when installing netsurf and its dependencies? Anthony fixed it, but here's some more info. At the end of build you see this: ===> Building package for netsurf-3.6p0 Create /usr/ports/packages/amd64/all/netsurf-3.6p0.tgz LIB_DEPENDS STEM->=0.1.0:www/netsurf/libnspsl not needed for www/netsurf/browser ? Link to /usr/ports/packages/amd64/ftp/netsurf-3.6p0.tgz Link to /usr/ports/packages/amd64/cdrom/netsurf-3.6p0.tgz This indicates that libnspsl is in LIB_DEPENDS but no library from that package is listed in WANTLIB. I wonder if we should turn this into a hard error. bsd.port.mk(5) says: : LIB_DEPENDS not needed for There doesn't seem to be : any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS won't : turn into a @depends line in the created package. This is often because of : confusion between LIB_DEPENDS and RUN_DEPENDS: RUN_DEPENDS is needed for : dlopen'd libraries. : : Might be intentional sometimes, if some compile flavors create static : binaries, for instance. People can cope with flavours by setting LIB_DEPENDS conditionally. : Also, will happen for multi-packages, where one : sets LIB_DEPENDS to have a given build dependency (and corresponding WANTLIB : for a given SUBPACKAGE). I don't understand this case, if something is in LIB_DEPENDS then there should be a WANTLIB, if there isn't a need for a WANTLIB entry then there isn't a need for a LIB_DEPENDS entry either.
Re: emacs-25.1.90 pretest: tests wanted
On Wed, Dec 07, 2016 at 11:22:08PM +0100, Jeremie Courreges-Anglas wrote: > > Hi, > > some good news from the Emacs front. > > Since glibc removed "private" stuff that was used for emacs, the > direction is now towards using more portable techniques: > - emacs-25.2 will use system malloc(3) (except for the "unexec" step) > - emacs-26.1 will probably stop using this horrid "unexec" step which is > causing build and toolchain problems since basically forever > This means that emacs should soon stop being this cute time-eating > project and start leveraging the same improvements as all other ports: > no more -Z, PIE, ASLR, etc Related to this, with some technical details: https://lwn.net/Articles/707615/ Landry
Re: emacs-25.1.90 pretest: tests wanted
On 12/08/16 01:05, Jeremie Courreges-Anglas wrote: > Jeremie Courreges-Anglas writes: > >> Hi, >> >> some good news from the Emacs front. >> >> Since glibc removed "private" stuff that was used for emacs, the >> direction is now towards using more portable techniques: >> - emacs-25.2 will use system malloc(3) (except for the "unexec" step) >> - emacs-26.1 will probably stop using this horrid "unexec" step which is >> causing build and toolchain problems since basically forever >> This means that emacs should soon stop being this cute time-eating >> project and start leveraging the same improvements as all other ports: >> no more -Z, PIE, ASLR, etc >> >> The diff below updates to the first pretest for emacs-25.2, which works >> fine for me since a couple of days. It doesn't use malloc(3) from the >> system yet, but it disables the use of ld -z nocombreloc, which upstream >> is considering. >> >> Build tests on !(amd64) would help! > > Actually, a runtime test seems to be needed to ensure that -z > nocombreloc isn't needed any more. Bonus points if you use one of the > graphical flavors. > Build & starts fine on amd64 with gtk3 flavor. I'm using it right now and will report if I encounter any problems. Thanks for your work!
