Re: gcc4.9 and _Unwind_Resume segfaults

[Vadim Zhukov]

2016-12-22 1:36 GMT+03:00 Karel Gardas :
> On Wed, Dec 21, 2016 at 11:24 PM, Paul Irofti  wrote:
>>> the port (if everything there is C++-based, tweaking CONFIGURE_ENV
>>
>> Teach me how :)
>>
>> It doesn't work with this
>>
>> CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include -I${X11BASE}/include \
>> -I${LOCALBASE}/include/ereadline" \
>> LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib -lestdc++" \
>> LRELEASE="${MODQT_LRELEASE}" \
>> F77=${FC}
>
> Shouldn't c++ app be linked with using eg++ which should put -lestdc++
> implicitly there without a need to do that on the command-line?

Yes, and it's the problem: the libtool doesn't see that -lestdc++ and
thus doesn't cut -lstdc++.

--
  WBR,
  Vadim Zhukov

Re: gcc4.9 and _Unwind_Resume segfaults

[Vadim Zhukov]

2016-12-22 1:24 GMT+03:00 Paul Irofti :
>> the port (if everything there is C++-based, tweaking CONFIGURE_ENV
>
> Teach me how :)
>
> It doesn't work with this
>
> CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include -I${X11BASE}/include \
> -I${LOCALBASE}/include/ereadline" \
> LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib -lestdc++" \
> LRELEASE="${MODQT_LRELEASE}" \
> F77=${FC}

I'm rebuilding octave right now. It picked up -lestdc++ from
CONFIGURE_ENV, lets see the linking results...

--
  WBR,
  Vadim Zhukov

UPDATE net/nmap 7.40

[David CARLIER]

Hi,

there is the update to the newest version.

Cheers.
Index: Makefile
===
RCS file: /cvs/ports/net/nmap/Makefile,v
retrieving revision 1.122
diff -u -p -r1.122 Makefile
--- Makefile6 Oct 2016 05:47:35 -   1.122
+++ Makefile22 Dec 2016 06:20:18 -
@@ -3,7 +3,7 @@
 COMMENT-main=  scan ports and fingerprint stack of network hosts
 COMMENT-zenmap=graphical frontend for nmap
 
-MODPY_EGG_VERSION= 7.30
+MODPY_EGG_VERSION= 7.40
 DISTNAME=  nmap-${MODPY_EGG_VERSION}
 PKGNAME-main=  ${DISTNAME}
 PKGNAME-zenmap=nmap-zenmap-${MODPY_EGG_VERSION}
Index: distinfo
===
RCS file: /cvs/ports/net/nmap/distinfo,v
retrieving revision 1.35
diff -u -p -r1.35 distinfo
--- distinfo6 Oct 2016 05:47:35 -   1.35
+++ distinfo22 Dec 2016 06:20:18 -
@@ -1,2 +1,2 @@
-SHA256 (nmap-7.30.tgz) = LdYrr7IGxgBe5SLhKNTpXd+4pVwLtaUz/hF0y4DjS4w=
-SIZE (nmap-7.30.tgz) = 11106693
+SHA256 (nmap-7.40.tgz) = rDX2ToIAce+naMNMlu10G3J4u/zp/td2zTIAyi2QSmU=
+SIZE (nmap-7.40.tgz) = 11229014
Index: patches/patch-libnetutil_netutil_cc
===
RCS file: /cvs/ports/net/nmap/patches/patch-libnetutil_netutil_cc,v
retrieving revision 1.9
diff -u -p -r1.9 patch-libnetutil_netutil_cc
--- patches/patch-libnetutil_netutil_cc 6 Oct 2016 05:47:35 -   1.9
+++ patches/patch-libnetutil_netutil_cc 22 Dec 2016 06:20:18 -
@@ -8,9 +8,9 @@ http://marc.info/?l=nmap-dev=140179174
 
 chunks dealing with iovec: ???
 
 libnetutil/netutil.cc.orig Thu Aug 25 19:41:03 2016
-+++ libnetutil/netutil.cc  Thu Sep 29 22:04:48 2016
-@@ -3172,7 +3172,6 @@ static int route_dst_netlink(const struct sockaddr_sto
+--- libnetutil/netutil.cc.orig Wed Dec 14 00:12:23 2016
 libnetutil/netutil.cc  Thu Dec 22 05:45:11 2016
+@@ -3179,7 +3179,6 @@ static int route_dst_netlink(const struct sockaddr_sto
   const struct sockaddr_storage *spoofss) {
struct sockaddr_nl snl;
struct msghdr msg;
@@ -18,7 +18,7 @@ chunks dealing with iovec: ???
struct nlmsghdr *nlmsg;
struct rtmsg *rtmsg;
struct rtattr *rtattr;
-@@ -3224,22 +3223,14 @@ static int route_dst_netlink(const struct sockaddr_sto
+@@ -3231,22 +3230,14 @@ static int route_dst_netlink(const struct sockaddr_sto
  add_rtattr_addr(nlmsg, , , RTA_SRC, spoofss, intf_index);
}
  
@@ -41,7 +41,7 @@ chunks dealing with iovec: ???
len = recvmsg(fd, , 0);
if (len <= 0)
  netutil_fatal("%s: cannot recvmsg: %s", __func__, strerror(errno));
-@@ -3870,7 +3861,6 @@ static const unsigned char *add_exthdr_ancillary(struc
+@@ -3877,7 +3868,6 @@ static const unsigned char *add_exthdr_ancillary(struc
  static int send_ipv6_ip(const struct sockaddr_in6 *dst,
const unsigned char *packet, size_t packetlen) {
struct msghdr msg;
@@ -49,7 +49,7 @@ chunks dealing with iovec: ???
  
const unsigned char *end;
struct ip6_hdr *hdr;
-@@ -3889,8 +3879,6 @@ static int send_ipv6_ip(const struct sockaddr_in6 *dst
+@@ -3896,8 +3886,6 @@ static int send_ipv6_ip(const struct sockaddr_in6 *dst
/* Set up sendmsg data structure. iov is filled in below. */
msg.msg_name = (void *) dst;
msg.msg_namelen = sizeof(*dst);
@@ -58,7 +58,7 @@ chunks dealing with iovec: ???
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_flags = 0;
-@@ -3949,8 +3937,6 @@ static int send_ipv6_ip(const struct sockaddr_in6 *dst
+@@ -3956,8 +3944,6 @@ static int send_ipv6_ip(const struct sockaddr_in6 *dst
}
  
assert(packet <= end);
@@ -67,7 +67,7 @@ chunks dealing with iovec: ???
  
n = sendmsg(sd, , 0);
if (n == -1)
-@@ -4153,9 +4139,6 @@ int datalink_offset(int datalink)
+@@ -4160,9 +4146,6 @@ int datalink_offset(int datalink)
  {
if (datalink == DLT_EN10MB)
  return ETH_HDR_LEN;
@@ -77,7 +77,7 @@ chunks dealing with iovec: ???
else
  return -1;
  }
-@@ -4281,10 +4264,6 @@ static bool accept_arp(const unsigned char *p, const s
+@@ -4288,10 +4271,6 @@ static bool accept_arp(const unsigned char *p, const s
  
if (datalink == DLT_EN10MB) {
  return ntohs(*((u16 *) (p + 12))) == ETH_TYPE_ARP;
Index: patches/patch-scan-engine_cc
===
RCS file: /cvs/ports/net/nmap/patches/patch-scan-engine_cc,v
retrieving revision 1.9
diff -u -p -r1.9 patch-scan-engine_cc
--- patches/patch-scan-engine_cc6 Oct 2016 05:47:35 -   1.9
+++ patches/patch-scan-engine_cc22 Dec 2016 06:20:18 -
@@ -5,9 +5,9 @@ pcap_filter changes: to deal with base l
 
 Format changes for 64-bit time_t, should go upstream
 
 scan_engine.cc.origFri Aug 19 13:38:29 2016
-+++ scan_engine.cc Thu Sep 29 22:04:48 2016
-@@ -2029,7 +2029,7 @@ void ultrascan_host_probe_update(UltraScanInfo *USI, H
+--- scan_engine.cc.orig 

spurious crash dialog box, fail to start

[Ed Ahlsen-Girard]

I run the version from -current (version: 5.2.2.2.0+ Build ID:
20m0(Build:2)) and for some time now, if I start LibreOffice by itself,
without a file specified, I receive a Document Recovery dialog box to
the effect that LibreOffice crashed and was going to try to recover
documents, with no documents listed. If a file is passed as a
command line argument or as the run action specified for the file type
in rox-filer, all is well. I have deleted the user profile, but that
has no effect.

Is this a known problem or just me?

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL

Re: gcc4.9 and _Unwind_Resume segfaults

[Karel Gardas]

On Wed, Dec 21, 2016 at 11:24 PM, Paul Irofti  wrote:
>> the port (if everything there is C++-based, tweaking CONFIGURE_ENV
>
> Teach me how :)
>
> It doesn't work with this
>
> CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include -I${X11BASE}/include \
> -I${LOCALBASE}/include/ereadline" \
> LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib -lestdc++" \
> LRELEASE="${MODQT_LRELEASE}" \
> F77=${FC}

Shouldn't c++ app be linked with using eg++ which should put -lestdc++
implicitly there without a need to do that on the command-line?

Re: gcc4.9 and _Unwind_Resume segfaults

[Paul Irofti]

> the port (if everything there is C++-based, tweaking CONFIGURE_ENV

Teach me how :)

It doesn't work with this

CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include -I${X11BASE}/include \
-I${LOCALBASE}/include/ereadline" \
LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib -lestdc++" \
LRELEASE="${MODQT_LRELEASE}" \
F77=${FC}

Re: Update: www/w3m (0.5.3+git20161120)

[Christian Weisgerber]

On 2016-12-17, Christian Weisgerber  wrote:

> This is a security update and complete overhaul of the www/w3m port.
> It uses the Debian version as upstream, which fixes 23 (!) CVEs,
> and follows the Debian package in some other respects.

I have committed this.  Given the extensive changes, I'm uncertain
what to do about -stable.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/12/21 13:57:09

Modified files:
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 
www: Makefile 

Log message:
Japanese w3m is gone, upgrade to plain w3m

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/12/21 13:54:16

Modified files:
www/w3m: Makefile distinfo 
www/w3m/patches: patch-configure 
www/w3m/pkg: DESCR PFRAG.image PLIST 
Added files:
www/w3m/pkg: PFRAG.no-image 
Removed files:
www/w3m/patches: patch-Makefile_in patch-config_h_in 
 patch-main_c 
www/w3m/pkg: PFRAG.japanese PFRAG.no-japanese 

Log message:
Security update, switch to Debian upstream (0.5.3+git20161120), and
complete overhaul:
* Fixes for 23 CVEs.
* Switch the image flavor to use the lighter imlib2 dependency.
* Drop the japanese flavor; gettext localization is sufficient.
* Convert Japanese docs to UTF-8.

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/12/21 12:18:22

Modified files:
devel  : Makefile 

Log message:
+msgpack

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/12/21 12:17:15

Log message:
import msgpack-2.0.0

MessagePack is an efficient binary serialization format, which lets you
exchange data among multiple languages like JSON, except that it's
faster and smaller. Small integers are encoded into a single byte while
typical short strings require only one extra byte in addition to the
strings themselves.

initial port by edd@
OK edd@

Status:

Vendor Tag: jasper
Release Tags:   jasper_20162112

N ports/devel/msgpack/Makefile
N ports/devel/msgpack/distinfo
N ports/devel/msgpack/pkg/DESCR
N ports/devel/msgpack/pkg/PLIST
N ports/devel/msgpack/patches/patch-CMakeLists_txt
N ports/devel/msgpack/patches/patch-test_CMakeLists_txt

No conflicts created by this import

libestdc++ magic for libtool

[Vadim Zhukov]

Hi, all.

The patch below makes libtool remove -lstdc++ when -lestdc++ exists.
This is needed to fix another poppler linking issue, and likely some
other ports that get both -lstdc++ and -lestdc++ linked in (which is
bad by definition).

A side effect of this patch could/should be some stdc++ entries
in WANTLIB becoming extra ones. So, in theory, this _is_ a package
contents change. But PLIST_DB doesn't register checksums of files,
so this doesn't affect bulk builds themselves.

aja@ kindly put this in a bulk build, and there were no regressions.
So... okay?

To be honest, the patch won't help when either -lstdc++ or -lestdc++
is implied by the compiler. There are some crazy ideas, like:

  * Pass LIBTOOL_CXXLIB=estdc++ from ports framework when "estdc++"
is found in any of WANTLIB* entries;

  * Patch ld(1) instead of libtool;

  * Ask David Blaine for a special magic;

and so on, discussion is open. :)

--
WBR,
  Vadim Zhukov


Index: LT/UList.pm
===
RCS file: /cvs/src/usr.bin/libtool/LT/UList.pm,v
retrieving revision 1.2
diff -u -p -r1.2 UList.pm
--- LT/UList.pm 20 Apr 2014 17:34:26 -  1.2
+++ LT/UList.pm 19 Dec 2016 08:34:15 -
@@ -63,6 +63,8 @@ sub TIEARRAY {
 # returned by tie() or tied() instead.
 sub exists { return exists $_[0]->[0]->{$_[1]}; }
 
+sub indexof { return exists($_[0]->[0]->{$_[1]}) ? ($_[0]->[0]->{$_[1]} - 1) : 
undef; }
+
 sub FETCHSIZE { return scalar(@{$_[0]}) - 1; }
 
 # not needed
@@ -144,8 +146,30 @@ sub SPLICE
$length = $maxrm;
}
 
-   # do not ever dream of adding items here
-   my @ret = splice(@$self, $offset, $length);
+   my $i = @$self;
+
+   # make sure no duplicates get added
+   @_ = grep { !exists $self->[0] or
+   $self->[0]->{$_} >= $offset &&
+   $self->[0]->{$_} < $offset + $length } @_;
+
+   for (@_) {
+   # set up index
+   $self->[0]->{$_} = $i++;
+   }
+
+   #
+   # Renumber (in advance) trailing items, in case something gets added
+   # and number of added and removed items differs.
+   #
+   my $delta = scalar(@_) - $length;
+   if (scalar(@_) and $delta) {
+   for $i ($offset + $length .. scalar(@$self)) {
+   $self->[0]->{$self->[$i]} += $delta;
+   }
+   }
+
+   my @ret = splice(@$self, $offset, $length, @_);
 
for (@ret) {
delete $self->[0]->{$_};
Index: LT/Mode/Link.pm
===
RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v
retrieving revision 1.33
diff -u -p -r1.33 Link.pm
--- LT/Mode/Link.pm 3 Nov 2016 10:23:01 -   1.33
+++ LT/Mode/Link.pm 19 Dec 2016 08:34:15 -
@@ -822,6 +822,20 @@ sub common1
my $staticlibs = [];
my $args = $parser->parse_linkargs2($gp, $orderedlibs, $staticlibs, 
$dirs,
$libs);
+   my $tiedlibs = tied(@$orderedlibs);
+   my $ie = $tiedlibs->indexof("estdc++");
+   my $is = $tiedlibs->indexof("stdc++");
+   if (defined($ie) and defined($is)) {
+   tsay {"stripping stdc++ from orderedlibs due to having estdc++ 
already; ie=$ie, is=$is"};
+   # check what library comes later
+   if ($ie < $is) {
+   splice(@$orderedlibs, $ie, 1);
+   splice(@$orderedlibs, $is, 1, "estdc++");
+   $ie = $is;
+   } else {
+   splice(@$orderedlibs, $is, 1);
+   }
+   }
tsay {"staticlibs = \n", join("\n", @$staticlibs)};
tsay {"orderedlibs = @$orderedlibs"};
return ($staticlibs, $orderedlibs, $args);

samba-4.4.8 patches for -stable

[Jeremie Courreges-Anglas]

Jeremie Courreges-Anglas  writes:

> Hi,
>
> I committed an update to samba-4.5.2 on -current earlier today.  Below
> there's a diff to update to samba-4.5.3, a security update.
>
> o  CVE-2016-2123 (Samba NDR Parsing ndr_pull_dnsp_name Heap-based Buffer
>Overflow Remote Code Execution Vulnerability).
> o  CVE-2016-2125 (Unconditional privilege delegation to Kerberos servers in
>trusted realms).
> o  CVE-2016-2126 (Flaws in Kerberos PAC validation can trigger privilege
>elevation).
>
>   https://www.samba.org/samba/history/samba-4.5.3.html

Committed.

[...]

> For -stable I plan to cook a diff later today / tomorrow, an update to
> 4.4.8 (since -stable is currently at 4.4.5).

Since moving to samba-4.4.8 would imply the removal of a shared library
used by other ports, let's backport the security fixes to samba-4.4.5
instead.

Build tests welcome.  ok?


Index: Makefile
===
RCS file: /d/cvs/ports/net/samba/Makefile,v
retrieving revision 1.227
diff -u -p -r1.227 Makefile
--- Makefile8 Jul 2016 18:39:50 -   1.227
+++ Makefile21 Dec 2016 13:24:24 -
@@ -15,6 +15,7 @@ PKGNAME-tevent =  tevent-${TEVENT_V}
 PKGNAME-util = samba-util-${VERSION}
 PKGNAME-docs = samba-docs-${VERSION}
 
+REVISION-main =0
 REVISION-ldb = 0
 REVISION-tevent =  0
 
Index: patches/patch-auth_kerberos_kerberos_pac_c
===
RCS file: patches/patch-auth_kerberos_kerberos_pac_c
diff -N patches/patch-auth_kerberos_kerberos_pac_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-auth_kerberos_kerberos_pac_c  21 Dec 2016 13:22:23 -
@@ -0,0 +1,50 @@
+$OpenBSD$
+
+commit ce31a69a32d2bd6975006e428afe4584f6b7bc43
+Author: Stefan Metzmacher 
+Date:   Tue Nov 22 17:08:46 2016 +0100
+
+CVE-2016-2126: auth/kerberos: only allow known checksum types in 
check_pac_checksum()
+
+aes based checksums can only be checked with the
+corresponding aes based keytype.
+
+Otherwise we may trigger an undefined code path
+deep in the kerberos libraries, which can leed to
+segmentation faults.
+
+BUG: https://bugzilla.samba.org/show_bug.cgi?id=12446
+
+Signed-off-by: Stefan Metzmacher 
+
+--- auth/kerberos/kerberos_pac.c.orig  Wed Dec 21 12:14:39 2016
 auth/kerberos/kerberos_pac.c   Wed Dec 21 14:20:55 2016
+@@ -39,6 +39,28 @@ krb5_error_code check_pac_checksum(DATA_BLOB pac_data,
+   krb5_boolean checksum_valid = false;
+   krb5_data input;
+ 
++  switch (sig->type) {
++  case CKSUMTYPE_HMAC_MD5:
++  /* ignores the key type */
++  break;
++  case CKSUMTYPE_HMAC_SHA1_96_AES_256:
++  if (KRB5_KEY_TYPE(keyblock) != ENCTYPE_AES256_CTS_HMAC_SHA1_96) 
{
++  return EINVAL;
++  }
++  /* ok */
++  break;
++  case CKSUMTYPE_HMAC_SHA1_96_AES_128:
++  if (KRB5_KEY_TYPE(keyblock) != ENCTYPE_AES128_CTS_HMAC_SHA1_96) 
{
++  return EINVAL;
++  }
++  /* ok */
++  break;
++  default:
++  DEBUG(2,("check_pac_checksum: Checksum Type %d is not 
supported\n",
++  (int)sig->type));
++  return EINVAL;
++  }
++
+ #ifdef HAVE_CHECKSUM_IN_KRB5_CHECKSUM /* Heimdal */
+   cksum.cksumtype = (krb5_cksumtype)sig->type;
+   cksum.checksum.length   = sig->signature.length;
Index: patches/patch-source3_librpc_crypto_gse_c
===
RCS file: patches/patch-source3_librpc_crypto_gse_c
diff -N patches/patch-source3_librpc_crypto_gse_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-source3_librpc_crypto_gse_c   21 Dec 2016 13:23:12 -
@@ -0,0 +1,28 @@
+$OpenBSD$
+
+commit 07ef0f6ce0fb9d9735710ab79c2ee91d7a72a974
+Author: Stefan Metzmacher 
+Date:   Wed Nov 23 11:42:59 2016 +0100
+
+CVE-2016-2125: s3:gse: avoid using GSS_C_DELEG_FLAG
+
+We should only use GSS_C_DELEG_POLICY_FLAG in order to let
+the KDC decide if we should send delegated credentials to
+a remote server.
+
+BUG: https://bugzilla.samba.org/show_bug.cgi?id=12445
+
+Signed-off-by: Stefan Metzmacher 
+Reviewed-by: Alexander Bokovoy 
+Reviewed-by: Simo Sorce 
+
+--- source3/librpc/crypto/gse.c.orig   Wed Dec 21 12:14:43 2016
 source3/librpc/crypto/gse.cWed Dec 21 14:20:55 2016
+@@ -142,7 +142,6 @@ static NTSTATUS gse_context_init(TALLOC_CTX *mem_ctx,
+   memcpy(_ctx->gss_mech, gss_mech_krb5, sizeof(gss_OID_desc));
+ 
+   gse_ctx->gss_want_flags = GSS_C_MUTUAL_FLAG |
+-  GSS_C_DELEG_FLAG |
+   GSS_C_DELEG_POLICY_FLAG |
+   

CVS: cvs.openbsd.org: ports

[Ingo Feinerer]

CVSROOT:/cvs
Module name:ports
Changes by: feine...@cvs.openbsd.org2016/12/21 07:16:30

Modified files:
math/maxima: Makefile distinfo 
math/maxima/pkg: PLIST 

Log message:
Update to Maxima 5.39.0

OK pirofti@

build postgres on arm with ports gcc for atomics

[Jonathan Gray]

Before the change to add arm to the --disable-spinlocks list the
postgres build on arm would error with:

gmake[4]: Entering directory 
'/usr/pobj/postgresql-9.6.1/postgresql-9.6.1/src/backend/access/brin'
cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -O2 -pipe -I../../../../src/include 
-I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include   -c -o 
brin.o brin.c
In file included from ../../../../src/include/storage/lwlock.h:22,
 from ../../../../src/include/storage/lock.h:23,
 from ../../../../src/include/access/heapam.h:22,
 from ../../../../src/include/nodes/execnodes.h:18,
 from ../../../../src/include/access/brin.h:14,
 from brin.c:18:
../../../../src/include/storage/s_lock.h:922:2: error: #error PostgreSQL does 
not have native spinlock support on 
this platform. To continue the compilation, rerun configure using 
--disable-spinlocks. However, performance will be poor. Please report this to 
pgsql-b...@postgresql.org.
In file included from ../../../../src/include/storage/lwlock.h:22,
 from ../../../../src/include/storage/lock.h:23,
 from ../../../../src/include/access/heapam.h:22,
 from ../../../../src/include/nodes/execnodes.h:18,
 from ../../../../src/include/access/brin.h:14,
 from brin.c:18:
../../../../src/include/storage/s_lock.h:994: warning: type defaults to 'int' 
in declaration of 'slock_t'
../../../../src/include/storage/s_lock.h:994: error: expected ';', ',' or ')' 
before '*' token
../../../../src/include/storage/s_lock.h:1004: error: expected '=', ',', ';', 
'asm' or '__attribute__' before 'dummy_spinlock'
../../../../src/include/storage/s_lock.h:1009: warning: type defaults to 'int' 
in declaration of 'slock_t'
../../../../src/include/storage/s_lock.h:1009: error: expected ';', ',' or ')' 
before '*' token
In file included from brin.c:23:
../../../../src/include/access/relscan.h:37: error: expected 
specifier-qualifier-list before 'slock_t'
gmake[4]: *** [: brin.o] Error 1

/*
 * On ARM and ARM64, we use __sync_lock_test_and_set(int *, int) if available.
 *
 * We use the int-width variant of the builtin because it works on more chips
 * than other widths.
 */
#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || 
defined(__aarch64)
#ifdef HAVE_GCC__SYNC_INT32_TAS
#define HAS_TEST_AND_SET

#define TAS(lock) tas(lock)

typedef int slock_t;

static __inline__ int
tas(volatile slock_t *lock)
{
return __sync_lock_test_and_set(lock, 1);
}

#define S_UNLOCK(lock) __sync_lock_release(lock)

#endif   /* HAVE_GCC__SYNC_INT32_TAS */
#endif   /* __arm__ || __arm || __aarch64__ || __aarch64 */

The arm specific path in the header isn't used as base gcc does not
provide the atomic sync builtins on arm.  Switch to ports gcc (which
currently targets mpcore/armv6k) to get the armv6+ atomic builtins.

ports llvm doesn't build on arm currently so that isn't an option.

Index: Makefile
===
RCS file: /cvs/ports/databases/postgresql/Makefile,v
retrieving revision 1.220
diff -u -p -r1.220 Makefile
--- Makefile21 Dec 2016 07:43:57 -  1.220
+++ Makefile21 Dec 2016 13:14:02 -
@@ -11,6 +11,7 @@ COMMENT-pg_upgrade=Support for upgrading
 # in case a dump before / restore after pkg_add -u is required!
 
 VERSION=   9.6.1
+REVISION=  0
 DISTNAME=  postgresql-${VERSION}
 PKGNAME-main=  postgresql-client-${VERSION}
 PKGNAME-server=postgresql-server-${VERSION}
@@ -48,9 +49,12 @@ USE_GROFF=   Yes
 
 CONFIGURE_STYLE=gnu
 
-MODULES=   lang/python
+MODULES=   lang/python gcc4
 MODPY_RUNDEP=  No
 
+# for __sync_lock_test_and_set
+MODGCC4_ARCHS= arm
+
 CONFIGURE_ENV= ac_cv_path_PYTHON=${MODPY_BIN} \
CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
@@ -76,7 +80,7 @@ CONFIGURE_ARGS=   --disable-rpath --with-o
 # a system to get this working, disable them for now. There is
 # (apparently) a serious performance hit doing this.
 
-.if ${MACHINE_ARCH} == "hppa" || ${MACHINE_ARCH} == "alpha" || ${MACHINE_ARCH} 
== "arm"
+.if ${MACHINE_ARCH} == "hppa" || ${MACHINE_ARCH} == "alpha"
 CONFIGURE_ARGS+=--disable-spinlocks
 .endif
 

Re: NEW: sysutils/riemann

[Landry Breuil]

On Tue, Dec 20, 2016 at 10:06:24PM +, Stuart Henderson wrote:
> On 2016/12/21 00:42, Pavel Korovin wrote:
> > On 12/20, Stuart Henderson wrote:
> >  
> > > There are a couple of "/etc/riemann.config", /etc should be replaced
> > > with ${SYSCONFDIR} one way or another (either via SUBST_CMD or a simple
> > > sed -i).
> > 
> > Fixed.
> 
> One more in the rc script; fixed one attached.
> 
> This version is OK sthen@ to import if somebody would like to do that
> (if they don't find something else to tweak :)

imported, thanks pavel!

Landry

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2016/12/21 05:52:45

Modified files:
sysutils   : Makefile 

Log message:
+riemann

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2016/12/21 05:51:56

Log message:
Import riemann 0.2.12, from MAINTAINER Pavel Korovin /p/tristero/se

Riemann provides low-latency, transient shared state for systems with many
moving parts.
Riemann aggregates events from your servers and applications with a powerful
stream processing language. Send an email for every exception raised by your
code. Track the latency distribution of your web app. See the top processes
on any host, by memory and CPU. Combine statistics from every Riak node in
your cluster and forward to Graphite. Send alerts when a key process fails
to check in. Know how many users signed up right this second.

ok sthen@

Status:

Vendor Tag: pkorovin
Release Tags:   landry_20161221

N ports/sysutils/riemann/Makefile
N ports/sysutils/riemann/distinfo
N ports/sysutils/riemann/patches/patch-etc_riemann_config
N ports/sysutils/riemann/patches/patch-bin_riemann
N ports/sysutils/riemann/pkg/riemann.rc
N ports/sysutils/riemann/pkg/DESCR
N ports/sysutils/riemann/pkg/PLIST

No conflicts created by this import

Re: When trying to update port, nothing happens

[Stuart Henderson]

On 2016/12/21 10:26, Артур Истомин wrote:
> I'm trying update some ports, but when I invoke "make update" nothing
> happens. 
> 
> Collecting installed packages: ok
> Collecting port versions: ok
> Collecting port signatures|**Collecting port signatures: ok
> Outdated ports:
> 
> devel/quirks   # always-update -> quirks-2.241
> net/glib2-networking   # @gnutls-3.4.14 -> @gnutls-3.4.15
> x11/gtk+2,-main# @gdk-pixbuf-2.34.0 -> @gdk-pixbuf-2.34.0p0
> x11/gtk+3,-guic# @gdk-pixbuf-2.34.0 -> @gdk-pixbuf-2.34.0p0
> 
> cd x11/gtk+2
> make update
> 
> ...and nothing happens
> 
> I'm doing something wrong?
> My system is OpenBSD 6.0
> 

"make update" is not useful in this case.

In general, "make update" is only really useful for people who are
working on ports development, not for normal users.

I'd _strongly_ recommend you just use binary packages.

If you won't do that, using dpb with the -u and -R flags is probably
the best approach. I'm not sure if that updates everything or just
dependencies, so you might need something like "doas env
TRUSTED_PKG_PATH=/usr/ports/packages/XX/all pkg_add -u" when
it's done.

Re: When trying to update port, nothing happens

[Marc Espie]

On Wed, Dec 21, 2016 at 10:26:24AM +0500, ?? ?? wrote:
> I'm trying update some ports, but when I invoke "make update" nothing
> happens. 
> 
> Collecting installed packages: ok
> Collecting port versions: ok
> Collecting port signatures|**Collecting port signatures: ok
> Outdated ports:
> 
> devel/quirks   # always-update -> quirks-2.241
> net/glib2-networking   # @gnutls-3.4.14 -> @gnutls-3.4.15
> x11/gtk+2,-main# @gdk-pixbuf-2.34.0 -> @gdk-pixbuf-2.34.0p0
> x11/gtk+3,-guic# @gdk-pixbuf-2.34.0 -> @gdk-pixbuf-2.34.0p0
> 
> cd x11/gtk+2
> make update
> 
> ...and nothing happens
> 
> I'm doing something wrong?
> My system is OpenBSD 6.0

You are.

The package name didn't change, so you won't rebuild the package.
You need to do make clean=package  first.

Building ports by yourself is quite possible, but there are a lot of details.
Which is why you're much better off using binary packages unless you want
to invest the time.

Re: gcc4.9 and _Unwind_Resume segfaults

[Vadim Zhukov]

2016-12-21 13:52 GMT+03:00 Paul Irofti :
>> I've added a patch to avoid picking up Qt5.
>
> Your change is fine, thank you!
>
>> But the first issue I see is enormous space eating, due to static
>> libraries (?). I had to remove all port working directories to allow
>> Octave to build, this didn't happen with 4.0 at all. It still builds.
>> :-\
>
> Yes, the space issue might be due to the debug flag.
>
> $ du -sh octave-4.*
> 92.4M   octave-4.0.2
> 10.0G   octave-4.2.0 (with debug)
>
> Have you tried buiding w/o debug symbols?

Hah, missed that -g, thanks!

It looks like libstdc++ is compiled in explicitly while libestdc++
comes implicitly. So libtool patch is useless. It's either patching
the port (if everything there is C++-based, tweaking CONFIGURE_ENV
should be enough) needed, or some other hack. Since libtool doesn't
know what compiler it actually invokes, it can't predict what library
would be added implicitly: -lstdc++ or -lestdc++. :( Does anybody have
any ideas?

--
  WBR,
  Vadim Zhukov

Re: UPDATE: math/maxima

[Paul Irofti]

On Sun, Dec 18, 2016 at 11:20:00AM +0100, Ingo Feinerer wrote:
> Update math/maxima 5.38.1 -> 5.39.0
> 
> Changes:
> https://sourceforge.net/p/maxima/code/ci/master/tree/ChangeLog-5.39.md
> 
> Tested on amd64.
> 
> Now requires a recent texinfo to build -> BUILD_DEPENDS on print/texinfo.
> 
> OK?

OK pirofti@

> 
> Best regards,
> Ingo
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/math/maxima/Makefile,v
> retrieving revision 1.35
> diff -u -p -r1.35 Makefile
> --- Makefile  21 May 2016 17:31:23 -  1.35
> +++ Makefile  18 Dec 2016 10:03:15 -
> @@ -2,7 +2,7 @@
>  
>  COMMENT= GPL computer algebra system based on DOE Macsyma
>  
> -VERSION= 5.38.1
> +VERSION= 5.39.0
>  DISTNAME=maxima-${VERSION}
>  CATEGORIES=  math
>  
> @@ -24,11 +24,15 @@ USE_GMAKE=yes
>  MODULES =lang/python
>  MODPY_RUNDEP =   No
>  
> +BUILD_DEPENDS =  print/texinfo
>  LIB_DEPENDS= lang/ecl
>  RUN_DEPENDS =misc/rlwrap \
>   misc/shared-mime-info
>  
>  SUBST_VARS=  VERSION
> +
> +MAKE_FLAGS = MAKEINFO="${LOCALBASE}/bin/gtexi2any" \
> + TEXI2DVI="${LOCALBASE}/bin/gtexi2dvi"
>  
>  CONFIGURE_ARGS+= --enable-ecl
>  CONFIGURE_STYLE= gnu
> Index: distinfo
> ===
> RCS file: /cvs/ports/math/maxima/distinfo,v
> retrieving revision 1.15
> diff -u -p -r1.15 distinfo
> --- distinfo  21 May 2016 17:31:23 -  1.15
> +++ distinfo  18 Dec 2016 10:03:15 -
> @@ -1,2 +1,2 @@
> -SHA256 (maxima-5.38.1.tar.gz) = DoZlNqtYR+wEW6ATVw+A82IGymzgel0TmHAQvLMhxtw=
> -SIZE (maxima-5.38.1.tar.gz) = 38641257
> +SHA256 (maxima-5.39.0.tar.gz) = 9Y/5gBP8qjfYZhuUFnLDjbWPmC8ILWz8yh8bX6x9cbM=
> +SIZE (maxima-5.39.0.tar.gz) = 38652090
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/math/maxima/pkg/PLIST,v
> retrieving revision 1.14
> diff -u -p -r1.14 PLIST
> --- pkg/PLIST 21 May 2016 17:31:23 -  1.14
> +++ pkg/PLIST 18 Dec 2016 10:03:16 -
> @@ -4,7 +4,10 @@ bin/rmaxima
>  bin/xmaxima
>  @info info/imaxima.info
>  info/maxima-index.lisp
> -@info info/maxima.info
> +info/maxima.info
> +info/maxima.info-1
> +info/maxima.info-2
> +info/maxima.info-3
>  @info info/xmaxima.info
>  lib/maxima/
>  lib/maxima/${VERSION}/
> @@ -64,6 +67,7 @@ share/maxima/${VERSION}/doc/html/figures
>  share/maxima/${VERSION}/doc/html/figures/draw_cbrange.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_cbtics.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_color.gif
> +share/maxima/${VERSION}/doc/html/figures/draw_color2.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_colorbox.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_colorbox2.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_columns.gif
> @@ -112,6 +116,8 @@ share/maxima/${VERSION}/doc/html/figures
>  share/maxima/${VERSION}/doc/html/figures/draw_interpolate_color5.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_interpolate_color6.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_key.gif
> +share/maxima/${VERSION}/doc/html/figures/draw_key_label_alignment.gif
> +share/maxima/${VERSION}/doc/html/figures/draw_key_label_orientation.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_key_pos.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_key_pos2.gif
>  share/maxima/${VERSION}/doc/html/figures/draw_label.gif
> @@ -367,6 +373,10 @@ share/maxima/${VERSION}/doc/html/maxima_
>  share/maxima/${VERSION}/doc/implementation/
>  share/maxima/${VERSION}/doc/implementation/dir_vars.txt
>  share/maxima/${VERSION}/doc/implementation/external-interface.txt
> +share/maxima/${VERSION}/doc/implementation/maximatoplevelflow.dot
> +share/maxima/${VERSION}/doc/implementation/maximatoplevelflow.png
> +share/maxima/${VERSION}/doc/implementation/maximatoplevelflow.ps
> +share/maxima/${VERSION}/doc/implementation/sloop-loop-changes.txt
>  share/maxima/${VERSION}/doc/misc/
>  
> share/maxima/${VERSION}/doc/misc/completescanoffunctionssortedbybytecodelength.txt
>  share/maxima/${VERSION}/doc/misc/grepforvariables.sh
> @@ -400,6 +410,7 @@ share/maxima/${VERSION}/emacs/smart-comp
>  share/maxima/${VERSION}/emacs/sshell.el
>  share/maxima/${VERSION}/share/
>  share/maxima/${VERSION}/share/.gitattributes
> +share/maxima/${VERSION}/share/MYTOPIC-index.lisp
>  share/maxima/${VERSION}/share/affine/
>  share/maxima/${VERSION}/share/affine/README
>  share/maxima/${VERSION}/share/affine/affine.lisp
> @@ -454,12 +465,12 @@ share/maxima/${VERSION}/share/algebra/re
>  share/maxima/${VERSION}/share/algebra/recur.transcript
>  share/maxima/${VERSION}/share/algebra/rtest_recur.mac
>  share/maxima/${VERSION}/share/algebra/solver/
> +share/maxima/${VERSION}/share/algebra/solver/Solver.mac
>  

Re: CVS: cvs.openbsd.org: ports

[Stuart Henderson]

> 2016-12-21 11:45 GMT+03:00 Jonathan Gray :
> > On Wed, Dec 21, 2016 at 12:43:57AM -0700, Peter Hessler wrote:
> >> CVSROOT:  /cvs
> >> Module name:  ports
> >> Changes by:   phess...@cvs.openbsd.org2016/12/21 00:43:57
> >>
> >> Modified files:
> >>   databases/postgresql: Makefile
> >>
> >> Log message:
> >> disable spinlocks on arm, so we can have a postgresql package
> >>
> >
> > Wouldn't it be better to depend on a newer gcc/clang to
> > get the atomic/sync builtins that base gcc on arm lacks?

If it works, then yes I think so.

On 2016/12/21 11:52, Vadim Zhukov wrote:
> Until we have working libc++ in base, the generic answer would be
> "please, no, if you can". Using egcc/clang forces the port binaries
> being linked to libestdc++, which in turn causes havoc in all
> dependant ports which are build with base compiler.

OpenBSD has been living with that for years, both with base gcc3/ports gcc4,
and then base gcc4.2/ports 4.9. It used to be very obvious before you hid
the _S_debug_messages symbol warnings ;)

If you use any of the usual gui web browsers on OpenBSD you are running code
with this kind of conflict.

Re: gcc4.9 and _Unwind_Resume segfaults

[Paul Irofti]

> I've added a patch to avoid picking up Qt5.

Your change is fine, thank you!

> But the first issue I see is enormous space eating, due to static
> libraries (?). I had to remove all port working directories to allow
> Octave to build, this didn't happen with 4.0 at all. It still builds.
> :-\

Yes, the space issue might be due to the debug flag.

$ du -sh octave-4.*
92.4M   octave-4.0.2
10.0G   octave-4.2.0 (with debug)

Have you tried buiding w/o debug symbols?

Re: CVS: cvs.openbsd.org: ports

[Peter Hessler]

On 2016 Dec 21 (Wed) at 12:51:44 +0300 (+0300), Vadim Zhukov wrote:
:2016-12-21 11:57 GMT+03:00 Jonathan Gray :
:> On Wed, Dec 21, 2016 at 11:52:50AM +0300, Vadim Zhukov wrote:
:>> 2016-12-21 11:45 GMT+03:00 Jonathan Gray :
:>> > On Wed, Dec 21, 2016 at 12:43:57AM -0700, Peter Hessler wrote:
:>> >> CVSROOT:  /cvs
:>> >> Module name:  ports
:>> >> Changes by:   phess...@cvs.openbsd.org2016/12/21 00:43:57
:>> >>
:>> >> Modified files:
:>> >>   databases/postgresql: Makefile
:>> >>
:>> >> Log message:
:>> >> disable spinlocks on arm, so we can have a postgresql package
:>> >>
:>> >
:>> > Wouldn't it be better to depend on a newer gcc/clang to
:>> > get the atomic/sync builtins that base gcc on arm lacks?
:>>
:>> Until we have working libc++ in base, the generic answer would be
:>> "please, no, if you can". Using egcc/clang forces the port binaries
:>> being linked to libestdc++, which in turn causes havoc in all
:>> dependant ports which are build with base compiler.
:>
:> postgres doesn't seem to use c++?
:
:Good point. :) Then let someone doing regular bulk builds speak, not
:me. Sorry for annoyance.
:

I simply copied the same logic used for hppa and alpha as a quick fix.

I'd be happy if armv7 switched to clang; but that will happen when it is
ready.


-- 
Misfortune, n.:
The kind of fortune that never misses.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: CVS: cvs.openbsd.org: ports

[Vadim Zhukov]

2016-12-21 11:57 GMT+03:00 Jonathan Gray :
> On Wed, Dec 21, 2016 at 11:52:50AM +0300, Vadim Zhukov wrote:
>> 2016-12-21 11:45 GMT+03:00 Jonathan Gray :
>> > On Wed, Dec 21, 2016 at 12:43:57AM -0700, Peter Hessler wrote:
>> >> CVSROOT:  /cvs
>> >> Module name:  ports
>> >> Changes by:   phess...@cvs.openbsd.org2016/12/21 00:43:57
>> >>
>> >> Modified files:
>> >>   databases/postgresql: Makefile
>> >>
>> >> Log message:
>> >> disable spinlocks on arm, so we can have a postgresql package
>> >>
>> >
>> > Wouldn't it be better to depend on a newer gcc/clang to
>> > get the atomic/sync builtins that base gcc on arm lacks?
>>
>> Until we have working libc++ in base, the generic answer would be
>> "please, no, if you can". Using egcc/clang forces the port binaries
>> being linked to libestdc++, which in turn causes havoc in all
>> dependant ports which are build with base compiler.
>
> postgres doesn't seem to use c++?

Good point. :) Then let someone doing regular bulk builds speak, not
me. Sorry for annoyance.

--
  WBR,
  Vadim Zhukov

CVS: cvs.openbsd.org: ports

[Jonathan Gray]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2016/12/21 02:27:57

Modified files:
devel/llvm : Makefile 
devel/llvm/patches: patch-tools_clang_lib_Basic_Targets_cpp 

Log message:
Recognise an OpenBSD aarch64 triple.  This enables some OpenBSD specific
builtin defines such as __OpenBSD__.  Same patch that patrick committed
to llvm in base.

ok patrick@

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2016/12/21 02:03:49

Modified files:
sysutils/awscli: Makefile distinfo 

Log message:
Update to awscli-1.11.32.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2016/12/21 02:03:13

Modified files:
net/py-boto3   : Makefile distinfo 

Log message:
Update to py-boto3-1.4.3.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2016/12/21 02:03:28

Modified files:
net/py-botocore: Makefile distinfo 

Log message:
Update to py-botocore-1.4.89.

Re: CVS: cvs.openbsd.org: ports

[Jonathan Gray]

On Wed, Dec 21, 2016 at 11:52:50AM +0300, Vadim Zhukov wrote:
> 2016-12-21 11:45 GMT+03:00 Jonathan Gray :
> > On Wed, Dec 21, 2016 at 12:43:57AM -0700, Peter Hessler wrote:
> >> CVSROOT:  /cvs
> >> Module name:  ports
> >> Changes by:   phess...@cvs.openbsd.org2016/12/21 00:43:57
> >>
> >> Modified files:
> >>   databases/postgresql: Makefile
> >>
> >> Log message:
> >> disable spinlocks on arm, so we can have a postgresql package
> >>
> >
> > Wouldn't it be better to depend on a newer gcc/clang to
> > get the atomic/sync builtins that base gcc on arm lacks?
> 
> Until we have working libc++ in base, the generic answer would be
> "please, no, if you can". Using egcc/clang forces the port binaries
> being linked to libestdc++, which in turn causes havoc in all
> dependant ports which are build with base compiler.

postgres doesn't seem to use c++?

Re: CVS: cvs.openbsd.org: ports

[Vadim Zhukov]

2016-12-21 11:45 GMT+03:00 Jonathan Gray :
> On Wed, Dec 21, 2016 at 12:43:57AM -0700, Peter Hessler wrote:
>> CVSROOT:  /cvs
>> Module name:  ports
>> Changes by:   phess...@cvs.openbsd.org2016/12/21 00:43:57
>>
>> Modified files:
>>   databases/postgresql: Makefile
>>
>> Log message:
>> disable spinlocks on arm, so we can have a postgresql package
>>
>
> Wouldn't it be better to depend on a newer gcc/clang to
> get the atomic/sync builtins that base gcc on arm lacks?

Until we have working libc++ in base, the generic answer would be
"please, no, if you can". Using egcc/clang forces the port binaries
being linked to libestdc++, which in turn causes havoc in all
dependant ports which are build with base compiler.

--
  WBR,
  Vadim Zhukov

Re: CVS: cvs.openbsd.org: ports

[Jonathan Gray]

On Wed, Dec 21, 2016 at 12:43:57AM -0700, Peter Hessler wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   phess...@cvs.openbsd.org2016/12/21 00:43:57
> 
> Modified files:
>   databases/postgresql: Makefile 
> 
> Log message:
> disable spinlocks on arm, so we can have a postgresql package
> 

Wouldn't it be better to depend on a newer gcc/clang to
get the atomic/sync builtins that base gcc on arm lacks?

Re: gcc4.9 and _Unwind_Resume segfaults

[Vadim Zhukov]

2016-12-21 0:24 GMT+03:00 Paul Irofti :
> On Tue, Dec 20, 2016 at 11:16:45PM +0200, Paul Irofti wrote:
>> > Given that math/octave uses libtool, the chances are that a libtool
>> > patch being tested right now will fix the issue. Or maybe not. :) You
>> > may give it a try anyway (attached).
>>
>> Thanks, but unfortunately it does not.
>>
>> I patched and installed libtool, anything else I should have done?
>
> I pushed the Octave port to openbsd-wip tree on github in case anyone
> else wants to look at this issue.
>
> https://github.com/jasperla/openbsd-wip/tree/master/math/octave

I've added a patch to avoid picking up Qt5.

But the first issue I see is enormous space eating, due to static
libraries (?). I had to remove all port working directories to allow
Octave to build, this didn't happen with 4.0 at all. It still builds.
:-\

--
  WBR,
  Vadim Zhukov