Re: gcc4.9 and _Unwind_Resume segfaults

[Vadim Zhukov]

2016-12-23 10:56 GMT+03:00 Paul Irofti :
> On Thu, Dec 22, 2016 at 09:49:08AM +0300, Vadim Zhukov wrote:
>> 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...
>
> Well?

Yes, now libtool patch works fine.

There comes another problem: components are C, not C++, but now they
get -lestdc++ explicitly, the resulting binary breaks badly for me.

I'll try to construct a hammer solution in post-configure...

--
  WBR,
  Vadim Zhukov

Re: gcc4.9 and _Unwind_Resume segfaults

[Paul Irofti]

On Thu, Dec 22, 2016 at 09:49:08AM +0300, Vadim Zhukov wrote:
> 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...

Well?

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

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: 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: 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: 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

Re: gcc4.9 and _Unwind_Resume segfaults

[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

Re: gcc4.9 and _Unwind_Resume segfaults

[Paul Irofti]

> 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?

Re: gcc4.9 and _Unwind_Resume segfaults

[Vadim Zhukov]

2016-12-20 15:01 GMT+03:00 Pascal Stumpf :
> On Tue, 20 Dec 2016 12:33:47 +0200, Paul Irofti wrote:
>> Hi,
>>
>> The new Octave version requires a modern C++ compiler and so I switched
>> to gcc 4.9. All compiles and seems to be running fine until an exception
>> is raised, then the program faults.
>>
>> This seems to happen on all errors, not just Octave specific errors.
>> Could this be something we are doing wrong? I have no idea where to
>> start with investigating this issue.
>>
>> Here is a detailed report on the Octave bugtracker
>>
>>https://savannah.gnu.org/bugs/index.php?49859
>>
>> any thoughts? Pointers?
>
> I know nothing about Octave, but the issue seems to be that it links to
> libgcc from base instead of the 4.9 port.

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).

--
  WBR,
  Vadim Zhukov
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 shouldn't affect bulk build itself.

I've tested this patch with a partial bulk build, and got no
regressions. But I've skipped many CPU hogs like webkit and libreoffice,
and even those that don't use libtool themselves could be a dependency
for autoconf/libtool-based stuff.

--
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);

Re: gcc4.9 and _Unwind_Resume segfaults

[Pascal Stumpf]

On Tue, 20 Dec 2016 12:33:47 +0200, Paul Irofti wrote:
> Hi,
> 
> The new Octave version requires a modern C++ compiler and so I switched
> to gcc 4.9. All compiles and seems to be running fine until an exception
> is raised, then the program faults.
> 
> This seems to happen on all errors, not just Octave specific errors.
> Could this be something we are doing wrong? I have no idea where to
> start with investigating this issue.
> 
> Here is a detailed report on the Octave bugtracker
> 
>https://savannah.gnu.org/bugs/index.php?49859
> 
> any thoughts? Pointers?

I know nothing about Octave, but the issue seems to be that it links to
libgcc from base instead of the 4.9 port.

> Thanks,
> Paul

gcc4.9 and _Unwind_Resume segfaults

[Paul Irofti]

Hi,

The new Octave version requires a modern C++ compiler and so I switched
to gcc 4.9. All compiles and seems to be running fine until an exception
is raised, then the program faults.

This seems to happen on all errors, not just Octave specific errors.
Could this be something we are doing wrong? I have no idea where to
start with investigating this issue.

Here is a detailed report on the Octave bugtracker

   https://savannah.gnu.org/bugs/index.php?49859

any thoughts? Pointers?

Thanks,
Paul