Buidsystem and libnsfb patches to enable building on Mac OS X 10.9.4 (Darwin13); confirmation of bug #2120 for netsurf-gtk compiled for Mac OS X

Hello, everyone,

This weekend I played with compiling netsurf-gtk for Mac OS X 10.9.4 with libraries supplied by MacPorts. Ultimately, I would like to create a Portfile (MacPorts package) of netsurf-gtk since as you know might know, the Carbon framework (on which netsurf-cocoa relies) has been deprecated since Mac OS X 10.8.

I followed the QUICKSTART compilation instructions, which mostly worked. The purpose of the attached patches is to ensure that they work completely.

buildsystem.patch solves the issue of toolchain detection on Mac OS X. The reported first line of cc --version is "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)", of which neither the first nor the second word are clang, which is what current toolchain autodetection does. The patch does autodetection of clang by looking for "clang" as a substring of the first line cc --version rather than as a first or second word.

libnsfb.patch solves the issue of endian.h being located in machine/endian.h. Currently, the two files 32bpp-xbgr8888.c and 32bpp-xgbr8888.c both include "endian.h" unless the platform is win32. The patch adds a futher check on whether the platform is Apple, in which case it includes machine/endian.h and defines the appropriate macros. Curiously, patches of this sort for nsfb were submitted three years ago by Sven Weidauer (http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-January/002300.html).

Now, I had to compile libparserutils without iconv because I guess the macports iconv library seems to break the compilation of netsurf_gtk (clang compalins about undefined symbols). Overall, compilation of the libraries is successful except for some self-defined warnings.

For compiling netsurf-gtk, in addition to installing the necessary libraries for macports (I use gtk2 with quartz support rather thatn X) I also had to edit the jsapi.c include from "js/jsapi.h" to "mozjs185/jsapi.h" because for some reason that's where the spidermonkey185 library is in MacPorts. Also, I added CFLAGS+=-D_DARWIN_C_SOURCE to make sure the compilation goes correctly (apparently Sven also had patches to make sure this is included automatically, for framebuffer at least). Since these are merely configuration and a quirk of MacPorts, I decided these did not need their own patches.

Anyway, I was able to compile netsurf-gtk with the above settings, but this led to strange compilation errors for files that aren't really really missing. I've attached the logs.

Also, the resulting binary runs, but realizes bug #2120, as well as a possibly new bug where the mouse cursor does not change on hover events.

All the best; let me know if you'd like more info from me.

--Vladimir Sotirov

Re: Memory still not being released

On 30/08/14 10:42, Steve Fryatt wrote:

> I think it's worth adding that the "many other apps [which] manage to
> release their DAs when documents are closed", referred to by Chris,
> are almost certainly using some kind of sliding block heap (such as
> the ubiquitous flexlib for C) to manage their memory heaps.

The memory allocation/freeing for decoded bitmaps (which are often some
of the bigger allocations NetSurf does), is handled by the front ends.
The core interface is in image/bitmap.h, and the front end should be
able to use a sliding block heap. The one fly in the ointment that I
can see is that the gif decoder, at least, needs to get at the bitmap
data buffer, through bitmap_get_buffer. I think that could be handled
though. Maybe it's worth looking at using a sliding heap for bitmaps on
RISC OS?

> The bottom line is that RISC OS needs to handle malloc()-controlled
> heaps properly: both UnixLib (and the Shared C Library, which has
> similar issues) need to use sparse DAs to release their free memory
> back to the system.

Indeed.


Cheers,

--
Michael Drake http://www.netsurf-browser.org/

Re: Memory still not being released

On 30 Aug, Michael Drake wrote in message
<54010C15.8040209@netsurf-browser.org>:

> So that's how NetSurf deals with memory. On RISC OS you have a further
> issue. NetSurf uses UnixLib, which implements the memory allocation stuff
> using DAs. If a DA contains contents 1, 2 and 3, and they sit in memory
> like this
>
> 111111222222222222222333333
>
> and NetSurf says it wants to free the allocation for 2, the area now looks
> like this
>
> 111111 333333
>
> The space between 1 and 3 is not used by NetSurf any more but on RISC OS,
> it isn't available for use by other apps. Next time NetSurf allocates
> some memory it might not be given the space between 1 and 3, but something
> beyond 3, causing the DA to gow.
>
> I think UnixLib can reduce the size of the DA, when the last 64 Kb (or
> something) is unused, but in practice that never happens.
>
> If UnixLib used sparse DAs, then the unused memory between what NetSurf's
> using would be available for other apps.

I think it's worth adding that the "many other apps [which] manage to
release their DAs when documents are closed", referred to by Chris, are
almost certainly using some kind of sliding block heap (such as the
ubiquitous flexlib for C) to manage their memory heaps.

Given the amount of different bits of data that NetSurf has to keep track
of, using flex would be near impossible due to the restrictions that it
imposes on an application. No copies can be taken of flex block pointers,
because they're not static: there was an interesting discussion on
csa.programmer recently about an obscure bug in Pluto which was apparently
caused by the simple act of taking a local copy of a flex pointer for use
within a single loop. Bugs resulting from this kind of thing can be near
impossible to reproduce and track down, due to the fact that the flex heap
can shift and invalidate copies of pointers at *any* time (even when memory
isn't being claimed from or freed back to the heap, in some set-ups).

>From what I've seen, NetSurf uses pointers to allocated blocks inside its DA
as 'handles' to refer to the stored objects: that's pretty standard practice
everywhere but on RISC OS. This isn't just a NetSurf issue: two other apps
that I have detailed knowledge of (CashBook and Locate) use flex, and their
memory handling is orders of magnitude more complex (and hence harder to
keep bug free, due to the potential for issues like the one found in Pluto)
than it would have been if I'd written them for a more sane operating
system. I wouldn't fancy converting NetSurf's memory handling to use flex
(if it were even an option: NetSurf runs on other platforms, so flex can't
be used).

The bottom line is that RISC OS needs to handle malloc()-controlled heaps
properly: both UnixLib (and the Shared C Library, which has similar issues)
need to use sparse DAs to release their free memory back to the system.

> Finally, I must say, please create bug reports for issues like this, with
> log files. If for example, we're leaking DOM trees right and left, it
> will be clear for the log data and we can fix it. Without hard
> information, we're only guessing.

Definitely. There could still be memory leaks in NetSurf (NetSurf itself can
re-use freed memory from within its DA, as long as there are big enough
blocks of contiguous free memory available there), so problems do need
investigating.

Proper bug reports, with full log files, are essential, however.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Re: Memory still not being released

On 29/08/14 23:05, cj wrote:

> I think this problem has been raised on a number of occasions,
> probably for more than a year. The comment that has come back is that
> RISC OS has appalling memory management routines and not much can be
> done. Many other apps manage to release their DAs when documents are
> closed.

Right, well there are a few things to note here.

NetSurf deliberately does not free memory for documents as soon as the
window is closed, or the page is navigated away from.

It keeps things around, because if they are needed again it is much
faster. For example, if we have a JPEG image or CSS file, and then move
to another page using the same resource later, it's a waste of time to
download it again, and parse/decode all the data once more.

So we would not expect to see memory usage drops to occur exactly in
time with windows/tabs closing, or pages being navigated away from.

However, memory for cached content[1] is freed and the user can control
how aggressively it is freed. There is a config option to set the size
of the memory cache. The way NetSurf works, iirc, is every 10 seconds
it checks to see if the amount of memory it has in use due to cached
content exceeds this limit. If it does exceed this limit, it will look
for any content that is currently unused in any open window and free it.
Note that if all current content across your windows/tabs require
content cache that exceeds the cache limit, it won't be able to free
things, or stuff would no longer be available to be shown in the windows.

(Actually image caching is handled specially. Once decoded, a JPEG,
image of a few hundred kilobytes can balloon to many megabytes. If the
memory usage is above the configured limit, NetSurf can free the decoded
version of the image, even if it's currently used on screen. After
that, if NetSurf needs to redraw the image, it has to decode it again
from the source data.)

So that's how NetSurf deals with memory. On RISC OS you have a further
issue. NetSurf uses UnixLib, which implements the memory allocation
stuff using DAs. If a DA contains contents 1, 2 and 3, and they sit in
memory like this

111111222222222222222333333

and NetSurf says it wants to free the allocation for 2, the area now
looks like this

111111 333333

The space between 1 and 3 is not used by NetSurf any more but on RISC
OS, it isn't available for use by other apps. Next time NetSurf
allocates some memory it might not be given the space between 1 and 3,
but something beyond 3, causing the DA to gow.

I think UnixLib can reduce the size of the DA, when the last 64 Kb (or
something) is unused, but in practice that never happens.

If UnixLib used sparse DAs, then the unused memory between what
NetSurf's using would be available for other apps.

Finally, I must say, please create bug reports for issues like this,
with log files. If for example, we're leaking DOM trees right and left,
it will be clear for the log data and we can fix it. Without hard
information, we're only guessing.

[1] By content, I mean any resource like an HTML file, CSS, Images, etc.

Cheers,
--
Michael Drake http://www.netsurf-browser.org/

Re: Memory still not being released

In article <5400C022.3000008@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> You say "persist" and "still"; is there some context for this that
> I am missing? Do we have a log files for such runs?

I think this problem has been raised on a number of occasions,
probably for more than a year. The comment that has come back is that
RISC OS has appalling memory management routines and not much can be
done. Many other apps manage to release their DAs when documents are
closed.

The problem seems to be release of memory. For example, I have just
run Netsurf, and looked at a couple of ROOL forum pages. Netsurf has
claimed three dynamic areas totalling 16 MB, the largest more than 12
MB. However, this memory usage is not released when the pages are
closed. When different pages are loaded the claimed memory
continually increases. On this machine (on 24/7) I used to get
regular crashes when one of Netsurfs dynamic areas reached ca. 131 MB
which is the maximum setting. I am now in the habit of regularly
quitting Netsurf so the DAs are released.

One can live with it.

--
Chris Johnson

Re: Memory still not being released

On 29/08/14 16:53, mail@JohnWoodhouse.plus.com wrote:

> the problem seems to persist

You say "persist" and "still"; is there some context for this that I am
missing? Do we have a log files for such runs?

If there isn't one for this already, please open a bug report[1] with
the relevant details and logs.

[1] http://bugs.netsurf-browser.org/

Cheers,

--
Michael Drake http://www.netsurf-browser.org/

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

On 29/08/14 13:02, Alan Buckley wrote:
>> Lee Noar wrote on Thursday, August 28, 2014 6:41 PM:
>
> On 18/08/14 08:44, alan buckley wrote:
>> > On Sat, 16 Aug 2014 14:25:24 +0100 Lee Noar wrote:
>> >
>> > On 15/08/14 14:59, Alan Buckley wrote:
>> > > I seem to be having a problem with programs not catching C++
>> exceptions
>> > > when compiled with GCCSDK 4.7.
>> >
> [snip]
>
>> Turned out to be a 26/32bit problem, hence why it works in RISC OS 5,
>> but not 4. The PSR bits were being interpreted as part of an address
>> when searching for exception handlers.
>
>> Should be fixed with r6737.
>
> It didn't seem to work for me. I may not have rebuilt it correctly though.
>
> I did:
> svn update
> deleted buildstepsdir/cross-gcc-built
> make
> ./install-env
>
> Is there anything else I should do?

I think you may also have to delete buildstepsdir/src-gcc-copied to
force the patches to be reapplied.
You don't usually need to do install-env if you've already got a
previous build, but you do need to 'make install' after make to copy
all the components to '~/gccsdk/cross'.

> I got new gcc and g++ files where I excepted them

The changed components are libstdc++ and libgcc. For statically built
programs, you'll have to relink with these libraries to benefit from
the fixes. For dynamically linked programs, the libstdc++ and libgcc
shared libraries should be copied to '!SharedLibs.lib.abi-2.0' on the
RISC OS side.

> and the output from the version commands was:

> ~/gccsdk/cross/bin/arm-unknown-riscos-g++ --version
> arm-unknown-riscos-g++ (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4
> 20140527 (
> prerelease) [gcc-4_7-branch revision 210956]
> Copyright (C) 2012 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I was going to say that I would expect to see a more recent date than
20140527, but having tried the same here, I don't get a date at all.
Even so, I think you're still looking at the old versions here;
'make install' should fix that.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Memory still not being released

I have been using NS 3.0 for the most part, but having tried with 3.1 and
now the latest available 3.3 (Dev CI #2070), the problem seems to persist:

Using VARPC, memory is limited - the most I can use is around 102Mb. and
running Netsurf initially knocks that back to c. 94Mb with a Google default
page. If I now click on e.g. the Youtube link it drops to c. 81mb. Fair
enough, but if I now re-load the same page the available memory drops
around 9Mb each time until it reaches about 62Mb - on one occasion it
droped to 39Mb but this seems to vary. This means that I have to keep a
wary eye on memory available to avoid VARPC crashing if I start using
heavier applications.

Quitting from Netsurf releases the used memory, but is there any other way
of preventing this?

John

P.S. Having just tried the above procedure using the latest download
(#2070), it seems to be even worse: available memory dropped to 30Mb.

--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

> Lee Noar wrote on Thursday, August 28, 2014 6:41 PM:

On 18/08/14 08:44, alan buckley wrote:
> > On Sat, 16 Aug 2014 14:25:24 +0100 Lee Noar wrote:
> >
> > On 15/08/14 14:59, Alan Buckley wrote:
> > > I seem to be having a problem with programs not catching C++
> exceptions
> > > when compiled with GCCSDK 4.7.
> >
[snip]

> Turned out to be a 26/32bit problem, hence why it works in RISC OS 5,
> but not 4. The PSR bits were being interpreted as part of an address
> when searching for exception handlers.

> Should be fixed with r6737.

It didn't seem to work for me. I may not have rebuilt it correctly though.

I did:
svn update
deleted buildstepsdir/cross-gcc-built
make
./install-env

Is there anything else I should do?

I got new gcc and g++ files where I excepted them and the output from
the version commands was:

~/gccsdk/cross/bin/arm-unknown-riscos-g++ --version
arm-unknown-riscos-g++ (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4
20140527 (
prerelease) [gcc-4_7-branch revision 210956]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/gccsdk/cross/bin/arm-unknown-riscos-gcc --version
arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4
20140527 (
prerelease) [gcc-4_7-branch revision 210956]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Regards,
Alan


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

On 18/08/14 08:44, alan buckley wrote:
> > On Sat, 16 Aug 2014 14:25:24 +0100 Lee Noar wrote:
> >
> > On 15/08/14 14:59, Alan Buckley wrote:
> > > I seem to be having a problem with programs not catching C++ exceptions
> > > when compiled with GCCSDK 4.7.
> >
> > [snip]
> >
> > > Can anyone else confirm this isn't working?
> >
> > I can't reproduce this. I've tried both the cross compiler and the
> > native compiler running in RPCEmu which I also use to run the result.
> >
> > It looks like the same thing that Duncan reported in bug#256 (which I
> > can't reproduce either).
> >
> > Are you running in VirtualRPC by any chance?
> >
>
> I'm running on RPCEmu (the latest release) with RISC OS 4.02 (from the
> nearly
> free product from ROL) with the Castle 32 bit System installed.

Turned out to be a 26/32bit problem, hence why it works in RISC OS 5,
but not 4. The PSR bits were being interpreted as part of an address
when searching for exception handlers.

Should be fixed with r6737.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: Boxconvert

On Thu, 21 Aug 2014 23:12:19 +0100, Richard Porter wrote:

> I got a warning from NetSurf - Boxconvert
>
> What is "boxconvert"?

It means NetSurf hasn't been able to parse an HTML "box" (I'm not
entirely sure what the definion of a "box" is). I suspect the plain
English version of this error has somehow gone missing.

Can you consistently create the error on a particular page? Do you
have a log file?

Chris

Boxconvert

I got a warning from NetSurf - Boxconvert

What is "boxconvert"?

--
Richard Porter http://www.minijem.plus.com/
Skype: minijem2 mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.

AmigaOS 4.1 under emulation

This is not strictly NetSurf related but I wanted to make a note of it
here in case it is useful for development/testing/debugging of NetSurf
Amiga version.

Thee are some easy steps here on how to set up OS4.1 Classic on the
new beta of WinUAE:
http://classicamiga.blogspot.com.au/2014/08/amigaos41-classic-on-winuae-part-1.html

It needs a (legal) image of the OS4.1 Classic CD and a (legal) 3.1 ROM
image (I think the OS4.1 CD has one of these on it these days).

I've not tried it myself as (a) my PC is currently broken and (b) I
don't have the "classic" version of OS4.1.

Chris

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

On 18/08/14 08:44, alan buckley wrote:
> > On Sat, 16 Aug 2014 14:25:24 +0100 Lee Noar wrote:
> >
> > On 15/08/14 14:59, Alan Buckley wrote:
> > > I seem to be having a problem with programs not catching C++ exceptions
> > > when compiled with GCCSDK 4.7.
> >
> > [snip]
> >
> > > Can anyone else confirm this isn't working?
> >
> > I can't reproduce this. I've tried both the cross compiler and the
> > native compiler running in RPCEmu which I also use to run the result.
> >
> > It looks like the same thing that Duncan reported in bug#256 (which I
> > can't reproduce either).
> >
> > Are you running in VirtualRPC by any chance?
> >
>
> I'm running on RPCEmu (the latest release) with RISC OS 4.02 (from the
> nearly
> free product from ROL) with the Castle 32 bit System installed.

Ok, I can now reproduce this and bug#256. It's seems that they work
fine on RISC OS 5 (which is what I normally test on), but not on RISC
4.02 (which is what I've just tried) or RISC OS 4.39 (which is what
Duncan is using).
Now that I can see what you see, I can start digging.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

3.2 Release

We have made some significant cleanups and feature improvements to the
master branch since the 3.1 release including a significant number of
fixes for crash causing problems.

As there are currently no large feature merges outstanding and Daniel
and myself triaged and fixed numerous bugs recently this seems like a
suitable time to create a 3.2 release.

As this is principally a bug fix release and the only user visible
change is the persistent object cache I see no reason for an extended
test period. I will be making the release by the end of the month,
probably Saturday 23rd.

The 3.2 roadmap on the issue tracker [1] only shows two issues tagged
for this release one of which I intend to address immediately, the
other may get ignored if nobody addresses it.

I would like to raise the issue that the RISC OS frontend has received
minimal bug fixing this release cycle as Steve Fryatt has been unable
to dedicate much time recently. There are over twenty RISC OS specific
issues outstanding and I would be delighted if someone could provide
fixes for any of these.


[1] http://bugs.netsurf-browser.org/mantis/roadmap_page.php

--
Regards Vincent
http://www.kyllikki.org/

libhubbub: allow build with json-c 0.12

>From 13bd4b9cc2e311b43f49b0e6f002dc738a779cb9 Mon Sep 17 00:00:00 2001
From: David Tardon <dtardon@redhat.com>
Date: Mon, 18 Aug 2014 12:46:44 +0200
Subject: [PATCH] allow build with json-c 0.12

The library, the include dir and the .pc file were renamed from json to
json-c a few releases ago, but the old names were kept for backwards
compatibility. They were finally removed in version 0.12.
---
Makefile | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 4ec03f3..afbbe46 100644
--- a/Makefile
+++ b/Makefile
@@ -46,13 +46,23 @@ include $(NSBUILD)/Makefile.top
ifeq ($(WANT_TEST),yes)
# We require the presence of libjson -- http://oss.metaparadigm.com/json-c/
ifneq ($(PKGCONFIG),)
+ # The pkgconfig file name has changed from json.pc to json-c.pc
+ JSONC_CFLAGS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --cflags json-c)
+ JSONC_LIBS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --libs json-c)
+ JSON_CFLAGS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --cflags json)
+ JSON_LIBS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --libs json)
TESTCFLAGS := $(TESTCFLAGS) \
- $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --cflags json)
+ $(if $(strip $(JSONC_CFLAGS)),$(JSONC_CFLAGS),$(JSON_CFLAGS))
TESTLDFLAGS := $(TESTLDFLAGS) \
- $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --libs json)
+ $(if $(strip $(JSONC_LIBS)),$(JSONC_LIBS),$(JSON_LIBS))
else
- TESTCFLAGS := $(TESTCFLAGS) -I$(PREFIX)/include/json
- TESTLDFLAGS := $(TESTLDFLAGS) -ljson
+ ifeq ($(wildcard $(PREFIX)/include/json-c/json.h),)
+ TESTCFLAGS := $(TESTCFLAGS) -I$(PREFIX)/include/json
+ TESTLDFLAGS := $(TESTLDFLAGS) -ljson
+ else
+ TESTCFLAGS := $(TESTCFLAGS) -I$(PREFIX)/include/json-c
+ TESTLDFLAGS := $(TESTLDFLAGS) -ljson-c
+ endif
endif

ifneq ($(GCCVER),2)
--
1.9.3

Hi,

the attached patch fixes ${SUBJECT}.

D.

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

> On Sat, 16 Aug 2014 14:25:24 +0100 Lee Noar wrote:
>
> On 15/08/14 14:59, Alan Buckley wrote:
> > I seem to be having a problem with programs not catching C++ exceptions
> > when compiled with GCCSDK 4.7.
>
> [snip]
>
> > Can anyone else confirm this isn't working?
>
> I can't reproduce this. I've tried both the cross compiler and the
> native compiler running in RPCEmu which I also use to run the result.
>
> It looks like the same thing that Duncan reported in bug#256 (which I
> can't reproduce either).
>
> Are you running in VirtualRPC by any chance?
> 

I'm running on RPCEmu (the latest release) with RISC OS 4.02 (from the nearly

free product from ROL) with the Castle 32 bit System installed.

Regards,

Alan

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

On 15/08/14 14:59, Alan Buckley wrote:
> I seem to be having a problem with programs not catching C++ exceptions
> when compiled with GCCSDK 4.7.

[snip]

> Can anyone else confirm this isn't working?

I can't reproduce this. I've tried both the cross compiler and the
native compiler running in RPCEmu which I also use to run the result.

It looks like the same thing that Duncan reported in bug#256 (which I
can't reproduce either).

Are you running in VirtualRPC by any chance?

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] C++ exceptions not working with GCCSDK 4.7

I seem to be having a problem with programs not catching C++ exceptions

when compiled with GCCSDK 4.7.

Full version:

(GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140527 (

prerelease) [gcc-4_7-branch revision 210956]

 

The following simple program (main.cc) will crash rather than catch

the exception as expected.

 

#include <iostream>

#include <stdexcept>

 

int main(int argc, char *argv[])

{

    try

    {

        std::cout << "Before throw" << std::endl;

        throw std::runtime_error("Test throw and catch");

    } catch(...)

    {

        std::cout << "Caught thrown exception as expected\n" << std::endl;

    }

    std::cout << "After try/catch block" << std::endl;

}

 

I'm compiling it using the following makefile.

 

# Makefile for exceptcrash

 

SRC=main.cc

CXX=~/gccsdk/cross/bin/arm-unknown-riscos-g++

CXXFLAGS= -O2 -mthrowback

TARGET=exceptnotcaught

 

 

all:    $(TARGET)

 

$(TARGET):    $(SRC:.cc=.o)

    $(CXX)  -static $(SRC:.cc=.o) -o $(TARGET)ELF,e1f

    ~/gccsdk/cross/bin/elf2aif $(TARGET)ELF,e1f $(TARGET),ff8

 

 

The ELF version crashes as well at the aif version.

 

The output from the program is:

 

Before throw

terminate called after throwing an instance of 'std::runtime_error'

terminate called recursively

 

Fatal signal received: Aborted

 

Stack backtrace:

 

Running thread 0x84968

  (  c56e84) pc:    6c774 lr:    6cc18 sp:   c56e88  __write_backtrace()

  (  c56ef4) pc:    6c890 lr:    6cf7c sp:   c56ef8  __unixlib_raise_signal()

  (  c56f04) pc:    6cf60 lr:    536cc sp:   c56f08  raise()

  (  c56f18) pc:    53690 lr:    3d1e4 sp:   c56f1c  abort()

  (  c56f38) pc:    3d118 lr:    34b08 sp:   c56f3c  __gnu_cxx::__verbose_terminate_handler()()

  (  c56f48) pc:    34afc lr:    34b60 sp:   c56f4c  __cxxabiv1::__terminate(void (*)())()

  (  c56f8c) pc:    3d114 lr:    34b08 sp:   c56f90  __gnu_cxx::__verbose_terminate_handler()()

  (  c56f9c) pc:    34af8 lr:    34b60 sp:   c56fa0  __cxxabiv1::__terminate(void (*)())()

  (  c56fec) pc:     84f0 lr:    5828c sp:   c56ff0  main()

 

 

Can anyone else confirm this isn't working?

 

Regards,

Alan

 

[gccsdk] New riscos.info directions and prospective disruption

As some of you may have noticed, riscos.info has been suffering some
unreliability problems: usually what happens is that SpamAssassin causes it
to exhaust its memory and become wedged.

I've recently taken over administration of riscos.info from Peter Naulls,
and my first job is to fix this. As part of this process I also intend to
move hosts, as part of a longer-term plan to partition services over
different servers so this becomes less of an issue.

I intend to do most of this work in the background, but it will entail a
certain amount of disruption so various databases (SVN, wiki etc) are kept
consistent. Due to limited time on my part, I may have to schedule some
downtime at relatively short notice.

I'm intending to start this process this weekend, and riscos.info should be
assumed to be vulnerable over that period. There's currently no external
server status page, but I'll update:
http://www.markettos.org.uk/riscos.info/
as I go.

If there's any problems, do email me.
(This mailing list may not work during disruption, for obvious reasons)

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Pthreads barrier

In message <53DF700A.9060506@mesham.com>
Nick Brown <nick@mesham.com> wrote:

> I'm trying to compile a Linux code which uses pthreads, it all seems
> fine apart from not being able to find barrier support (
> pthread_barrier_t and associated functions.) I've had a look in the
> pthreads.h include file that ships with the RISC OS version of GCC and
> it seems like barriers are missing from it. I can work around this by
> implementing my own barrier in the code but before I do this, to avoid
> any duplication, was wondering if it has been implemented and is just
> somewhere else?

I'm not aware of pthread barrier support in UnixLib. Awaiting
contributions ;-)

John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] Pthreads barrier

Hi all,

I'm trying to compile a Linux code which uses pthreads, it all seems
fine apart from not being able to find barrier support (
pthread_barrier_t and associated functions.) I've had a look in the
pthreads.h include file that ships with the RISC OS version of GCC and
it seems like barriers are missing from it. I can work around this by
implementing my own barrier in the code but before I do this, to avoid
any duplication, was wondering if it has been implemented and is just
somewhere else?

Cheers,
Nick

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK