Tuesday, 31 March 2020

Re: [gccsdk] Building GCC 8


On 30/03/2020 11:49, Lee Noar wrote:
On 30/03/2020 10:52, David Pitt wrote:
Lee Noar, on 30 Mar, wrote:

[snip]

When building GCC8 or using it as the compiler in the autobuilder, you
have to have:

RO_USE_ARMEABIHF=yes

in your build-setvars file.

Many thanks, the build does now complete and there is a !SharedLibs with
content.


There was a minor matter at the end of the build.

Autobuilder: Packaging source
/home/djp/gccsdk/autobuilder/build-program: line 384: distclean: command not
found
/home/djp/gccsdk/autobuilder/build-program: line 384: clean: command not
found
Package gcc: ***Failure***
Build for package "gcc" failed


I  get the same. Still a bit rusty on exactly what is what, but in the gcc Makefile (in build/gcc8/gcc/gcc-8.2.0/cross-build)  I cannot see targets of distclean and clean .. all I see are do-distclean and do-clean ..

Does this suggest a patch for the makefile to add distclean and clean that access these targets?

John



Not a complete failure however.

djp@ubuntu1910:~/gccsdk/env$ ./ro-path gcc --version
arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 3) 4.7.4

djp@ubuntu1910:~/gccsdk/env$ ./ro-path arm-riscos-gnueabihf-gcc --version
arm-riscos-gnueabihf-gcc (GCCSDK GCC 8.2.0) 8.2.0

Thanks again.

I've never seen this because I always build with the -d switch, ie:

../autobuilder/build -d gcc

as this causes the source code/build products to be retained for
debugging and development. I'll have a look and see if I can
fix it.

Thanks,
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
--
Stop press! Just announced -

Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile

For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761

Intrigued? Call me

John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923

Monday, 30 March 2020

Re: libnslog: portability fixes for plan9

> What about when neither of these cases match?
>
> Maybe something like this would be better
>
> #else
> # if defined(_PLAN9)
> # pragma varargck nslog__log argpos 2
> # endif
> # define PRINTF(pos, args)
>

Re: [gccsdk] Building GCC 8

There does seem to be a list problem, I have not seen this via the list
(yet?).

Lee Noar, on 30 Mar, wrote:

> On 30/03/2020 10:52, David Pitt wrote:
> > Lee Noar, on 30 Mar, wrote:

[snip]

> > Autobuilder: Packaging source
> > /home/djp/gccsdk/autobuilder/build-program: line 384: distclean: command
> > not found
> > /home/djp/gccsdk/autobuilder/build-program: line 384: clean:
> > command not found

> > Package gcc: ***Failure*** Build for package "gcc"
> > failed

[snip]

> I've never seen this because I always build with the -d switch, ie:
>
> ../autobuilder/build -d gcc
>
> as this causes the source code/build products to be retained for debugging
> and development. I'll have a look and see if I can fix it.

I see I am perhaps jumping the gun a bit. I saw mentions of the use of GCC8
on the ROOL forum so had a look.

'Hello Worlds' in C and C++ have now been cross compiled with gcc 8 and they
do run on the Titanium.

--
David Pitt

_______________________________________________
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] Building GCC 8

On 30/03/2020 10:52, David Pitt wrote:
> Lee Noar, on 30 Mar, wrote:
>
> [snip]
>
>> When building GCC8 or using it as the compiler in the autobuilder, you
>> have to have:
>>
>> RO_USE_ARMEABIHF=yes
>>
>> in your build-setvars file.
>
> Many thanks, the build does now complete and there is a !SharedLibs with
> content.
>
>
> There was a minor matter at the end of the build.
>
> Autobuilder: Packaging source
> /home/djp/gccsdk/autobuilder/build-program: line 384: distclean: command not
> found
> /home/djp/gccsdk/autobuilder/build-program: line 384: clean: command not
> found
> Package gcc: ***Failure***
> Build for package "gcc" failed
>
>
> Not a complete failure however.
>
> djp@ubuntu1910:~/gccsdk/env$ ./ro-path gcc --version
> arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 3) 4.7.4
>
> djp@ubuntu1910:~/gccsdk/env$ ./ro-path arm-riscos-gnueabihf-gcc --version
> arm-riscos-gnueabihf-gcc (GCCSDK GCC 8.2.0) 8.2.0
>
> Thanks again.

I've never seen this because I always build with the -d switch, ie:

../autobuilder/build -d gcc

as this causes the source code/build products to be retained for
debugging and development. I'll have a look and see if I can
fix it.

Thanks,
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] Building GCC 8

Lee Noar, on 30 Mar, wrote:

[snip]

> When building GCC8 or using it as the compiler in the autobuilder, you
> have to have:
>
> RO_USE_ARMEABIHF=yes
>
> in your build-setvars file.

Many thanks, the build does now complete and there is a !SharedLibs with
content.


There was a minor matter at the end of the build.

Autobuilder: Packaging source
/home/djp/gccsdk/autobuilder/build-program: line 384: distclean: command not
found
/home/djp/gccsdk/autobuilder/build-program: line 384: clean: command not
found
Package gcc: ***Failure***
Build for package "gcc" failed


Not a complete failure however.

djp@ubuntu1910:~/gccsdk/env$ ./ro-path gcc --version
arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 3) 4.7.4

djp@ubuntu1910:~/gccsdk/env$ ./ro-path arm-riscos-gnueabihf-gcc --version
arm-riscos-gnueabihf-gcc (GCCSDK GCC 8.2.0) 8.2.0

Thanks again.
--
David Pitt

_______________________________________________
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

Sunday, 29 March 2020

Re: libnslog: portability fixes for plan9

On 2020-03-22, ori@eigenstate.org <ori@eigenstate.org> wrote:
> diff -urN a/include/nslog/nslog.h b/include/nslog/nslog.h
> --- a/include/nslog/nslog.h Sun Feb 23 01:49:32 2020
> +++ b/include/nslog/nslog.h Sun Mar 22 18:08:23 2020
> @@ -17,6 +17,13 @@
>
> #include <stdarg.h>
>
> +#if defined(__GNUC__)
> +# define PRINTF(fmt, args) __attribute__ ((format (printf, 2, 3)))

Did you mean `#define PRINTF(pos, args) __attribute__ ((format
(printf, pos, args)))` here?

> +#elif defined(_PLAN9)
> +# pragma varargck nslog__log argpos 2
> +# define PRINTF(pos, args)
> +

Re: [gccsdk] Building GCC 8

On 29/03/2020 22:47, David Pitt wrote:
> Lee Noar, on 29 Mar, wrote:
>
> [snip]
>
>>> Autobuilder: Running make command: /bin/cp: cannot create regular file
>>>
> '/home/djp/gccsdk/build/gcc/package/SharedLibs-armeabihf/Resources/!SharedLibs/lib/armeabihf/libgcc_s.so.1,E1F':
>>> No such file or directory
>
> [snip]
>
>> The previous ab_add_sharedlib should have created the necessary directory
>> structure, but do all the directories exist up to
>> !SharedLibs/lib/armeabihf? There should be other libraries in there
>> already.
>
> No, that has not happened, the only folder present is :-
>
> /home/djp/gccsdk/build/gcc/package/SharedLibs-armeabihf/Resources/!SharedLibs/lib/abi-2.0
>
> The last-failure log is at :-
>
> http://www.pittdj.co.uk/temp/last-failure.zip

Ok, I think I can see what's happening. When building GCC8 or using it
as the compiler in the autobuilder, you have to have:

RO_USE_ARMEABIHF=yes

in your build-setvars file. Admittedly, this still requires documenting
somewhere. When I eventually get the native compiler working, I will add
some proper documentation to the wiki.

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] Building GCC 8

Lee Noar, on 29 Mar, wrote:

[snip]

> > Autobuilder: Running make command: /bin/cp: cannot create regular file
> >
'/home/djp/gccsdk/build/gcc/package/SharedLibs-armeabihf/Resources/!SharedLibs/lib/armeabihf/libgcc_s.so.1,E1F':
> > No such file or directory

[snip]

> The previous ab_add_sharedlib should have created the necessary directory
> structure, but do all the directories exist up to
> !SharedLibs/lib/armeabihf? There should be other libraries in there
> already.

No, that has not happened, the only folder present is :-

/home/djp/gccsdk/build/gcc/package/SharedLibs-armeabihf/Resources/!SharedLibs/lib/abi-2.0

The last-failure log is at :-

http://www.pittdj.co.uk/temp/last-failure.zip

--
David Pitt

_______________________________________________
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] Building GCC 8

On 29/03/2020 20:01, David Pitt wrote:
> I have been trying to build gcc 8.2 on the autobuilder, because it's there
> and suddenly there is time to spare, with :-
>
> ../autobuilder/build -v gcc
>
> It fails :-
>
> make[2]: Leaving directory
> '/home/djp/gccsdk/build/gcc/gcc-8.2.0/cross-build/ld-riscos'
> make[1]: Leaving directory
> '/home/djp/gccsdk/build/gcc/gcc-8.2.0/cross-build/ld-riscos'
> Autobuilder: Running make command:
> /bin/cp: cannot create regular file
> '/home/djp/gccsdk/build/gcc/package/SharedLibs-armeabihf/Resources/!SharedLibs/lib/armeabihf/libgcc_s.so.1,E1F':
> No such file or directory
>
> The source is line 186 from SetVars.
>
> # libgcc_s doesn't follow the rules
> cp -fT $GCCSDK_INSTALL_ENV/arm-riscos-gnueabihf/lib/libgcc_s.so.1
> $A/lib/$GCCSDK_RISCOS_ABI_VERSION/libgcc_s.so.1,E1F
> $GCCSDK_INSTALL_CROSSBIN/arm-unknown-riscos-ln -s libgcc_s.so.1
> $A/lib/$GCCSDK_RISCOS_ABI_VERSION/libgcc_s.so,1C8
>
> What have I missed.

I can't see anything obvious.

The previous ab_add_sharedlib should have created the necessary
directory structure, but do all the directories exist up to
!SharedLibs/lib/armeabihf? There should be other libraries in
there already.

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] Building GCC 8

I have been trying to build gcc 8.2 on the autobuilder, because it's there
and suddenly there is time to spare, with :-

../autobuilder/build -v gcc

It fails :-

make[2]: Leaving directory
'/home/djp/gccsdk/build/gcc/gcc-8.2.0/cross-build/ld-riscos'
make[1]: Leaving directory
'/home/djp/gccsdk/build/gcc/gcc-8.2.0/cross-build/ld-riscos'
Autobuilder: Running make command:
/bin/cp: cannot create regular file
'/home/djp/gccsdk/build/gcc/package/SharedLibs-armeabihf/Resources/!SharedLibs/lib/armeabihf/libgcc_s.so.1,E1F':
No such file or directory

The source is line 186 from SetVars.

# libgcc_s doesn't follow the rules
cp -fT $GCCSDK_INSTALL_ENV/arm-riscos-gnueabihf/lib/libgcc_s.so.1
$A/lib/$GCCSDK_RISCOS_ABI_VERSION/libgcc_s.so.1,E1F
$GCCSDK_INSTALL_CROSSBIN/arm-unknown-riscos-ln -s libgcc_s.so.1
$A/lib/$GCCSDK_RISCOS_ABI_VERSION/libgcc_s.so,1C8

What have I missed.

GCC4 has already been built.

--
David Pitt

_______________________________________________
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

[Rpcemu] Another little patch for macOS

Rounding off the work I've been making doing for macOS X, is the attached patch.

  • VERSION is now defined in the QT .pro file, rather than in rpcemu.h
  • The Mac application info.plist uses this for the correct application version
  • The Mac application bundle identifier is properly composed using qmake variables, leading to a different identifier for the recompiler vs interpreter versions; this allows both of them to be added to Security & Privacy settings as independent entities.

The line numbers in the patch are for a set of sources already patched with Timothy Coltman's V4 Mac patch, but would probably work successfully in unpatched source too using just the diff context. While this small change set is mostly Mac-focused, I do think having the version specified in the project file is the right thing generally and it might be a useful addition to the main source tree.

--   Andrew Hodgkinson  RISC OS Open Limited  http://www.riscosopen.org/

Saturday, 28 March 2020

Re: [gccsdk] Unixlib select bug?

On 27/03/2020 11:37, Chris Johns wrote:
> Not sure if this is the right place to post this..

Yes, this is the right place.

> I think there is a bug in the select() timeout logic - the effect is it
> seems to ignore the tv_usec part of the timeout. Python's time.sleep
> used select to do the actual waiting, and it was found that it just
> ignored the fractional part, so sleep(0.2) would just return. In fact
> sleep (0.99) also just returns, sleep (1.0) sleeps for a second,
> sleep(1.99) also sleeps for a second..
>
> I had a look at the logic in ul_select.c and it appears to use this to
> work out then end time..
>
>           end = now + timeout->tv_sec * 100
>             + (50000 + timeout->tv_usec) / 1000000;
>
> However, the tv_usec part will just get end up as 0 (unless its >
> 1000000, but that will get rejected by the earlier check). I think the
> problem is it's converting usec to seconds, rather than usec to
> centiseconds, so it should be:
>
>           end = now + timeout->tv_sec * 100
>             + (500 + timeout->tv_usec) / 10000;
>
> In fact:
>
>           end = now + timeout->tv_sec * 100 + timeout->tv_usec / 10000;
>
> Might be enough.

Ok, thanks, I'll try that. I've had trouble with select() myself for
some time. I've been suspecting for a while that it can get stuck in
an infinite loop. If calling Wimp_Poll from the same thread, then the
desktop comes to a halt. Your findings may well be the explanation.

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

Friday, 27 March 2020

[gccsdk] Unixlib select bug?

Not sure if this is the right place to post this..

I think there is a bug in the select() timeout logic - the effect is it
seems to ignore the tv_usec part of the timeout. Python's time.sleep
used select to do the actual waiting, and it was found that it just
ignored the fractional part, so sleep(0.2) would just return. In fact
sleep (0.99) also just returns, sleep (1.0) sleeps for a second,
sleep(1.99) also sleeps for a second..

I had a look at the logic in ul_select.c and it appears to use this to
work out then end time..

          end = now + timeout->tv_sec * 100
            + (50000 + timeout->tv_usec) / 1000000;

However, the tv_usec part will just get end up as 0 (unless its >
1000000, but that will get rejected by the earlier check). I think the
problem is it's converting usec to seconds, rather than usec to
centiseconds, so it should be:

          end = now + timeout->tv_sec * 100
            + (500 + timeout->tv_usec) / 10000;

In fact:

          end = now + timeout->tv_sec * 100 + timeout->tv_usec / 10000;

Might be enough.

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

Thursday, 26 March 2020

Re: Atari build 5032: cache folder

Vincent,

you did it! I tested FireBee version and nov disk cache also works! Now surfing the net is also faster.
Thank you a lot!

There is still one problem with Atari built and if you have will to take a look. it doesnt display the webp pictures.
Instead to display it, it wants to download it.

Thank you,
Vido


V V sre., 25. mar. 2020 ob 23:14 je oseba Vincent Sanders <vince@netsurf-browser.org> napisala:
On Sat, Feb 29, 2020 at 10:33:10PM +0000, Peter Slegg wrote:
>
> I have just installed the Atari test build 5032 and it throws an error.
>
> NetSurf failed to initialise
>
>
> I switched the binary back to a previous build but that failed as
> well. Investigation showed that the cache folder had gone.
>
> I re-created it and the older version runs again but 5032 deletes it.
>
>
> Peter

I beleive I have fixed this now. The code for atari_mkdir_all() was
using the wrong directory separator (i.e. / instead of \)

Let me know if that fixes the problem as I cannot test myself


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

Re: [Rpcemu] RPCEmu macOS mouse behaviour

In message <601FFCCA-2F8E-4FEE-A579-66899E79ADCA@riscosopen.org>
"Andrew Hodgkinson" <ahodgkin@riscosopen.org> wrote:



> I copied the executable onto a Catalina Mac from work that's never run
> it before and added it into the Accessibility section of the Security
> system preferences as described elsewhere. With this done, the mouse
> pointer in non-host mode did work as expected and per Peter's
> explanation. In this mode, EX0/EY0 stuff works just fine, so I was
> delighted to be able to run a true retina mode X3072 Y1920 C256 EX0
> EY0 and for the first time ever, run a good-sized RISC OS desktop in
> native "retina mode". Fun!

On a 27" 5K display I have got this far :-

WimpMode X3200 Y2160 C256 EX0 EY0

As far as I can see 'certain measures' need to be taken to avoid a
2048 size limit.

Impressive though.
--
David Pitt
Titanium

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: libwapcaplet portability fixes (re: plan 9 port)

On Thu, Mar 26, 2020 at 02:13:25 -0700, Michael Forney wrote:
> If this is not an option, then I would suggest using `#ifdef __GNUC__`
> to check for the availability of statement-expressions rather than
> assuming only plan9 lacks them.

We had a discussion about exactly that define on #netsurf not long after
I sent that email. My only excuse is that I hadn't had much tea yet.

Clearly it makes more sense to check for __GNUC__ and that's what I'll do
later today if noone gets there before me.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Re: libwapcaplet portability fixes (re: plan 9 port)

On 2020-03-26, Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
>> The plan 9 compilers are not gcc, and do not handle many
>> gcc extensions like expression templates. this change
>> replaces them with either plain macros, or with static
>> inline functions, which are already in use elsewhere in
>> the project.
>
> I've reviewed the patch and it's not fundamentally bad, though
> the inline function for lwc_string_ref() will end up exploding the
> size of code a lot on many of our platforms.
>
> Instead I'd prefer to rework this to have the same effect for
> you, but to remain slightly less impactful on our other platforms.
>
> Could you let me know of a preprocessor macro I can rely on for plan9?
> With that, I can then rework this into something I hope will work
> for you, but also be nicer for the rest of our targets.

Hi there,

I've been using a similar patch[0] for my netsurf builds because my C
compiler, cproc, also does not support GNU C statement-expressions. I
hope that we can solve this without a plan9-specific #ifdef so that
the issue can be fixed for other non-GNU C compilers.

I'm curious as to why the inline function is exploding the code size
on other platforms. Is the code not getting inlined? If that's the
case, another option might be to just use plain `inline` in the
headers, and then make a `extern inline` declaration in
libwapcaplet.c. This way, anything that includes libwapcaplet.h will
be able to inline calls to lwc_string_ref if the compiler wants, and
if it doesn't, it will just use the single definition in
libwapcaplet.a (avoiding separate definitions for each translation
unit). I can provide a patch using this approach if you want check if
it works for your other platforms.

If this is not an option, then I would suggest using `#ifdef __GNUC__`
to check for the availability of statement-expressions rather than
assuming only plan9 lacks them.

[0] https://github.com/michaelforney/libwapcaplet/commit/5c4d56ff64856fb5d39a91d15df417934981e4fe

Re: libwapcaplet portability fixes (re: plan 9 port)

On Sun, Mar 22, 2020 at 17:50:47 -0700, ori@eigenstate.org wrote:
> I'm one of the people who's been helping port netsurf to
> plan9, and I've started rebasing changes that we did against
> 3.9 to master, so that we can start submitting what makes sense.

Great.

> First off, thanks for a wonderfully portable codebase -- it's
> great how small the patches are to get most of the libraries
> working.

I'm very pleased that it's proving possible (and even easy) for you.

> I'm hoping that we can get things to the point where we need to
> carry very few patches forward, though I don't expect you'll want
> to maintain our build system (ie, the mkfiles), so I'm going to
> leave them out of patches.

True, at least for now we won't want a secondary build system. We're
resisting CMake for similar reasons.

> The plan 9 compilers are not gcc, and do not handle many
> gcc extensions like expression templates. this change
> replaces them with either plain macros, or with static
> inline functions, which are already in use elsewhere in
> the project.

I've reviewed the patch and it's not fundamentally bad, though
the inline function for lwc_string_ref() will end up exploding the
size of code a lot on many of our platforms.

Instead I'd prefer to rework this to have the same effect for
you, but to remain slightly less impactful on our other platforms.

Could you let me know of a preprocessor macro I can rely on for plan9?
With that, I can then rework this into something I hope will work
for you, but also be nicer for the rest of our targets.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Wednesday, 25 March 2020

Re: Atari build 5032: cache folder

On Wed, 25 Mar 2020 22:14:52 , Vincent Sanders <vince@netsurf-browser.org> wrote:
> On Sat, Feb 29, 2020 at 10:33:10PM +0000, Peter Slegg wrote:
> >
> > I have just installed the Atari test build 5032 and it throws an error.
> >
> > NetSurf failed to initialise
> >
> >
> > I switched the binary back to a previous build but that failed as
> > well. Investigation showed that the cache folder had gone.
> >
> > I re-created it and the older version runs again but 5032 deletes it.
> >
> >
> > Peter
>
> I beleive I have fixed this now. The code for atari_mkdir_all() was
> using the wrong directory separator (i.e. / instead of \)
>
> Let me know if that fixes the problem as I cannot test myself
>
>


Hi,

I quickly tried the non-working build from an ext2 partition but that
didn't work either.

However build 5049 has fixed it.

Many thanks.

Peter

Re: Atari build 5032: cache folder

On Sat, Feb 29, 2020 at 10:33:10PM +0000, Peter Slegg wrote:
>
> I have just installed the Atari test build 5032 and it throws an error.
>
> NetSurf failed to initialise
>
>
> I switched the binary back to a previous build but that failed as
> well. Investigation showed that the cache folder had gone.
>
> I re-created it and the older version runs again but 5032 deletes it.
>
>
> Peter

I beleive I have fixed this now. The code for atari_mkdir_all() was
using the wrong directory separator (i.e. / instead of \)

Let me know if that fixes the problem as I cannot test myself


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

Re: [Rpcemu] RPCEmu macOS mouse behaviour

On 26 Mar 2020, at 0:44, David Pitt wrote:

> I can confirm that with Andrew's full screen mouse patch applied the
> the mouse pointer does now work on RPCEmu 0.9.2 in Full-screen in
> Follow Host Mouse mode on Ubuntu 18.04 running in a VMWare Fusion VM
> on an iMacPro.

Good to know, thanks. I copied the executable onto a Catalina Mac from
work that's never run it before and added it into the Accessibility
section of the Security system preferences as described elsewhere. With
this done, the mouse pointer in non-host mode did work as expected and
per Peter's explanation. In this mode, EX0/EY0 stuff works just fine, so
I was delighted to be able to run a true retina mode X3072 Y1920 C256
EX0 EY0 and for the first time ever, run a good-sized RISC OS desktop in
native "retina mode". Fun!

--
Andrew Hodgkinson
RISC OS Open Limited
http://www.riscosopen.org/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu macOS mouse behaviour

In message <20B2A48A-E46F-4017-B564-7C0E6B777450@riscosopen.org>
Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:

> On 23/03/2020, at 19:04, I wrote:

>> On 23 Mar 2020, at 14:23, Peter Howkins wrote:
>>
>>> Can you confirm this, or if not please provide info on which Linux
>>> distro you're running under?
>>
>> A colleague had Linux issues and confirmed follow-host in full screen
>> mode worked OK with the patch; I'll get back to you with distro info
>> when I have that available.

> Sorry for the delayed response. New Zealand went into full lockdown so
> there was some inevitable disruption.

> It was tested on Linux Mint 19.1, which is effectively the same as
> Ubuntu 18.04, and uses Qt 5.9.5.

I can confirm that with Andrew's full screen mouse patch applied the
the mouse pointer does now work on RPCEmu 0.9.2 in Full-screen in
Follow Host Mouse mode on Ubuntu 18.04 running in a VMWare Fusion VM
on an iMacPro.

--
David Pitt
Titanium

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Tuesday, 24 March 2020

Re: [Rpcemu] RPCEmu macOS mouse behaviour

On 23/03/2020, at 19:04, I wrote:

> On 23 Mar 2020, at 14:23, Peter Howkins wrote:
>
>> Can you confirm this, or if not please provide info on which Linux distro you're running under?
>
> A colleague had Linux issues and confirmed follow-host in full screen mode worked OK with the patch; I'll get back to you with distro info when I have that available.

Sorry for the delayed response. New Zealand went into full lockdown so there was some inevitable disruption.

It was tested on Linux Mint 19.1, which is effectively the same as Ubuntu 18.04, and uses Qt 5.9.5.

--
Andrew Hodgkinson
RISC OS Open Limited
https://www.riscosopen.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Atari build 5032: cache folder

I dont remember such issues in the past but I know disc cache never worked for me.
If I understand right the errors I posted, NetSurf cant update the file as the file is locked?
I guess the file should be released after update/creation?

Vido


V V ned., 22. mar. 2020 ob 23:24 je oseba Peter Slegg <pslegg@scubadivers.co.uk> napisala:
On Mon, 9 Mar 2020 19:54:06 , Peter Slegg <pslegg@scubadivers.co.uk> wrote:
> Hi Vido,
>
> From a quick look at the commit, I think if there is any issue
> with the cache it deletes it.
>
> http://git.netsurf-browser.org/netsurf.git/commit/?id=14286b381b12034140768800c7ba10baa7c3b334
>
> I suspect it cannot create it again for some reason.
>
> Peter
>

I have a vague memory of a similar issue several years ago in the
Atari build. A file or folder that was not created when needed.
It had to be created manually.

Could this be a general problem with the way Netsurf creates files
or folders in the Atari build ?

Peter




Sunday, 22 March 2020

Re: [Rpcemu] RPCEmu macOS mouse behaviour

On 23 Mar 2020, at 14:23, Peter Howkins wrote:

> Can you confirm this, or if not please provide info on which Linux
> distro you're running under?

A colleague had Linux issues and confirmed follow-host in full screen
mode worked OK with the patch; I'll get back to you with distro info
when I have that available.

>> It is definitely advantageous to be able 
>> to access the menu bar and get out of full screen mode in Mac OS,
>> and 
>> advantageous to be able to thereafter scale the RPCEmu window and
>> have 
>> the mouse coordinates still correctly mapped.
>
> I'm also a bit confused about this one, at least on Windows and Linux,
> full screen means you can pretend there's no Host OS there, it's great
> for games and the like you're on a real machine. There isn't the menu
> bar available (because either the menu bar is over the top of the RISC
> OS content, or the RISC OS content has been squished under it?).

Under macOS since the introduction of a system-wide OS API standardised
full screen mode (IIRC in OS X Lion, 10.7.0) the way it works is:

* Your window goes into its own desktop "space"
* The application menu bar (shown at the top of the screen in macOS) and
the window title bar with window controls is hidden
* If the OS mouse pointer is moved towards the top of the screen, the
menu bar and window title bar become visible

There are three ways once in full screen mode that one might exit it:

* Using some usually application-specific key combination
* By using an application menu entry
* By using the "green" button (of the OS X red, orange green) in the
window title bar

The last two are only possible when the menu bar and title bar are
visible, which in turn is only possible when the mouse pointer is able
to move to the top of the screen. In the "non-mousehack" mode that
RPCEmu currently enforces when in full screen, the mouse pointer is
continuously reset to the window centre, making it impossible to reach
the application main menu or the window title bar. This also means you
can't do things like change application preferences or e.g. load a
floppy disc image.

Mac laptops don't have an End key, so Ctrl+End is not accessible there
and this means users tend to get 'trapped' in full screen mode in the
current implementation. Even if they turned on mousehack, it's
temporarily disabled in full screen mode. With the patch in my previous
message, this behaviour is changed. *If* the user has chosen "follow
host" (mousehack) mode, then this maintained in full screen mode and the
host mouse and guest (RISC OS) mouse positions are properly mapped. The
host mouse pointer moves normally and the window titlebar & main menu
all become accessible in full screen mode. If the user has turned
"follow host" off, then the unaltered prior behaviour of
host-mouse-pulled-to-centre is maintained and the user has to find their
own way out of full screen mode, but they have the advantage of a far
more accurate emulation environment and I suspect that this is likely to
be especially useful for games.

If I were using RISC OS under emulation in full screen on a Mac for the
desktop, then, I'd prefer it with the patch applied & mousehack on. For
games, I'd turn mousehack off.

--
Andrew Hodgkinson
RISC OS Open Limited
http://www.riscosopen.org/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

nsfb plan9 support

>From cb45b499fb048c7bfcaea0744f4303b964d48469
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 22 Mar 2020 19:06:30 -0700
Subject: [PATCH] Add support for plan 9 surface, remove gcc dependency.


This adds framebuffer support for plan 9 image surfaces,
and puts macros like UNUSED and __attribute__((constructor))
behind appropriate ifdefs.
diff -urN a/include/libnsfb.h b/include/libnsfb.h
--- a/include/libnsfb.h Mon Feb 24 02:57:05 2020
+++ b/include/libnsfb.h Sun Mar 22 19:06:30 2020
@@ -42,6 +42,7 @@
NSFB_SURFACE_LINUX, /**< Linux framebuffer surface */
NSFB_SURFACE_ABLE, /**< ABLE framebuffer surface */
NSFB_SURFACE_RAM, /**< RAM surface */
+ NSFB_SURFACE_PLAN9, /**< Plan 9 devdraw surface */
NSFB_SURFACE_COUNT, /**< The number of surface kinds */
};

diff -urN a/src/plot/16bpp.c b/src/plot/16bpp.c
--- a/src/plot/16bpp.c Mon Feb 24 02:57:05 2020
+++ b/src/plot/16bpp.c Sun Mar 22 19:06:30 2020
@@ -17,7 +17,11 @@
#include "nsfb.h"
#include "plot.h"

-#define UNUSED __attribute__((unused))
+#ifdef __GNUC__
+#define UNUSED __attribute__((unused))
+#else
+#define UNUSED
+

Re: [Rpcemu] RPCEmu macOS mouse behaviour



On Sun, 22 Mar 2020 at 22:55, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
That said, under Linux we also
see the exact same behaviour and the "mousehack" mode plus patch does
seem to do the trick there too.

This is odd, because in my experience it does work on Linux fine. Except under one circumstance, if it's a Linux running under VirtualBox there's virtual box bug that stops it :(
 
Can you confirm this, or if not please provide info on which Linux distro you're running under?

It is definitely advantageous to be able
to access the menu bar and get out of full screen mode in Mac OS, and
advantageous to be able to thereafter scale the RPCEmu window and have
the mouse coordinates still correctly mapped.

I'm also a bit confused about this one, at least on Windows and Linux, full screen means you can pretend there's no Host OS there, it's great for games and the like you're on a real machine. There isn't the menu bar available (because either the menu bar is over the top of the RISC OS content, or the RISC OS content has been squished under it?).

Peter

libnslog: portability fixes for plan9

>From be21e1a1d3ffa0b3baa073bdb4b04c80af7f7bee
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 22 Mar 2020 18:08:23 -0700
Subject: [PATCH] portability fixes for plan9


this fixes 3 issues:
- First off, the plan 9 C compilers don't handle GNU style varargs,
so we switch over to c99 style.
- Second, the __attribute((format, printf) is a GNU C extension,
so we only define it for GNU C. For plan 9, we use the varargck
pragma to do the same thing.
- Third, 0 length arrays aren't portable, so we use C99 flexible
array members.
diff -urN a/include/nslog/nslog.h b/include/nslog/nslog.h
--- a/include/nslog/nslog.h Sun Feb 23 01:49:32 2020
+++ b/include/nslog/nslog.h Sun Mar 22 18:08:23 2020
@@ -17,6 +17,13 @@

#include <stdarg.h>

+#if defined(__GNUC__)
+# define PRINTF(fmt, args) __attribute__ ((format (printf, 2, 3)))
+#elif defined(_PLAN9)
+# pragma varargck nslog__log argpos 2
+# define PRINTF(pos, args)
+

[PATCH] make source a compatible type

>From 5b1b4fc13212991968bff51e98cba9da5552d983
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 22 Mar 2020 18:04:44 -0700
Subject: [PATCH] make source a compatible type


We pass uint32_t source as an out parameter which takes an int32_t pointer,
and the plan 9 compilers complain about this. This makes the type match.

diff -urN a/bindings/hubbub/parser.c b/bindings/hubbub/parser.c
--- a/bindings/hubbub/parser.c Sat Feb 22 09:15:42 2020
+++ b/bindings/hubbub/parser.c Sun Mar 22 18:04:44 2020
@@ -642,7 +642,7 @@
static hubbub_error change_encoding(void *parser, const char *charset)
{
dom_hubbub_parser *dom_parser = (dom_hubbub_parser *) parser;
- uint32_t source;
+ int32_t source;
const char *name;

/* If we have an encoding here, it means we are *certain* */

[PATCH] libcss portability fixes for plan9

>From 294f0ec43f6f64765d85d2e85ac9b4dafeb0e045
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 22 Mar 2020 18:00:34 -0700
Subject: [PATCH] portability fixes for plan9


Several changes are made here:
- Our compilers don't like double-declared enum tags, so we rename
them to avoid conflicts.
- We don't handle static initializations of bitfields, so we
replace 2 16 bit bitfields with 2 int16_ts. This shouldn't
affect storage or performance.
- uint32_t isn't guaranteed to be compatible with css_unit,
and in fact it isn't on plan9, so we need to just pass
a uint32_t.

diff -urN a/include/libcss/errors.h b/include/libcss/errors.h
--- a/include/libcss/errors.h Mon Feb 24 02:28:58 2020
+++ b/include/libcss/errors.h Sun Mar 22 18:00:34 2020
@@ -14,8 +14,9 @@

libnspsl -- remove bitfields

This patch will probably be something we need to carry forward
in our own port, but I'm going to submit it for discussion anyways.

Currently, the plan 9 C compilers do *not* support static initialization
of bitfields, so we need to do somethign about that. We can replace them
with an enum and flags, or we can drop them entirely. This patch does
the latter.

If you'd be willing to take some other method of removing bitfields, I'd
be happy to implement it and reduce the diff.

--- /mnt/git/object/e41d7b3c868309e0704e01e841cc80da72dd8157/tree/src/psl.inc Mon Jun 24 03:47:46 2019
+++ src/psl.inc Sun Mar 22 14:53:33 2020
@@ -9,9 +9,9 @@
*/
union pnode {
struct {
- unsigned int idx:24; /**< index of domain element in string table */
- unsigned int len:6; /**< length of domain element in string table */
- unsigned int children:1; /**< has children */
+ unsigned int idx; /**< index of domain element in string table */
+ unsigned char len; /**< length of domain element in string table */
+ unsigned char children; /**< has children */
} label;
struct {
uint16_t index; /**< index of first child node */
@@ -28,8 +28,8 @@ enum stab_entities {
* Huffman coding node
*/
struct hnode {
- uint8_t term:1; /**< non zero if the node terminates a code */
- uint8_t value:7; /**< value in node */
+ uint8_t term; /**< non zero if the node terminates a code */
+ uint8_t value; /**< value in node */
};

/**

libwapcaplet portability fixes (re: plan 9 port)

Hey,

I'm one of the people who's been helping port netsurf to
plan9, and I've started rebasing changes that we did against
3.9 to master, so that we can start submitting what makes sense.

First off, thanks for a wonderfully portable codebase -- it's
great how small the patches are to get most of the libraries
working.

I'm hoping that we can get things to the point where we need to
carry very few patches forward, though I don't expect you'll want
to maintain our build system (ie, the mkfiles), so I'm going to
leave them out of patches.

Here's the first patch.

>From b02d1e93846df7f135bc8c1c82c9a2e3291480cf
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 22 Mar 2020 17:47:46 -0700
Subject: [PATCH] portability fixes for Plan 9


The plan 9 compilers are not gcc, and do not handle many
gcc extensions like expression templates. this change
replaces them with either plain macros, or with static
inline functions, which are already in use elsewhere in
the project.
diff -urN a/include/libwapcaplet/libwapcaplet.h b/include/libwapcaplet/libwapcaplet.h
--- a/include/libwapcaplet/libwapcaplet.h Sat Sep 7 06:59:40 2019
+++ b/include/libwapcaplet/libwapcaplet.h Sun Mar 22 17:47:46 2020
@@ -133,7 +133,12 @@
* @note Use this if copying the string and intending both sides to retain
* ownership.
*/
-#define lwc_string_ref(str) ({lwc_string *__lwc_s = (str); assert(__lwc_s != NULL); __lwc_s->refcnt++; __lwc_s;})
+static inline lwc_string *
+lwc_string_ref(lwc_string *str)
+{
+ str->refcnt++;
+ return str;
+}

/**
* Release a reference on an lwc_string.
@@ -177,32 +182,6 @@
((*(ret) = ((str1) == (str2))), lwc_error_ok)

/**
- * Check if two interned strings are case-insensitively equal.
- *
- * @param _str1 The first string in the comparison.
- * @param _str2 The second string in the comparison.
- * @param _ret A pointer to a boolean to be filled out with the result.
- * @return Result of operation, if not ok then value pointed to by \a ret will
- * not be valid.
- */
-#define lwc_string_caseless_isequal(_str1,_str2,_ret) ({ \
- lwc_error __lwc_err = lwc_error_ok; \
- lwc_string *__lwc_str1 = (_str1); \
- lwc_string *__lwc_str2 = (_str2); \
- bool *__lwc_ret = (_ret); \
- \
- if (__lwc_str1->insensitive == NULL) { \
- __lwc_err = lwc__intern_caseless_string(__lwc_str1); \
- } \
- if (__lwc_err == lwc_error_ok && __lwc_str2->insensitive == NULL) { \
- __lwc_err = lwc__intern_caseless_string(__lwc_str2); \
- } \
- if (__lwc_err == lwc_error_ok) \
- *__lwc_ret = (__lwc_str1->insensitive == __lwc_str2->insensitive); \
- __lwc_err; \
- })
-
-/**
* Intern a caseless copy of the passed string.
*
* @param str The string to intern the caseless copy of.
@@ -215,6 +194,30 @@
*/
extern lwc_error
lwc__intern_caseless_string(lwc_string *str);
+
+/**
+ * Check if two interned strings are case-insensitively equal.
+ *
+ * @param _str1 The first string in the comparison.
+ * @param _str2 The second string in the comparison.
+ * @param _ret A pointer to a boolean to be filled out with the result.
+ * @return Result of operation, if not ok then value pointed to by \a ret will
+ * not be valid.
+ */
+static inline lwc_error
+lwc_string_caseless_isequal(lwc_string *str1, lwc_string *str2, bool *ret)
+{
+ lwc_error err = lwc_error_ok;
+ if (str1->insensitive == NULL) {
+ err = lwc__intern_caseless_string(str1);
+ }
+ if (err == lwc_error_ok && str2->insensitive == NULL) {
+ err = lwc__intern_caseless_string(str2);
+ }
+ if (err == lwc_error_ok)
+ *ret = (str1->insensitive == str2->insensitive);
+ return err;
+}

/**
* Retrieve the data pointer for an interned string.
@@ -228,7 +231,7 @@
* in future. Any code relying on it currently should be
* modified to use ::lwc_string_length if possible.
*/
-#define lwc_string_data(str) ({assert(str != NULL); (const char *)((str)+1);})
+#define lwc_string_data(str) ((const char *)((str)+1))

/**
* Retrieve the data length for an interned string.
@@ -236,7 +239,7 @@
* @param str The string to retrieve the length of.
* @return The length of \a str.
*/
-#define lwc_string_length(str) ({assert(str != NULL); (str)->len;})
+#define lwc_string_length(str) ((str)->len)

/**
* Retrieve (or compute if unavailable) a hash value for the content of the string.
@@ -250,7 +253,7 @@
* to be stable between invocations of the program. Never use the hash
* value as a way to directly identify the value of the string.
*/
-#define lwc_string_hash_value(str) ({assert(str != NULL); (str)->hash;})
+#define lwc_string_hash_value(str) ((str)->hash)

/**
* Retrieve a hash value for the caseless content of the string.
@@ -260,8 +263,8 @@
* @return Result of operation, if not ok then value pointed to by \a ret will
* not be valid.
*/
-static inline lwc_error lwc_string_caseless_hash_value(
- lwc_string *str, lwc_hash *hash)
+static inline lwc_error
+lwc_string_caseless_hash_value(lwc_string *str, lwc_hash *hash)
{
if (str->insensitive == NULL) {
lwc_error err = lwc__intern_caseless_string(str);

Re: [Rpcemu] RPCEmu macOS mouse behaviour

On 23 Mar 2020, at 9:14, Peter Howkins wrote:

> You correctly note we use a heuristic to determine eigen values for
> the display and mouse. Eigen values are entirely a RISC OS concept,
> the VIDC hardware doesn't know about them.

Thanks for taking the time to write up such a detailed response. It's
very useful to understand the thinking and design behind that particular
code section. As far as EX0/EY0 goes, it is a difficult problem; the
scaling is only known to the OS and the emulator can't restrict itself
to specific OS versions or related assumptions. It's quite common for
VMWare / Parallels-like VM solutions to include hosted-OS software that
you install within the VM environment which allow the host OS and hosted
OS to communicate - perhaps one day we might e.g. have a RISC OS module
compatible with as wide-as-possible a range of RISC OS versions that
communicates useful settings like eigenvalues through to the emulator.

In view of everything you've said, it might be that the patch I've been
using isn't a great idea, though it is *only* having any effect when
"mousehack" has been configured 'on' by the user. Tim's discovery of the
accessibility features setting gives away what must've been going on
with the UUID variations in behaviour. That said, under Linux we also
see the exact same behaviour and the "mousehack" mode plus patch does
seem to do the trick there too. It is definitely advantageous to be able
to access the menu bar and get out of full screen mode in Mac OS, and
advantageous to be able to thereafter scale the RPCEmu window and have
the mouse coordinates still correctly mapped.

It's excellent to hear that at last for Mac OS, we can use the
accessibility features setting to get things working in non-hack mode.
For those using multiple binaries or on Linux, perhaps the patch will be
a benefit.

Sorry to those who spotted there was no patch attached to my original
message. I *did* attach it, but suspect the mailing list software
rejected a ".patch" attachment. Since Tim's had success with a ".zip"
file, I've attached it again, ZIPped up this time. Fingers crossed.

--
Andrew Hodgkinson
RISC OS Open Limited
http://www.riscosopen.org/

Re: Atari build 5032: cache folder

On Mon, 9 Mar 2020 19:54:06 , Peter Slegg <pslegg@scubadivers.co.uk> wrote:
> Hi Vido,
>
> From a quick look at the commit, I think if there is any issue
> with the cache it deletes it.
>
> http://git.netsurf-browser.org/netsurf.git/commit/?id=14286b381b12034140768800c7ba10baa7c3b334
>
> I suspect it cannot create it again for some reason.
>
> Peter
>

I have a vague memory of a similar issue several years ago in the
Atari build. A file or folder that was not created when needed.
It had to be created manually.

Could this be a general problem with the way Netsurf creates files
or folders in the Atari build ?

Peter

Re: [Rpcemu] RPCEmu macOS mouse behaviour

On Sun, 22 Mar 2020 at 21:15, Timothy Coltman <lists@maemagel.com> wrote:

Peter - in full screen (2560x1600), using a RISC OS resolution of 800x600, it does seem like I have to move the mouse quite a lot on my desk to get it to move a short distance on screen.  Andrew's comment about it not scaling between host and RISC OS coordinates does look to be correct.

Ah, if it were not clear from previously, full screen is using the full OS code for mouse handling. As such changing the mouse speed in !Configure will likely see this speed up to usable.

Peter

Re: [Rpcemu] RPCEmu macOS mouse behaviour



On 22 Mar 2020, at 20:14, Peter Howkins <rpcemu.howkins@marutan.net> wrote:


On Sun, 22 Mar 2020 at 09:40, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
The root problem is within quite strange (I'm being super polite here) mouse handling code.

I think the more fundamental issue is that you have issues with your Mac setup or build system. You are right that two builds with different UUIDs should not behave differently, but that they do should be investigated. If I were thinking to diagnose the problem, I'd try the following;

1) Take the working and non working builds to a different Mac and run them there

 a) If both builds no longer work in full screen, that suggests that Mac OS stores some meta-data related to UUID and that there's a difference in settings between the two builds. Finding these settings, understanding them and possibly setting them on the new build will solve this issue.
 
 b) If the builds work and don't in the same way as your other Mac, that suggests there's some hard-coded Mac OS workaround for that particular UUID. If you can't find out why, the quick and dirty workaround is to set the new build UUID to the same as the old.
 
I do not have a Mac so cannot suggest anything more specific than to stop trying to work around the issue in the RPCEmu code.


I've been doing some playing around, and have got RPCEmu to work on a Mac (10.14.6) in capture mouse mode, unaltered.  The key is go to into System Preferences > Security and Privacy > Accessibility and to add the application in there ("Allow the apps below to control your computer").

You can only add the application in once, so if you have more than one version lying around, or multiple builds (recompiler, interpreter, release, debug), only one will work.  If you want to switch between recompiler/interpreter/Mac patch V3/Mac patch V4/Andrew's patch/David's patch/your own build/etc, you need to remove anything RPCEmu from this list and then re-add it.  

Quick survey: does anyone using the Mac version switch regularly between interpreter and recompiler?

If you run the application without RPCEmu being listed in the "control your computer" list and turn on capture mouse (or just click in the window if it's already active), you should get a prompt appear that tells you that RPCEmu wants to "control this computer using accessibility features".  Click on the "Open System Preferences" button and it'll open the appropriate location in System Preferences and add RPCEmu to the list.  All that you need to do is tick it.  If you then return to the emulator, the mouse should work as Peter describes.

There does seem to be something slightly weird happening, in that it may not list the application under the correct name.  I added a recompiler/debug build, having previously had interpreter/debug listed, and RPCEmu is still listed as "rpcemu-interpreter-debug".  Despite that, it does work fine (at least until I change to another variant).

Peter - in full screen (2560x1600), using a RISC OS resolution of 800x600, it does seem like I have to move the mouse quite a lot on my desk to get it to move a short distance on screen.  Andrew's comment about it not scaling between host and RISC OS coordinates does look to be correct.

From a Mac point of view, I think it's worth changing the magic key combination to something other than CTRL+END to make things easier for laptop users (I develop/test on a desktop).  VMware Fusion uses Ctrl+Command, so I may steal that.

Tim

Re: [Rpcemu] RPCEmu macOS mouse behaviour


On Sun, 22 Mar 2020 at 09:40, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
The root problem is within quite strange (I'm being super polite here) mouse handling code.

I think the more fundamental issue is that you have issues with your Mac setup or build system. You are right that two builds with different UUIDs should not behave differently, but that they do should be investigated. If I were thinking to diagnose the problem, I'd try the following;

1) Take the working and non working builds to a different Mac and run them there

 a) If both builds no longer work in full screen, that suggests that Mac OS stores some meta-data related to UUID and that there's a difference in settings between the two builds. Finding these settings, understanding them and possibly setting them on the new build will solve this issue.
 
 b) If the builds work and don't in the same way as your other Mac, that suggests there's some hard-coded Mac OS workaround for that particular UUID. If you can't find out why, the quick and dirty workaround is to set the new build UUID to the same as the old.
 
I do not have a Mac so cannot suggest anything more specific than to stop trying to work around the issue in the RPCEmu code.



However here is a quick mouse code primer for those interested.

RPCEmu uses two different sets of mouse handling code

1) "Capture Mouse" also used in "Full Screen" mode. Data from the Host OS is fed into the relevant hardware registers (quadrature/ps2) of the IOMD which RISC OS (or any other OS) interprets and moves its mouse.

The data injected is 'relative' coordinates from the Host OS, the amount moved since the last time the 'mouse' was polled. Real mice only work on relative movements as they have no concept of the displays they are running on.

To do this in RPCEmu, the host mouse pointer is hidden, moved to centre of the window, each time the mouse is polled the difference from that centre point is recorded and fed into the emulator, and the mouse moved back to the centre again. (The mouse keeps being moved back to the centre, as we only receive Host OS 'mouse move' events if the host pointer is over the RPCEmu window)

2) "Follow Host Mouse". Known internally (and for very good reason) as "mousehack". RISC OS specific and whilst considerably better than it was (6 major bugs in the last 10 years) it still may have issues for yet to be discovered usages of the RISC OS mouse API.

It works by intercepting Mouse SWIs used in RISC OS and directly injecting results from the Host OS into the return values. It bypasses all of RISC OS's low level handing of the mouse hardware.

The data injected in the return values of the SWIs are absolute values (Host units converted for OS units, eigen values, and the fact the Y axis goes the other way) as those are what the systems calling those SWIs expect.

Please note, "mousehack" still requires the support of the Host OS to move the Host mouse pointer, as this is used when RISC OS uses a 'mouse bounding box' such as error boxes that constrain the pointer to the error box.

You correctly note we use a heuristic to determine eigen values for the display and mouse. Eigen values are entirely a RISC OS concept, the VIDC hardware doesn't know about them.


Peter

Re: [Rpcemu] RPCEmu macOS mouse behaviour

In message <2F6A18EE-73A1-4B4D-B486-3D27CBED5E10@maemagel.com>
Timothy Coltman <lists@maemagel.com> wrote:


>> On 22 Mar 2020, at 09:40, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:

[snip]

>> Source code alludes to bugs in follow-host mode that should give the
>> user a preference for turning this off, but at least on macOS the
>> opposite seems quite strongly true. So I've attached a patch:
>>

> I seem to be missing the patch attachment. Does it show up for anyone else?

There is no patch here either.
--
David Pitt
Titanium

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu macOS mouse behaviour

> On 22 Mar 2020, at 09:40, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
>
> On 19/03/2020, at 08:22, Timothy Coltman <lists@maemagel.com> wrote:
>
>
> The root problem is within quite strange (I'm being super polite here) mouse handling code.
>
> In mainwindow.cpp on non-follow-host mode, the strategy appears to be to try and force the host mouse pointer into the centre of the window, then measure a distance from that and pass it to lower layers. Lower layers appear to be expecting only a difference since the last RISC OS position update though, not a distance-from-centre, so things get out of hand quickly.
>
> I can't honestly see how the non-follow-host code works on *any* platform and have no idea how I ended up with a magic Mac binary that did. Perhaps it requires a Qt build which *does not* properly support move-mouse-cursor, so move-to-centre is ignored and the differential position logic calculates correct positions by accident?

I had a play around with the source, and I don't think that mouse positioning works on macOS. I've not tried any other platforms.

>
> Source code alludes to bugs in follow-host mode that should give the user a preference for turning this off, but at least on macOS the opposite seems quite strongly true. So I've attached a patch:
>

I seem to be missing the patch attachment. Does it show up for anyone else?

Tim




_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu macOS mouse behaviour

On 19/03/2020, at 08:22, Timothy Coltman <lists@maemagel.com> wrote:

> Same happens here, with my development version of RPCEmu, which is based on 0.9.2. The mouse doesn't seem to move at all, though the keyboard is fine (so I can exit back to full-screen mode). This is an iMac with 10.14.6.

The root problem is within quite strange (I'm being super polite here) mouse handling code.

In mainwindow.cpp on non-follow-host mode, the strategy appears to be to try and force the host mouse pointer into the centre of the window, then measure a distance from that and pass it to lower layers. Lower layers appear to be expecting only a difference since the last RISC OS position update though, not a distance-from-centre, so things get out of hand quickly.

I can't honestly see how the non-follow-host code works on *any* platform and have no idea how I ended up with a magic Mac binary that did. Perhaps it requires a Qt build which *does not* properly support move-mouse-cursor, so move-to-centre is ignored and the differential position logic calculates correct positions by accident?

If I modify the code to allow follow-host mode in full screen, the most noticeable issues are around the host mouse being able to move around the full host screen area (e.g. 2560x1600 on this big screen in front of me) while the RISC OS emulation might be set to something much smaller (e.g. 1024x768). This means you can "move off the edges" of the RISC OS screen and have to move an invisible host mouse pointer back into the 1024x768 region before the RISC OS mouse picks up and starts tracking it again. RPCEmu simply does not attempt any scaling between host and RISC OS mouse coordinates.

That bug aside, there is a lot of better stuff going on when follow-host is used - not least being able to access the menu under macOS, including getting at the window 'traffic light' controls which means you can exit full screen without needing Ctrl+End - useful on any Mac laptop, since they don't have "End" keys!

Source code alludes to bugs in follow-host mode that should give the user a preference for turning this off, but at least on macOS the opposite seems quite strongly true. So I've attached a patch:

* If you're in follows-host-mode ("mousehackon") it stays that way in full screen
* The window pixel size is scaled to the RISC OS screen size so that the mouse pointer boundaries work properly
* Added bonus, you can resize the RPCEmu window to scale the RISC OS desktop within & the mouse still works
* Yes, I've accounted for EX2/EY2 doubling logic so e.g. mode 12 or mode 9 work fine

I note with a little sadness that the internal VIDC emulation does not appear to have a proper concept of eigenvalues and basically hacks EX2/EY2 using hard-coded logic and pixel dimension thresholds. This makes it prohibitively difficult to implement correct mouse pointer behaviour in EX0/EY0 modes, which is a shame. A full screen mode on a Retina Mac in EX0/EY0 would be a realisation of a dream we had at Acorn way-back-when we did the whole EX0 sprites support stuff in the first place.

This patch conflicts on one hunk with your V4 macOS patch, Tim, so mine includes an equivalent change in itself allowing the macOS patch hunk in question to fail safely. Apply this first, then your Mac patch.

The ROOL USB stick build will include all this.

--
Andrew Hodgkinson
RISC OS Open Limited
https://www.riscosopen.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Friday, 20 March 2020

Re: [gccsdk] Is it time for a new version of GCC4?

From what I can see, gnu no longer do svn, just git. I have used the following to checkout 4.7.4.. needs adding in the relevant place in the makefile I guess

git clone https://gcc.gnu.org/git/gcc.git gcc4 && cd gcc4 && git checkout releases/gcc-4.7.4 && cd ..

If you can find a svn for 4.7.4 perhaps you could let me know?

For now I'm just getting the source tar that gccsdk has

JB

On 20/03/2020 16:58, alan buckley wrote:

Lee Noar wrote on  19 March 2020 15:33
To: Alan; gcc@gccsdk.riscos.info
Subject: Re: [gccsdk] Is it time for a new version of GCC4?

 

> On 17/03/2020 17:11, Alan wrote:
> > On 16/03/2020 15:44, Lee Noar wrote:

> > I know a month ago GCC4 didn't build as I tried it on another machine.

> Do you remember why? I'm building on Kubuntu 19.10 and didn't
> encounter any major issues. I had to install the rename utility
> for the header suffix swap in the native build.

 

It failed for me again last night after an svn update, but I didn't make a note

of the problem as I decided to delete it all and try again. Unfortunately the

svn checkout of the gnu trunk code is failing today. I'll try again over the weekend.

 

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
--
Stop press! Just announced -

Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile

For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761

Intrigued? Call me

John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923

Re: [gccsdk] Is it time for a new version of GCC4?

Lee Noar wrote on  19 March 2020 15:33
To: Alan; gcc@gccsdk.riscos.info
Subject: Re: [gccsdk] Is it time for a new version of GCC4?

 

> On 17/03/2020 17:11, Alan wrote:
> > On 16/03/2020 15:44, Lee Noar wrote:

> > I know a month ago GCC4 didn't build as I tried it on another machine.

> Do you remember why? I'm building on Kubuntu 19.10 and didn't
> encounter any major issues. I had to install the rename utility
> for the header suffix swap in the native build.

 

It failed for me again last night after an svn update, but I didn't make a note

of the problem as I decided to delete it all and try again. Unfortunately the

svn checkout of the gnu trunk code is failing today. I'll try again over the weekend.

 

Regards,

Alan

Thursday, 19 March 2020

Re: [gccsdk] Is it time for a new version of GCC4?

Lee that is great news many thanks for your hard work. Fortran is very useful for engineering applications and to be able to run it on RISC OS is a big bonus. Especially with all the powerful platforms now available. 😊

On Fri., 20 Mar. 2020, 07:01 Lee Noar, <lee.noar@sky.com> wrote:
On 17/03/2020 08:22, Norman Lawrence wrote:
> Hi Lee Is there any chance to include fortran in the build?  I do
> not have the skills to do it myself but I would be happy to trial out
> the fortran build.

I've now added the fortran compiler and runtime library to the cross
compiler. I'm not familiar with fortran, but I was able to build a
simple helloworld test program and run the result on RISC OS (after
installing the libgfortran runtime shared library).
The compiler's name is arm-riscos-gnueabihf-gfortran.

Lee.

Re: [gccsdk] Is it time for a new version of GCC4?

Hi Lee,

> Lee Noar <lee.noar@sky.com> wrote:
>
> I've now added the fortran compiler and runtime library to the cross
> compiler. I'm not familiar with fortran, but I was able to build a
> simple helloworld test program and run the result on RISC OS (after
> installing the libgfortran runtime shared library).
> The compiler's name is arm-riscos-gnueabihf-gfortran.

Oh, you're having a run of luck? Maybe you could also try to add GNAT? I promise I won't ask for working support for tasking :-)

Although ISTR that there were incompatibilities between that version of GCC, GNAT and the ARM backend.

Thanks
Steffen aka hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

_______________________________________________
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] Is it time for a new version of GCC4?

On 17/03/2020 08:22, Norman Lawrence wrote:
> Hi Lee Is there any chance to include fortran in the build? I do
> not have the skills to do it myself but I would be happy to trial out
> the fortran build.

I've now added the fortran compiler and runtime library to the cross
compiler. I'm not familiar with fortran, but I was able to build a
simple helloworld test program and run the result on RISC OS (after
installing the libgfortran runtime shared library).
The compiler's name is arm-riscos-gnueabihf-gfortran.

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] Is it time for a new version of GCC4?

On 17/03/2020 17:11, Alan wrote:
> On 16/03/2020 15:44, Lee Noar wrote:
>
>>> The RISC OS packages have a new environment field and I'd like to add
>>> them to the GCC4 packages. I've noticed some useful work has been done
>>> in GCC 4 so it would be nice to get this included as well.
>>>
>>> I'm happy to have a go at building and packaging the latest GCC4, but
>>> before I do I want to check the current status.
>>>
>>> Is it stable at the moment or are some new changes about to go in?
>>
>> I do have some changes to commit to Unixlib and I need to check that
>> GCC4 still builds and runs correctly. Admittedly, I have neglected GCC4
>> recently in favour of GCC8, so all the testing I've been doing is with
>> the GCC8 build (autobuilder/develop/gcc).
>>
> Let me know when you've done what you need to for GCC4 and I'll go
> ahead and build and package the new version.

Ok, I think that's everything. If you could try building it and let
me know how you go.

> There's no desperate rush as long as it's not 3 months away:-)

Not quite 3 months :-)

> I know a month ago GCC4 didn't build as I tried it on another machine.

Do you remember why? I'm building on Kubuntu 19.10 and didn't
encounter any major issues. I had to install the rename utility
for the header suffix swap in the native build.

> I'm really intrigued about GCC8, but I'm being patient and waiting for
> more information to be "officially" released on it.

I'll look at building a native version.

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] Is it time for a new version of GCC4?

On 17/03/2020 08:22, Norman Lawrence wrote:
> Hi Lee
> Is there any chance to include fortran in the build?  I do not have the
> skills to do it myself but I would be happy to trial out the fortran build.

I'll see what I can do.

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

Wednesday, 18 March 2020

Re: [Rpcemu] RPCEmu macOS mouse behaviour

> On 18 Mar 2020, at 09:00, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
>
> One application was built a while ago, the other recently. When I run the old one, mouse pointer movement is fine. When I run the new, mouse pointer movement only works in "follow host" mode. In capture mode (and thus in full screen too), the mouse is unusable - the pointer jumps around all over the place.

Same happens here, with my development version of RPCEmu, which is based on 0.9.2. The mouse doesn't seem to move at all, though the keyboard is fine (so I can exit back to full-screen mode). This is an iMac with 10.14.6.

Tim


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: No more available space

On Wed, Mar 18, 2020 at 12:03:04 +0000, Gavin Wraith wrote:
> I am using NetSurf 3.9 from the RODirect version of RO 5.26.
> When I try to download newer builds from
> https://ci.netsurf-browser.org/builds/riscos/
> it says "The disc has no more available space". This is nonsense,
> there are gigabytes available.
> Can anyone diagnose what is going on here?

Can you please enable logging and provide a log? Also is your scratch
directory full?

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

No more available space

I am using NetSurf 3.9 from the RODirect version of RO 5.26.
When I try to download newer builds from
https://ci.netsurf-browser.org/builds/riscos/
it says "The disc has no more available space". This is nonsense,
there are gigabytes available.
Can anyone diagnose what is going on here?
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Re: [gccsdk] Is it time for a new version of GCC4?

In message <AM0PR0102MB35087A67040F9D971206152DF0F60@AM0PR0102MB3508.e
urprd01.prod.exchangelabs.com>
Alan <alan_baa@hotmail.com> wrote:

> On 16/03/2020 15:44, Lee Noar wrote:

[snip]

>> I do have some changes to commit to Unixlib and I need to check that
>> GCC4 still builds and runs correctly. Admittedly, I have neglected GCC4
>> recently in favour of GCC8, so all the testing I've been doing is with
>> the GCC8 build (autobuilder/develop/gcc).
>>
> Let me know when you've done what you need to for GCC4 and I'll go

> ahead and build and package the new version. There's no desperate

> rush as long as it's not 3 months away:-)

> I know a month ago GCC4 didn't build as I tried it on another machine.

GCC4 builds here now, and also built here on 13Jan20, on Ubuntu 19.10.
The build runs on the Titanium as very briefly tested with c and c++
Hello Worlds.

SharedUnixLibrary is 1.15.

Shared Object Manager is at 3.01. This requires the new ARMEABISupport
module provided in 500.Modules which is not currently rmensured
anywhere. SOM1stRun?

HTH.

--
David Pitt
Titanium

_______________________________________________
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

[Rpcemu] RPCEmu macOS mouse behaviour

Hi, I've a curious issue with RPCEmu on macOS X (10.14.6) and wonder if anyone has any ideas.

I have two builds, which are *binary identical* except for the main executable's Mach-O UUID and a small part of a plain text string where it looks like some kind of "about" message is having today's date dynamically inserted during building.

One application was built a while ago, the other recently. When I run the old one, mouse pointer movement is fine. When I run the new, mouse pointer movement only works in "follow host" mode. In capture mode (and thus in full screen too), the mouse is unusable - the pointer jumps around all over the place.

The binaries in question are dynamically linking to the same libraries - they're bit-identical but for the UUID and small amount of text as noted. I tried patching the faulty library to see what would happen. All I did first was copy over the 16 UUID bytes from the working copy, to the errant newer copy. That was enough; the newer copy's mouse starts to work. Undo the change; broken mouse. Redo the change; working mouse.

This sounds kinda like crazy talk, yet that's what is happening. FWIW, the working UUID is 5B4AC336-1C1F-3897-88E1-0836AF1DE484 and the broken UUID is - well - anything else.

The UUID shouldn't be used for anything functional at all surely, so how come these otherwise identical binaries behave so differently based on just this thing alone? Some hidden preference/setting somewhere that Mac OS has keyed into the UUID? All configuration data etc. is (obviously) the same (since the application bundles *appear to be* bit-for-bit identical except as noted). Mach-O linker cache of some kind maybe?

Even stranger, a colleague is having issues with Linux behaving the same way. Only the "follow host" mouse mode works. No Mach-O binary UUIDs there :-) so it might be a totally different issue, or perhaps it's actually the same root cause; something in the config or build, which I just can't fathom. Another build for Windows runs fine. Qt library versions don't seem to matter much. The working Windows 7 and 10 builds are on 5.9.5, the non-working Linux build uses 5.9.8 and the Mac builds I have are both dynamically linking against Homebrew-installed 5.14.1, which means it both works and doesn't work on that version. Again, the only thing that seems to fix it is the UUID burned into the binary.

Wut.

TIA! :-)

--
Andrew Hodgkinson
RISC OS Open Limited
https://www.riscosopen.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Tuesday, 17 March 2020

Re: [gccsdk] Is it time for a new version of GCC4?

On 16/03/2020 15:44, Lee Noar wrote:

>> The RISC OS packages have a new environment field and I'd like to add
>> them to the GCC4 packages. I've noticed some useful work has been done
>> in GCC 4 so it would be nice to get this included as well.
>>
>> I'm happy to have a go at building and packaging the latest GCC4, but
>> before I do I want to check the current status.
>>
>> Is it stable at the moment or are some new changes about to go in?
>
> I do have some changes to commit to Unixlib and I need to check that
> GCC4 still builds and runs correctly. Admittedly, I have neglected GCC4
> recently in favour of GCC8, so all the testing I've been doing is with
> the GCC8 build (autobuilder/develop/gcc).
>
Let me know when you've done what you need to for GCC4 and I'll go

ahead and build and package the new version. There's no desperate

rush as long as it's not 3 months away:-)

I know a month ago GCC4 didn't build as I tried it on another machine.

I'm really intrigued about GCC8, but I'm being patient and waiting for

more information to be "officially" released on it.

>> Is the SharedUnixLibrary 1.15 ready to go?
>
> Yes, that change was to improve clean up on program exit with
> shared libraries and GCC 8.
>
Excellent, I'll package this when I do GCC4
>> When packaging the shared library versions of the libraries that go with
>> it has the ABI changed so they need to be packaged as new ABI versions?
>
> GCC4 is still "abi-2.0", GCC8 is "armeabihf".
>
That's good.
> Lee.
>
Thanks,

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] Is it time for a new version of GCC4?

Hi Lee
Is there any chance to include fortran in the build?  I do not have the skills to do it myself but I would be happy to trial out the fortran build.  

Best wishes
Norman

On Tue, 17 Mar 2020 at 02:45, Lee Noar <lee.noar@sky.com> wrote:
> The RISC OS packages have a new environment field and I'd like to add
> them to the GCC4 packages. I've noticed some useful work has been done
> in GCC 4 so it would be nice to get this included as well.
>
> I'm happy to have a go at building and packaging the latest GCC4, but
> before I do I want to check the current status.
>
> Is it stable at the moment or are some new changes about to go in?

I do have some changes to commit to Unixlib and I need to check that
GCC4 still builds and runs correctly. Admittedly, I have neglected GCC4
recently in favour of GCC8, so all the testing I've been doing is with
the GCC8 build (autobuilder/develop/gcc).

> Is the SharedUnixLibrary 1.15 ready to go?

Yes, that change was to improve clean up on program exit with
shared libraries and GCC 8.

> When packaging the shared library versions of the libraries that go with
> it has the ABI changed so they need to be packaged as new ABI versions?

GCC4 is still "abi-2.0", GCC8 is "armeabihf".

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