Re: [gccsdk] GCC on RISC OS hanging

On 29/03/2021 18:57, alan buckley wrote:
> I�ve been trying to build my packit code on RISC OS 5.24 on RPCEmu. It
> just seems to hang. Occasionally the screen get�s corrupted or an error
> box (that I can�t see properly or read) appears. I�ve no idea what is
> causing this and I�ve not been able to eliminate anything to narrow it down.
>
> Smaller programs seem to compile OK.
>
> Any suggestion on what may be going wrong?

Is this in a taskwindow? If you attempt it from a single tasking command
line, does that give you a more useful error?
Are you using make, perhaps for your project, but calling GCC directly
for smaller programs; could it be make at fault rather than GCC?

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] GCC on RISC OS hanging

I've been trying to build my packit code on RISC OS 5.24 on RPCEmu. It just seems to hang. Occasionally the screen get's corrupted or an error box (that I can't see properly or read) appears. I've no idea what is causing this and I've not been able to eliminate anything to narrow it down.

 

Smaller programs seem to compile OK.

 

Any suggestion on what may be going wrong?

 

Regards,

Alan

 

Mailto:

Not sure when it dates from, but some time ago Netsurf stopped handling a
mailto: responses properly.

For example I have a perl contact program which can return a mailto:
address. This does not get passed on. Try

http://www.torrens.org/cgi-bin/Contact.cgi?Contact=Contact&CheckVar=Netsf


This on ARMX6 5.27 (08-Jun-20)

I tried the bug tracker but there seem to be no instructions as to how to
use it.

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: possible bug: libnsgif does not handle successive RESTORE frames correctly

Hi John,

Thanks for investigating and for the patch. It looks good!
I've applied it and its on master now.

Thanks again,

Michael


On 07/03/2021 14:39, jcupitt@gmail.com wrote:
> Here's a possible patch:
>
> https://github.com/libvips/libvips/commit/bf522eeffc5aa84a275b1d53e24d0daace59fa3e
>
>
> On Sun, 7 Mar 2021 at 14:31, <jcupitt@gmail.com> wrote:
>>
>> Hello again everyone,
>>
>> I think I have a GIF which libnsgif does not handle correctly:
>>
>> https://github.com/libvips/libvips/blob/master/test/test-suite/images/dispose-previous.gif
>>
>> This GIF has three frames which draw three concentric red circles. The
>> GIF does this:
>>
>> - clear frame
>> frame 0:
>> - disposal_method COMBINE
>> - draw outermost red circle
>> frame 1:
>> - disposal_method RESTORE
>> - draw middle red circle
>> frame 2:
>> - disposal_method RESTORE
>> - draw inner red circle
>>
>> So the viewer should see this:
>>
>> https://github.com/libvips/libvips/blob/master/test/test-suite/images/dispose-previous.png
>>
>> frame 0:
>> - outer circle
>> frame 1:
>> - outer + middle
>> frame 2:
>> - outer + inner
>>
>> However, if you view with libnsgif, you'll see frame 2 has all three
>> circles, ie. the middle frame is not removed.
>>
>> Looking at the code, the problem seems to be that
>> gif_internal_decode_frame() calls gif__record_previous_frame() before
>> it calls gif__recover_previous_frame(). This means that if you have
>> two frames with RESTORE dispose in a row, the second restore will be
>> missed, since it will save the frame (overwriting the restore) before
>> it tries to restore it.
>>
>> The simplest fix is probably to simply move the record handler to just
>> after the recover. I think this makes intuitive sense -- you want to
>> finish disposing of the previous frame before you record the current
>> state.
>>
>> John
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
>

--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: possible bug: libnsgif does not handle successive RESTORE frames correctly

On Sun, Mar 07, 2021 at 02:39:42PM +0000, jcupitt@gmail.com wrote:
> Here's a possible patch:
>
> https://github.com/libvips/libvips/commit/bf522eeffc5aa84a275b1d53e24d0daace59fa3e

Hi John,

I'm not sure your original mail made it through to the list - I
certainly didn't receive it. So sorry if you've been trying to discuss
this with us at length with no response! Hopefully somebody can take a
look at your proposed patch in the week, but your explanation sounds
obviously correct.

B.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: possible bug: libnsgif does not handle successive RESTORE frames correctly

Here's a possible patch:

https://github.com/libvips/libvips/commit/bf522eeffc5aa84a275b1d53e24d0daace59fa3e


On Sun, 7 Mar 2021 at 14:31, <jcupitt@gmail.com> wrote:
>
> Hello again everyone,
>
> I think I have a GIF which libnsgif does not handle correctly:
>
> https://github.com/libvips/libvips/blob/master/test/test-suite/images/dispose-previous.gif
>
> This GIF has three frames which draw three concentric red circles. The
> GIF does this:
>
> - clear frame
> frame 0:
> - disposal_method COMBINE
> - draw outermost red circle
> frame 1:
> - disposal_method RESTORE
> - draw middle red circle
> frame 2:
> - disposal_method RESTORE
> - draw inner red circle
>
> So the viewer should see this:
>
> https://github.com/libvips/libvips/blob/master/test/test-suite/images/dispose-previous.png
>
> frame 0:
> - outer circle
> frame 1:
> - outer + middle
> frame 2:
> - outer + inner
>
> However, if you view with libnsgif, you'll see frame 2 has all three
> circles, ie. the middle frame is not removed.
>
> Looking at the code, the problem seems to be that
> gif_internal_decode_frame() calls gif__record_previous_frame() before
> it calls gif__recover_previous_frame(). This means that if you have
> two frames with RESTORE dispose in a row, the second restore will be
> missed, since it will save the frame (overwriting the restore) before
> it tries to restore it.
>
> The simplest fix is probably to simply move the record handler to just
> after the recover. I think this makes intuitive sense -- you want to
> finish disposing of the previous frame before you record the current
> state.
>
> John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

possible bug: libnsgif does not handle successive RESTORE frames correctly

Hello again everyone,

I think I have a GIF which libnsgif does not handle correctly:

https://github.com/libvips/libvips/blob/master/test/test-suite/images/dispose-previous.gif

This GIF has three frames which draw three concentric red circles. The
GIF does this:

- clear frame
frame 0:
- disposal_method COMBINE
- draw outermost red circle
frame 1:
- disposal_method RESTORE
- draw middle red circle
frame 2:
- disposal_method RESTORE
- draw inner red circle

So the viewer should see this:

https://github.com/libvips/libvips/blob/master/test/test-suite/images/dispose-previous.png

frame 0:
- outer circle
frame 1:
- outer + middle
frame 2:
- outer + inner

However, if you view with libnsgif, you'll see frame 2 has all three
circles, ie. the middle frame is not removed.

Looking at the code, the problem seems to be that
gif_internal_decode_frame() calls gif__record_previous_frame() before
it calls gif__recover_previous_frame(). This means that if you have
two frames with RESTORE dispose in a row, the second restore will be
missed, since it will save the frame (overwriting the restore) before
it tries to restore it.

The simplest fix is probably to simply move the record handler to just
after the recover. I think this makes intuitive sense -- you want to
finish disposing of the previous frame before you record the current
state.

John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [gccsdk] GCC8+ what new environment check is needed for packages

On 04/03/2021 08:38, Rob Kendrick wrote:
> On Wed, Mar 03, 2021 at 07:31:51PM +0000, Lee Noar wrote:
>> If I'm understanding you correctly, then GCC8 and later should work on
>> anything with VFP, so a VFP check should be OK, however, the libraries
>> are not compatible with GCC4. The libraries for GCC8/10 are stored in
>> !SharedLibs.lib.armeabi, so armeabi would be the name of environment?
>> Main Page: http://www.riscos.info/index.php/GCCSDK
>
> If code generated by the new GCC depends on VFP, where does that leave
> people using RPCemu/VirtualRPC for their day-to-day use?

Unfortunately, FPA support was removed from GCC some time ago, so we
don't even have it as an option. Soft-float should still work, but
I haven't tried it. It would require an additional shared library ABI
and the ability for the dynamic linker to detect it and load the correct
libraries (the ELF header probably has a flag for this).

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: [gccsdk] GCC8+ what new environment check is needed for packages

In article <20210304135646.62fb3pimrtgdigqv@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:

> I think there would definitely be some mileage in writing suitable RISC OS
> drivers for QEMU - eg VirtIO - which would make it more hypervisor friendly.
> That would lift the limitations of the RPC hardware, although I don't know
> how friendly the UI is on platforms that QEMU supports (virt-manager is OK
> for KVM under Linux, not sure about Mac/Windows).

I don't know if it make is closer to get RISC OS running with QEMU. Recent
versions (5.2) have DWCDriver support for Rpi 2 (armv7) emulation. So USB
network and keyboards work with Raspberry Pi OS.

There's also RISC OS Linux. The VFPSupport module isn't supported yet but
it is possible to get VFP compiled programs to run by modifying the
SharedUnixLibrary module not to call VFPSupport.


_______________________________________________
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] GCC8+ what new environment check is needed for packages

On 04/03/2021 08:18, alan buckley wrote:
> Chris Gransden <mailto:chrisg@care4free.net> wrote on**03 March 2021 22:49
>
> > In article <88c19afa-7904-b93e-190c-2bcebaa3feb6@sky.com>,
> >�� Lee Noar <lee.noar@sky.com> wrote:
> > > If I'm understanding you correctly, then GCC8 and later should work on
> > > anything with VFP, so a VFP check should be OK, however, the libraries
> > > are not compatible with GCC4. The libraries for GCC8/10 are stored in
> > > !SharedLibs.lib.armeabi, so armeabi would be the name of environment?
>
> The environment is for the hardware it runs on, not the software itself.
> So if the vfp check is ok (but see below) that would be sufficient.
>
> Are the GCC8/10 linked to different numbered version of the shared C
> libraries?

Only the C++ library has a different version number, so we'll probably
have to tack on "armeabihf" to the package names to distinguish them.

> If this is the case, then we just need packages with different names for
> each.
>
> If it is just the case they need armeabi versions of the existing
> versions, I�d probably create a package with the correct versions in
and make anything
> that needs them depend on that package. If we need the stuff from the current
> shared libraries then these new shared library packages can depend on
> those.

Yes, the GCC10 !SharedLibs is designed to be copied over the GCC4
!SharedLibs, the result can then be used to run GCC4 and GCC10 code.
It should also depend an ARMEABISupport.

> > > For dynamic linking, it would require the runtime shared libraries to
> > > be packaged. Such a package is produced with the GCC10 build for
> > > copying over the package produced by the GCC4 build, although
> should the
> > > C++ libraries be in a separate package?
>
> Yes, I think it should really though it�s not critical. It sounds like
> the GCC10 package is already there.

Yes, I just need to split off the C++ library into a separate package.

>
> > I just tried a simple Hello World program built by gcc 10.2 and it
> gave an
> > abort when run on a RPi 1B. Pi 1 is armv6 and vfp2.
> > If I do gcc -v it shows armv7 and vfpv3 as defaults.
>
> Chris mentioned this to me, which is one of the reasons I asked the question
> about the environment.

Yes, sorry, Chris is right, I remember now discussing this with Andrew
Rawnsley when trying to determine which platforms Iris should
work on. So, yes, you would have to check for vfpv3.

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: [gccsdk] GCC8+ what new environment check is needed for packages

On Thu, Mar 04, 2021 at 12:26:47PM +0000, Chris Johns wrote:
> On 04/03/2021 08:38, Rob Kendrick wrote:
>
> >I don't think RPCemu provides any VFP, and I don't recall there being a
> >VFPEmulator module - but I admit to not looking for in a decade.
>
> I have before idly wondered if RPCEmu could be extended to handle
> VFP, either via a VFPEmulator module or even by emulating some sort
> of "StrongARM with VFP" processor.

The Howkins brothers tend to try to avoid adding non-RPC-related
hardware emulation to devices, prefering to emulate real hardware unless
there is a strong reason not to. Plus, a VFPEmulator would be useful on
older real hardware as well as VirtualRPC.

> I do wonder if trying to support
> a 20+ year old platform just so that people can emulate it is all
> that sensible.

I don't disagree, but I imagine a significant proportion of users do use
emulated systems. There's a bootstrap issue here: it may be better to
provide some measure of support for old and new, at least for a while,
before removing support for the old.

> >Perhaps it might be time to try porting RISC OS to a qemu target so we
> >can just plug in modern CPUs as they come along and use KVM on native
> >ARM hardware.
>
> I think people have got it running under Qemu in the past, but I
> seem to recall it was as modified version (of QEmu).

Yeah, ideally RISC OS should be modified to work with unmodified Qemu
(VirtIO or Versatile-type.) I suppose targeting real hardware is more
interesting for those with knowledge and willpower to work on the RISC
OS internals!

B.

_______________________________________________
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] GCC8+ what new environment check is needed for packages

On Thu, Mar 04, 2021 at 12:26:47PM +0000, Chris Johns wrote:
> On 04/03/2021 08:38, Rob Kendrick wrote:
>
> > I don't think RPCemu provides any VFP, and I don't recall there being a
> > VFPEmulator module - but I admit to not looking for in a decade.
>
> I have before idly wondered if RPCEmu could be extended to handle VFP,
> either via a VFPEmulator module or even by emulating some sort of "StrongARM
> with VFP" processor. I do wonder if trying to support a 20+ year old
> platform just so that people can emulate it is all that sensible.

That isn't a bad idea, although it would cause divergence away from the
actual Risc PC hardware. You would still be limited by the RPC
architectural limitations (256MB memory etc) so it's questionable how much
it would gain you.

> > Perhaps it might be time to try porting RISC OS to a qemu target so we
> > can just plug in modern CPUs as they come along and use KVM on native
> > ARM hardware.
>
> I think people have got it running under Qemu in the past, but I seem to
> recall it was as modified version (of QEmu).

https://github.com/slp/qemu-riscos/commits/master
seems to suggest they modified QEMU to implement the Raspberry Pi hardware
enough to support vanilla RISC OS Pi images, rather than modifying RISC OS.

I think there would definitely be some mileage in writing suitable RISC OS
drivers for QEMU - eg VirtIO - which would make it more hypervisor friendly.
That would lift the limitations of the RPC hardware, although I don't know
how friendly the UI is on platforms that QEMU supports (virt-manager is OK
for KVM under Linux, not sure about Mac/Windows).

Theo

(For completeness I should also mention:
https://www.riscos.info/index.php/QEMU
which is QEMU with unfinished 26-bit mode support - not really usable)

_______________________________________________
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] GCC8+ what new environment check is needed for packages

On 04/03/2021 08:38, Rob Kendrick wrote:

> I don't think RPCemu provides any VFP, and I don't recall there being a
> VFPEmulator module - but I admit to not looking for in a decade.

I have before idly wondered if RPCEmu could be extended to handle VFP,
either via a VFPEmulator module or even by emulating some sort of
"StrongARM with VFP" processor. I do wonder if trying to support a 20+
year old platform just so that people can emulate it is all that sensible.

> Perhaps it might be time to try porting RISC OS to a qemu target so we
> can just plug in modern CPUs as they come along and use KVM on native
> ARM hardware.

I think people have got it running under Qemu in the past, but I seem to
recall it was as modified version (of QEmu).

Cheers

Chris


_______________________________________________
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] GCC8+ what new environment check is needed for packages

On Wed, Mar 03, 2021 at 07:31:51PM +0000, Lee Noar wrote:
> If I'm understanding you correctly, then GCC8 and later should work on
> anything with VFP, so a VFP check should be OK, however, the libraries
> are not compatible with GCC4. The libraries for GCC8/10 are stored in
> !SharedLibs.lib.armeabi, so armeabi would be the name of environment?
> Main Page: http://www.riscos.info/index.php/GCCSDK

If code generated by the new GCC depends on VFP, where does that leave
people using RPCemu/VirtualRPC for their day-to-day use? I run GCCSDK
under Linux and test on RPCemu on the same machine. I've not had a
native RISC OS machine since I left Simtec a decade ago.

I don't think RPCemu provides any VFP, and I don't recall there being a
VFPEmulator module - but I admit to not looking for in a decade.

Perhaps it might be time to try porting RISC OS to a qemu target so we
can just plug in modern CPUs as they come along and use KVM on native
ARM hardware.

B.

_______________________________________________
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] GCC8+ what new environment check is needed for packages

Chris Gransden wrote on 03 March 2021 22:49

> In article <88c19afa-7904-b93e-190c-2bcebaa3feb6@sky.com>,
>   Lee Noar <lee.noar@sky.com> wrote:
> > On 03/03/2021 16:49, alan buckley wrote:
> > > To run programs compiled on GCC8 or later what environment is required?
> > >
> > > I�d like to add a new environment type to the PackMan packages so these
> > > programs can be packaged, but not show up on machines where they won�t run.
> > >
> > > I�m assuming that the current vfp check isn�t enough.
> > >
> > > Would a vfpv3 cover it? If so, does anyone know the code required to
> > > check for a RISC OS machine for it?

> > If I'm understanding you correctly, then GCC8 and later should work on
> > anything with VFP, so a VFP check should be OK, however, the libraries
> > are not compatible with GCC4. The libraries for GCC8/10 are stored in
> > !SharedLibs.lib.armeabi, so armeabi would be the name of environment?

 

The environment is for the hardware it runs on, not the software itself. So if

the vfp check is ok (but see below) that would be sufficient.

 

Are the GCC8/10 linked to different numbered version of the shared C libraries?

If this is the case, then we just need packages with different names for each.

If it is just the case they need armeabi versions of the existing versions, I'd

probably create a package with the correct versions in and make anything that

needs them depend on that package. If we need the stuff from the current

shared libraries then these new shared library packages can depend on those.

> > For dynamic linking, it would require the runtime shared libraries to
> > be packaged. Such a package is produced with the GCC10 build for
> > copying over the package produced by the GCC4 build, although should the
> > C++ libraries be in a separate package?

 

Yes, I think it should really though it's not critical. It sounds like the GCC10

package is already there.

> I just tried a simple Hello World program built by gcc 10.2 and it gave an
> abort when run on a RPi 1B. Pi 1 is armv6 and vfp2.
> If I do gcc -v it shows armv7 and vfpv3 as defaults.

Chris mentioned this to me, which is one of the reasons I asked the question

about the environment.

 

Regards,

Alan

 

Re: [gccsdk] GCC8+ what new environment check is needed for packages

In article <88c19afa-7904-b93e-190c-2bcebaa3feb6@sky.com>,
Lee Noar <lee.noar@sky.com> wrote:
> On 03/03/2021 16:49, alan buckley wrote:
> > To run programs compiled on GCC8 or later what environment is required?
> >
> > I�d like to add a new environment type to the PackMan packages so these
> > programs can be packaged, but not show up on machines where they won�t run.
> >
> > I�m assuming that the current vfp check isn�t enough.
> >
> > Would a vfpv3 cover it? If so, does anyone know the code required to
> > check for a RISC OS machine for it?

> If I'm understanding you correctly, then GCC8 and later should work on
> anything with VFP, so a VFP check should be OK, however, the libraries
> are not compatible with GCC4. The libraries for GCC8/10 are stored in
> !SharedLibs.lib.armeabi, so armeabi would be the name of environment?

> For dynamic linking, it would require the runtime shared libraries to
> be packaged. Such a package is produced with the GCC10 build for
> copying over the package produced by the GCC4 build, although should the
> C++ libraries be in a separate package?


I just tried a simple Hello World program built by gcc 10.2 and it gave an
abort when run on a RPi 1B. Pi 1 is armv6 and vfp2.
If I do gcc -v it shows armv7 and vfpv3 as defaults.


_______________________________________________
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] GCC8+ what new environment check is needed for packages

On 03/03/2021 16:49, alan buckley wrote:
> To run programs compiled on GCC8 or later what environment is required?
>
> I�d like to add a new environment type to the PackMan packages so these
> programs can be packaged, but not show up on machines where they won�t run.
>
> I�m assuming that the current vfp check isn�t enough.
>
> Would a vfpv3 cover it? If so, does anyone know the code required to
> check for a RISC OS machine for it?

If I'm understanding you correctly, then GCC8 and later should work on
anything with VFP, so a VFP check should be OK, however, the libraries
are not compatible with GCC4. The libraries for GCC8/10 are stored in
!SharedLibs.lib.armeabi, so armeabi would be the name of environment?

For dynamic linking, it would require the runtime shared libraries to
be packaged. Such a package is produced with the GCC10 build for
copying over the package produced by the GCC4 build, although should the
C++ libraries be in a separate package?

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] GCC8+ what new environment check is needed for packages

To run programs compiled on GCC8 or later what environment is required?

I'd like to add a new environment type to the PackMan packages so these programs can be packaged, but not show up on machines where they won't run.

I'm assuming that the current vfp check isn't enough.

Would a vfpv3 cover it? If so, does anyone know the code required to check for a RISC OS machine for it?

 

Thanks,

Alan

Re: [gccsdk] std::stringstream with GCCSDK

On 01/03/2021 10:34, Daryl wrote:
> Hi Lee,
>
> Thanks for the message! I couldn't get the stringstream to work at all,
> and when I searched up the errors somebody mentioned that C++11 support
> was incomplete in 4.7?

Yes, I think 4.7 may have been close to the threshold of when C++11 was
being added so support may be sketchy. I know webkit now requires at
least 4.9 to support the full features that it uses.

> So I then decided to try GCC8 in GCCSDK.

GCC 10.2 is the latest version available at autobuiler/develop/gcc, not
that it helps here much though. The idea is that autobuiler/develop/gcc
will always be the newest version in the autobuilder, and older versions
will be archived with their version number, like
autobuiler/develop/gcc8.

> This meant I couldn't do my
> build/debug cycle in RPCEmu as it needs VFP,

I find Sunfish/NFS the fastest method of transfer to keep the
build/debug cycle moving.

> but I did get it to compile
> once I had altered all references to wchar_t (which is specifically
> disabled I noticed in the GCCSDK build. > It actually runs pretty well on
> RISC OS itself but with one huge caveat. If I throw an exception, in
> certain cases it crashes out with a library error. If I throw an
> exception of type T and catch *exactly* type T then it works, but if I
> force the exception to be caught in a parent function it crashes. I've
> tried compiling with and without optimisations but with no luck.
>
> C++ exceptions not handled when building on ARM32 · Issue #785 ·
> android/ndk (github.com) <https://github.com/android/ndk/issues/785>
>
> Searching brought up that link, which suggests something very similar.
> ARM, armeabi and C++.
>
> Any ideas? Everything else is working that I can see!

It seems there is a problem with C++ exceptions, and I see the above
example crashes. It looks like it branches to zero and that could be
a missing weak symbol. I'll have a closer look and try to figure out
what's going wrong.

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: [gccsdk] std::stringstream with GCCSDK

Hi Lee,

Thanks for the message! I couldn't get the stringstream to work at all, and when I searched up the errors somebody mentioned that C++11 support was incomplete in 4.7? 

So I then decided to try GCC8 in GCCSDK. This meant I couldn't do my build/debug cycle in RPCEmu as it needs VFP, but I did get it to compile once I had altered all references to wchar_t (which is specifically disabled I noticed in the GCCSDK build). It actually runs pretty well on RISC OS itself but with one huge caveat. If I throw an exception, in certain cases it crashes out with a library error. If I throw an exception of type T and catch *exactly* type T then it works, but if I force the exception to be caught in a parent function it crashes. I've tried compiling with and without optimisations but with no luck.

C++ exceptions not handled when building on ARM32 · Issue #785 · android/ndk (github.com)

Searching brought up that link, which suggests something very similar. ARM, armeabi and C++.

Any ideas? Everything else is working that I can see!

Thanks,

Daryl.

On Sun, 28 Feb 2021 at 11:46, Lee Noar <lee.noar@sky.com> wrote:

On 21/02/2021 23:56, Daryl Dudey wrote:
> I'm writing a fairly big C++ BASIC style language for Windows & RISC OS and I'm trying to cross-compile on Windows and I can't get the std::stringstream to not give errors. I had problems with ostream before and switched to use regular C I/O functions to get around it.
>
> I get various errors including deleted functions errors. I can post the output if useful.
>
> If I replace it with just std::string or fprintf then it all works, but a lot of the code is in 3rd party library stuff I daren't risk changing.
>
> Is there anything I can try or do?
>
> Thanks,
> Daryl.

Hi Daryl,

Can you post a reduced example that show the errors that you are seeing?

I'm surprised that you had trouble with ostream as that is paired up
with the compiler and so its features are matched to what the compiler
is capable of (rather than 3rd party libraries which may have higher
expectations from the compiler).

Deleted function errors usually indicate that you're trying to use an
object in a way that isn't allowed, for example, trying to copy an
object when the copy constructor has been deleted. The nature of C++
means you can be copying an object without even realising it, for
example, by passing an object to a function by value instead of by
reference.

Lee.