>> If the page specifies colours then they will be used by NetSurf -
>> there's no way of overriding them [...]. I'm not sure how you'd
>> even go about implementing this.
Personally? My first reaction is to look at the display code and have
it used fixed colours instead of the colours that come from the page,
from the default CSS, from wherever.
That probably wouldn't be the best answer; it's just the most obvious
answer that occurs to me.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Saturday, 30 July 2022
Re: Possible to get it out of reverse video?
[forwarded from Chris Young, as I didn't see the CC'd message turn up on
the list]
---------- Begin forwarded message ----------
Date: Fri, 29 Jul 2022 15:08:46 +0100
From: Chris Young <cdyoung@gmail.com>
To: Harriet Bazley <lists@bazleyfamily.co.uk>
CC: netsurf-users@netsurf-browser.org
Subject: Re: Possible to get it out of reverse video?
>
>
> I'm struggling to post to this list, so hopefully this will work.
>
> Harriet Bazley wrote:
> > Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
> > force HTML pages to change their colour scheme. It doesn't offer all
> > that many customisations anyway (you can't even tell it not to load
> > images, so far as I'm aware). I think it was mainly written to be
> > small and fast, rather than highly flexible.
>
> There is a media query which allows a web browser to pick up the preferred
> colour scheme (light mode/dark mode) from the OS (or the browser itself).
> NetSurf does not implement this, so everything defaults to light mode.
>
> That would help with sites which support dark mode (via the media query or
> otherwise), however still leaves the rest of the web in light mode.
>
> You can change the default CSS but it is only going to help if the page
> itself doesn't specify colours.
>
> If the page specifies colours then they will be used by NetSurf - there's
> no way of overriding them (beyond light mode/dark mode - and even then
> you're still using colours specified by the page). I'm not sure how you'd
> even go about implementing this.
>
----------- End forwarded message -----------
--
Harriet Bazley == Loyaulte me lie ==
Nostalgia isn't what it used to be.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
the list]
---------- Begin forwarded message ----------
Date: Fri, 29 Jul 2022 15:08:46 +0100
From: Chris Young <cdyoung@gmail.com>
To: Harriet Bazley <lists@bazleyfamily.co.uk>
CC: netsurf-users@netsurf-browser.org
Subject: Re: Possible to get it out of reverse video?
>
>
> I'm struggling to post to this list, so hopefully this will work.
>
> Harriet Bazley wrote:
> > Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
> > force HTML pages to change their colour scheme. It doesn't offer all
> > that many customisations anyway (you can't even tell it not to load
> > images, so far as I'm aware). I think it was mainly written to be
> > small and fast, rather than highly flexible.
>
> There is a media query which allows a web browser to pick up the preferred
> colour scheme (light mode/dark mode) from the OS (or the browser itself).
> NetSurf does not implement this, so everything defaults to light mode.
>
> That would help with sites which support dark mode (via the media query or
> otherwise), however still leaves the rest of the web in light mode.
>
> You can change the default CSS but it is only going to help if the page
> itself doesn't specify colours.
>
> If the page specifies colours then they will be used by NetSurf - there's
> no way of overriding them (beyond light mode/dark mode - and even then
> you're still using colours specified by the page). I'm not sure how you'd
> even go about implementing this.
>
----------- End forwarded message -----------
--
Harriet Bazley == Loyaulte me lie ==
Nostalgia isn't what it used to be.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Friday, 29 July 2022
Re: Possible to get it out of reverse video?
I'm struggling to post to this list, so hopefully this will work.
Harriet Bazley wrote:
> Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
> force HTML pages to change their colour scheme. It doesn't offer all
> that many customisations anyway (you can't even tell it not to load
> images, so far as I'm aware). I think it was mainly written to be
> small and fast, rather than highly flexible.
There is a media query which allows a web browser to pick up the preferred colour scheme (light mode/dark mode) from the OS (or the browser itself). NetSurf does not implement this, so everything defaults to light mode.
That would help with sites which support dark mode (via the media query or otherwise), however still leaves the rest of the web in light mode.
You can change the default CSS but it is only going to help if the page itself doesn't specify colours.
If the page specifies colours then they will be used by NetSurf - there's no way of overriding them (beyond light mode/dark mode - and even then you're still using colours specified by the page). I'm not sure how you'd even go about implementing this.
Re: Possible to get it out of reverse video?
>> (I wouldn't even _want_ to override the page's colours, except that
>> most pages actively specify reverse-video colours. I don't
>> understand why.)
> So by 'reverse video' you mean DTP-style display, with dark text on a
> white page? Yes, that is the default for everything other than
> terminal-style screens (which I now understand is what you are trying
> to emulate).
Well, I wouldn't put it that way. I like it not because that's how
text terminals worked; I like it because I'm using self-luminant
displays, displays that give off light of their own (as opposed to
reflective displays, which reflect ambient light rather than generating
their own light). Text terminals also use - used, I guess I should say
these days - self-luminant displays, so light-on-dark made sense for
them just as much as it does for me now.
> Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
> force HTML pages to change their colour scheme.
Oh well. At least I don't need to struggle with it trying to find such
a mechanism, then. Thank you!
> So there probably isn't any way of getting it to meet your needs.
> (Though I'm not a developer and don't know what is actually
> possible!)
Well, of course, I could fetch the source and hack on that. I've been
hesitant to try that, expecting that understanding it enough to make
those changes would take longer than finding some other way to address
the issue...though I'm having enough trouble finding a suitable browser
for that system that I'm beginning to wonder if maybe I won't have to
do something like that with _some_ browser.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
>> most pages actively specify reverse-video colours. I don't
>> understand why.)
> So by 'reverse video' you mean DTP-style display, with dark text on a
> white page? Yes, that is the default for everything other than
> terminal-style screens (which I now understand is what you are trying
> to emulate).
Well, I wouldn't put it that way. I like it not because that's how
text terminals worked; I like it because I'm using self-luminant
displays, displays that give off light of their own (as opposed to
reflective displays, which reflect ambient light rather than generating
their own light). Text terminals also use - used, I guess I should say
these days - self-luminant displays, so light-on-dark made sense for
them just as much as it does for me now.
> Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
> force HTML pages to change their colour scheme.
Oh well. At least I don't need to struggle with it trying to find such
a mechanism, then. Thank you!
> So there probably isn't any way of getting it to meet your needs.
> (Though I'm not a developer and don't know what is actually
> possible!)
Well, of course, I could fetch the source and hack on that. I've been
hesitant to try that, expecting that understanding it enough to make
those changes would take longer than finding some other way to address
the issue...though I'm having enough trouble finding a suitable browser
for that system that I'm beginning to wonder if maybe I won't have to
do something like that with _some_ browser.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Re: Possible to get it out of reverse video?
On 28 Jul 2022 as I do recall,
Mouse wrote:
> >> [I tried netsurf]. As I have, unfortunately, come to expect from
> >> almost everything, it defaulted to reverse video. [...]
>
> > [default CSS] To be honest I don't know that this would override the
> > colours set up in the page [...]
>
> I wouldn't expect default CSS to override the page's colours. That's
> what defaults are all about, after all.
I can't think of any other way of doing it in Netsurf (and I didn't test
that suggestion, so I don't even know if it would have worked
anyway....)
> (I wouldn't even _want_ to override the page's colours, except that
> most pages actively specify reverse-video colours. I don't understand
> why.)
So by 'reverse video' you mean DTP-style display, with dark text on a
white page? Yes, that is the default for everything other than
terminal-style screens (which I now understand is what you are trying to
emulate).
StrongED (bitmap display text editor) used to have a special 'inverse
video' light-on-dark colour option to emulate the old BBC Micro
programming display, but I can't even find that option in the latest
versions, and I don't know of any other application that offers it -
RISC OS has been using cream/white/grey backgrounds with lines drawn
over them as the default for all user interfaces since the desktop first
came in circa 1990, and it has never been terminal-based, so I'm afraid
applications originating in RISC OS simply don't take that type of
display into account. :-(
[snip]
> The "make it usable" part needs, of course, to have a "for me"
> qualifier attached; I had assumed that was implicitly understood here,
> as of course it should be for pretty much any user-usability issue. I
> suspect most people have become accustomed to having large areas of
> bright on their screens. Maybe they like eyestrain? [Only half
> sarcastic....]
I find that fine white lines against a dark background tend to dance
before my eyes - particularly obvious when graphics designers use this
style on printed pages (and even worse of course when they do it on a
*textured* background, which may look good on their monitors but is all
but unreadable in a colour magazine), but I just generated an HTML page
of Lorem ipsum using a white-on-black colour scheme, and it's pretty
hard to read in Netsurf. It probably depends on your OS/monitor set-up.
> Of course, it doesn't matter much what the defaults are, as long as
> it's easy to change them. It's the changing-them part that led me to
> write to the list.
Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
force HTML pages to change their colour scheme. It doesn't offer all
that many customisations anyway (you can't even tell it not to load
images, so far as I'm aware). I think it was mainly written to be
small and fast, rather than highly flexible.
So there probably isn't any way of getting it to meet your needs.
(Though I'm not a developer and don't know what is actually possible!)
--
Harriet Bazley == Loyaulte me lie ==
He who hesitates is last.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Mouse wrote:
> >> [I tried netsurf]. As I have, unfortunately, come to expect from
> >> almost everything, it defaulted to reverse video. [...]
>
> > [default CSS] To be honest I don't know that this would override the
> > colours set up in the page [...]
>
> I wouldn't expect default CSS to override the page's colours. That's
> what defaults are all about, after all.
I can't think of any other way of doing it in Netsurf (and I didn't test
that suggestion, so I don't even know if it would have worked
anyway....)
> (I wouldn't even _want_ to override the page's colours, except that
> most pages actively specify reverse-video colours. I don't understand
> why.)
So by 'reverse video' you mean DTP-style display, with dark text on a
white page? Yes, that is the default for everything other than
terminal-style screens (which I now understand is what you are trying to
emulate).
StrongED (bitmap display text editor) used to have a special 'inverse
video' light-on-dark colour option to emulate the old BBC Micro
programming display, but I can't even find that option in the latest
versions, and I don't know of any other application that offers it -
RISC OS has been using cream/white/grey backgrounds with lines drawn
over them as the default for all user interfaces since the desktop first
came in circa 1990, and it has never been terminal-based, so I'm afraid
applications originating in RISC OS simply don't take that type of
display into account. :-(
[snip]
> The "make it usable" part needs, of course, to have a "for me"
> qualifier attached; I had assumed that was implicitly understood here,
> as of course it should be for pretty much any user-usability issue. I
> suspect most people have become accustomed to having large areas of
> bright on their screens. Maybe they like eyestrain? [Only half
> sarcastic....]
I find that fine white lines against a dark background tend to dance
before my eyes - particularly obvious when graphics designers use this
style on printed pages (and even worse of course when they do it on a
*textured* background, which may look good on their monitors but is all
but unreadable in a colour magazine), but I just generated an HTML page
of Lorem ipsum using a white-on-black colour scheme, and it's pretty
hard to read in Netsurf. It probably depends on your OS/monitor set-up.
> Of course, it doesn't matter much what the defaults are, as long as
> it's easy to change them. It's the changing-them part that led me to
> write to the list.
Unfortunately I'm pretty sure Netsurf doesn't offer any mechanism to
force HTML pages to change their colour scheme. It doesn't offer all
that many customisations anyway (you can't even tell it not to load
images, so far as I'm aware). I think it was mainly written to be
small and fast, rather than highly flexible.
So there probably isn't any way of getting it to meet your needs.
(Though I'm not a developer and don't know what is actually possible!)
--
Harriet Bazley == Loyaulte me lie ==
He who hesitates is last.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Thursday, 28 July 2022
Re: Possible to get it out of reverse video?
>> [I tried netsurf]. As I have, unfortunately, come to expect from
>> almost everything, it defaulted to reverse video. [...]
> [default CSS] To be honest I don't know that this would override the
> colours set up in the page [...]
I wouldn't expect default CSS to override the page's colours. That's
what defaults are all about, after all. (I wouldn't even _want_ to
override the page's colours, except that most pages actively specify
reverse-video colours. I don't understand why.)
> I'd be rather concerned about why everything on your system is for
> some reason defaulting to inverse video and needs to be over-ridden
> to make it usable...
It defaults to reverse video presumably for the same reason everything
else does these days: that seems to be what most people have come to
expect. (It's baffling to me why; the one UX person I've spoken with
about the issue actually agreed with me.)
The "make it usable" part needs, of course, to have a "for me"
qualifier attached; I had assumed that was implicitly understood here,
as of course it should be for pretty much any user-usability issue. I
suspect most people have become accustomed to having large areas of
bright on their screens. Maybe they like eyestrain? [Only half
sarcastic....]
Of course, it doesn't matter much what the defaults are, as long as
it's easy to change them. It's the changing-them part that led me to
write to the list.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
>> almost everything, it defaulted to reverse video. [...]
> [default CSS] To be honest I don't know that this would override the
> colours set up in the page [...]
I wouldn't expect default CSS to override the page's colours. That's
what defaults are all about, after all. (I wouldn't even _want_ to
override the page's colours, except that most pages actively specify
reverse-video colours. I don't understand why.)
> I'd be rather concerned about why everything on your system is for
> some reason defaulting to inverse video and needs to be over-ridden
> to make it usable...
It defaults to reverse video presumably for the same reason everything
else does these days: that seems to be what most people have come to
expect. (It's baffling to me why; the one UX person I've spoken with
about the issue actually agreed with me.)
The "make it usable" part needs, of course, to have a "for me"
qualifier attached; I had assumed that was implicitly understood here,
as of course it should be for pretty much any user-usability issue. I
suspect most people have become accustomed to having large areas of
bright on their screens. Maybe they like eyestrain? [Only half
sarcastic....]
Of course, it doesn't matter much what the defaults are, as long as
it's easy to change them. It's the changing-them part that led me to
write to the list.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Re: Possible to get it out of reverse video?
On 28 Jul 2022 as I do recall,
Mouse wrote:
> I recently had occasion to set up a Linux - Debian - machine (for work,
> to be sure). I'm having trouble finding a Web browser I can stand to
> use.
>
> One of the ones I tried was netsurf (via apt-get install, installing
> netsurf-common and netsurf-gtk - the About window says "NetSurf 3.10
> (24th May 2020)"). As I have, unfortunately, come to expect from
> almost everything, it defaulted to reverse video. The notable part is
> that I was unable to find any way to change that; most of the browsers
> I've run into on Linux have had some way to configure colours, usually
> including a way to tell it "use these colours no matter what the page
> tries to set". With netsurf, though, I couldn't find even the former,
> much less the latter.
>
> Did I just miss something, or is netsurf not capable of being told what
> colours to use?
>
Netsurf has a default CSS file that sets up various colours, e.g.
ins { color: green; text-decoration: underline; }
I can't see that it explicitly sets the main body colour (although it
does for text areas), but you could presumably edit additional
definitions in. To be honest I don't know that this would override the
colours set up in the page that it is being asked to interpret, though.
It's not something that any RISC OS browser has ever been asked to do,
to my knowledge.
I'd be rather concerned about why everything on your system is for some
reason defaulting to inverse video and needs to be over-ridden to make
it usable...
--
Harriet Bazley == Loyaulte me lie ==
USER ERROR: replace user and press any key to continue.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Mouse wrote:
> I recently had occasion to set up a Linux - Debian - machine (for work,
> to be sure). I'm having trouble finding a Web browser I can stand to
> use.
>
> One of the ones I tried was netsurf (via apt-get install, installing
> netsurf-common and netsurf-gtk - the About window says "NetSurf 3.10
> (24th May 2020)"). As I have, unfortunately, come to expect from
> almost everything, it defaulted to reverse video. The notable part is
> that I was unable to find any way to change that; most of the browsers
> I've run into on Linux have had some way to configure colours, usually
> including a way to tell it "use these colours no matter what the page
> tries to set". With netsurf, though, I couldn't find even the former,
> much less the latter.
>
> Did I just miss something, or is netsurf not capable of being told what
> colours to use?
>
Netsurf has a default CSS file that sets up various colours, e.g.
ins { color: green; text-decoration: underline; }
I can't see that it explicitly sets the main body colour (although it
does for text areas), but you could presumably edit additional
definitions in. To be honest I don't know that this would override the
colours set up in the page that it is being asked to interpret, though.
It's not something that any RISC OS browser has ever been asked to do,
to my knowledge.
I'd be rather concerned about why everything on your system is for some
reason defaulting to inverse video and needs to be over-ridden to make
it usable...
--
Harriet Bazley == Loyaulte me lie ==
USER ERROR: replace user and press any key to continue.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Possible to get it out of reverse video?
I recently had occasion to set up a Linux - Debian - machine (for work,
to be sure). I'm having trouble finding a Web browser I can stand to
use.
One of the ones I tried was netsurf (via apt-get install, installing
netsurf-common and netsurf-gtk - the About window says "NetSurf 3.10
(24th May 2020)"). As I have, unfortunately, come to expect from
almost everything, it defaulted to reverse video. The notable part is
that I was unable to find any way to change that; most of the browsers
I've run into on Linux have had some way to configure colours, usually
including a way to tell it "use these colours no matter what the page
tries to set". With netsurf, though, I couldn't find even the former,
much less the latter.
Did I just miss something, or is netsurf not capable of being told what
colours to use?
Mouse
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
to be sure). I'm having trouble finding a Web browser I can stand to
use.
One of the ones I tried was netsurf (via apt-get install, installing
netsurf-common and netsurf-gtk - the About window says "NetSurf 3.10
(24th May 2020)"). As I have, unfortunately, come to expect from
almost everything, it defaulted to reverse video. The notable part is
that I was unable to find any way to change that; most of the browsers
I've run into on Linux have had some way to configure colours, usually
including a way to tell it "use these colours no matter what the page
tries to set". With netsurf, though, I couldn't find even the former,
much less the latter.
Did I just miss something, or is netsurf not capable of being told what
colours to use?
Mouse
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Monday, 18 July 2022
Re: [gccsdk] [PATCH] UnixLib: supportforPOSIX.1-2008extendedlocaleAPIs
Theo Markettos, on 18 Jul, wrote:
> On Jul 18 2022, at 12:10 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> > The issue occurs on building RISC OS gcc4 :-
> >
> > cd gcc4
> > make ronative
> >
> > ./build-world stalled without locale_t.h as in revision 7702 but is fine
> > with revision 7703. I have not tried cross compiling with
> > arm-unknown-riscos-gcc.
>
> Ah, I see - I didn't check that. That's confirmed - a link-time failure
> in SOManager due to requiring POSIX-1.2008 symbols even when building
> without the feature enabled.
>
> I think I've fixed that in r7704 - are you able to confirm?
A RISC OS GCC4 has built. Untested at the moment, a job for tomorrow.
--
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
> On Jul 18 2022, at 12:10 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> > The issue occurs on building RISC OS gcc4 :-
> >
> > cd gcc4
> > make ronative
> >
> > ./build-world stalled without locale_t.h as in revision 7702 but is fine
> > with revision 7703. I have not tried cross compiling with
> > arm-unknown-riscos-gcc.
>
> Ah, I see - I didn't check that. That's confirmed - a link-time failure
> in SOManager due to requiring POSIX-1.2008 symbols even when building
> without the feature enabled.
>
> I think I've fixed that in r7704 - are you able to confirm?
A RISC OS GCC4 has built. Untested at the moment, a job for tomorrow.
--
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] [PATCH] UnixLib: support forPOSIX.1-2008extendedlocaleAPIs
On Jul 18 2022, at 12:10 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
> The issue occurs on building RISC OS gcc4 :-
>
> cd gcc4
> make ronative
>
> ./build-world stalled without locale_t.h as in revision 7702 but is fine
> with revision 7703. I have not tried cross compiling with
> arm-unknown-riscos-gcc.
Ah, I see - I didn't check that. That's confirmed - a link-time failure
in SOManager due to requiring POSIX-1.2008 symbols even when building
without the feature enabled.
I think I've fixed that in r7704 - are you able to confirm?
Thanks
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> The issue occurs on building RISC OS gcc4 :-
>
> cd gcc4
> make ronative
>
> ./build-world stalled without locale_t.h as in revision 7702 but is fine
> with revision 7703. I have not tried cross compiling with
> arm-unknown-riscos-gcc.
Ah, I see - I didn't check that. That's confirmed - a link-time failure
in SOManager due to requiring POSIX-1.2008 symbols even when building
without the feature enabled.
I think I've fixed that in r7704 - are you able to confirm?
Thanks
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] [PATCH] UnixLib: supportforPOSIX.1-2008extendedlocaleAPIs
David Pitt, on 18 Jul, wrote:
> Theo Markettos, on 18 Jul, wrote:
>
> > On Jul 18 2022, at 10:34 am, David Pitt <pittdj@pittdj.co.uk> wrote:
> >
> > > I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an
> > > intel iMac and still get the above error on building gcc4.
> > >
> > > build-world does now build with 7703.
> [snip]
> > Just to clarify, are you getting that error when building gcc4 (ie
> > ./build-world in the SVN tree) or when building *with* gcc4 (ie
> > arm-unknown-riscos-gcc helloworld.c or compiling a program on RISC OS)?
>[snip]
> ./build-world stalled without locale_t.h as in revision 7702 but is fine
> with revision 7703. I have not tried cross compiling with
> arm-unknown-riscos-gcc.
For completeness, cross compiling is OK.
/home/djp/gccsdk/env/ro-path gcc -o helloC helloworld.c
--
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
> Theo Markettos, on 18 Jul, wrote:
>
> > On Jul 18 2022, at 10:34 am, David Pitt <pittdj@pittdj.co.uk> wrote:
> >
> > > I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an
> > > intel iMac and still get the above error on building gcc4.
> > >
> > > build-world does now build with 7703.
> [snip]
> > Just to clarify, are you getting that error when building gcc4 (ie
> > ./build-world in the SVN tree) or when building *with* gcc4 (ie
> > arm-unknown-riscos-gcc helloworld.c or compiling a program on RISC OS)?
>[snip]
> ./build-world stalled without locale_t.h as in revision 7702 but is fine
> with revision 7703. I have not tried cross compiling with
> arm-unknown-riscos-gcc.
For completeness, cross compiling is OK.
/home/djp/gccsdk/env/ro-path gcc -o helloC helloworld.c
--
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] [PATCH] UnixLib: support forPOSIX.1-2008extendedlocaleAPIs
Theo Markettos, on 18 Jul, wrote:
> On Jul 18 2022, at 10:34 am, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> > I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an
> > intel iMac and still get the above error on building gcc4.
> >
> > build-world does now build with 7703.
[snip]
> Just to clarify, are you getting that error when building gcc4 (ie
> ./build-world in the SVN tree) or when building *with* gcc4 (ie
> arm-unknown-riscos-gcc helloworld.c or compiling a program on RISC OS)?
>
> In other words, what's the difference between your first two paragraphs
> above?
The issue occurs on building RISC OS gcc4 :-
cd gcc4
make ronative
./build-world stalled without locale_t.h as in revision 7702 but is fine
with revision 7703. I have not tried cross compiling with
arm-unknown-riscos-gcc.
Sorry if I was not clear enough.
--
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
> On Jul 18 2022, at 10:34 am, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> > I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an
> > intel iMac and still get the above error on building gcc4.
> >
> > build-world does now build with 7703.
[snip]
> Just to clarify, are you getting that error when building gcc4 (ie
> ./build-world in the SVN tree) or when building *with* gcc4 (ie
> arm-unknown-riscos-gcc helloworld.c or compiling a program on RISC OS)?
>
> In other words, what's the difference between your first two paragraphs
> above?
The issue occurs on building RISC OS gcc4 :-
cd gcc4
make ronative
./build-world stalled without locale_t.h as in revision 7702 but is fine
with revision 7703. I have not tried cross compiling with
arm-unknown-riscos-gcc.
Sorry if I was not clear enough.
--
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] [PATCH] UnixLib: support for POSIX.1-2008extendedlocaleAPIs
On Jul 18 2022, at 10:34 am, David Pitt <pittdj@pittdj.co.uk> wrote:
> I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an intel
> iMac and still get the above error on building gcc4.
>
> build-world does now build with 7703.
>
> As Theo's installation works I will park this for now and ascribe the issue
> to some local wierdness.
Just to clarify, are you getting that error when building gcc4 (ie
./build-world in the SVN tree) or when building *with* gcc4 (ie
arm-unknown-riscos-gcc helloworld.c or compiling a program on RISC OS)?
In other words, what's the difference between your first two paragraphs above?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an intel
> iMac and still get the above error on building gcc4.
>
> build-world does now build with 7703.
>
> As Theo's installation works I will park this for now and ascribe the issue
> to some local wierdness.
Just to clarify, are you getting that error when building gcc4 (ie
./build-world in the SVN tree) or when building *with* gcc4 (ie
arm-unknown-riscos-gcc helloworld.c or compiling a program on RISC OS)?
In other words, what's the difference between your first two paragraphs above?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] [PATCH] UnixLib: support for POSIX.1-2008extendedlocaleAPIs
Theo Markettos, on 16 Jul, wrote:
> On Jul 16 2022, at 10:23 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> > Revision 7703 supplies the missing locale_t header but a gcc4 build now
> > fails with :-
> >
> >
/home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(stricmp.o):
> > In function `strcasecmp_l':
> > /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43:
undefined
> > reference to `tolower_l'
> > /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43:
undefined
> > reference to `tolower_l'
>
> Apologies, I failed to svn add the bits/locale_t.h file from the patch.
> I committed that in 7703.
>
> I did a fresh checkout of 7703 and it built for me (Ubuntu 21.10 amd64).
> Perhaps you need to clean your build if there are files left over from a
> previous revision?
I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an intel
iMac and still get the above error on building gcc4.
build-world does now build with 7703.
As Theo's installation works I will park this for now and ascribe the issue
to some local wierdness.
--
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
> On Jul 16 2022, at 10:23 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> > Revision 7703 supplies the missing locale_t header but a gcc4 build now
> > fails with :-
> >
> >
/home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(stricmp.o):
> > In function `strcasecmp_l':
> > /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43:
undefined
> > reference to `tolower_l'
> > /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43:
undefined
> > reference to `tolower_l'
>
> Apologies, I failed to svn add the bits/locale_t.h file from the patch.
> I committed that in 7703.
>
> I did a fresh checkout of 7703 and it built for me (Ubuntu 21.10 amd64).
> Perhaps you need to clean your build if there are files left over from a
> previous revision?
I have done a fresh checkout of 7703 onto a new Ubuntu 22.04 VM on an intel
iMac and still get the above error on building gcc4.
build-world does now build with 7703.
As Theo's installation works I will park this for now and ascribe the issue
to some local wierdness.
--
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
Saturday, 16 July 2022
Re: [gccsdk] [PATCH] UnixLib: support for POSIX.1-2008 extendedlocaleAPIs
On Jul 16 2022, at 10:23 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
> Revision 7703 supplies the missing locale_t header but a gcc4 build now
> fails with :-
>
> /home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(stricmp.o):
> In function `strcasecmp_l':
> /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
> reference to `tolower_l'
> /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
> reference to `tolower_l'
Apologies, I failed to svn add the bits/locale_t.h file from the patch.
I committed that in 7703.
I did a fresh checkout of 7703 and it built for me (Ubuntu 21.10 amd64).
Perhaps you need to clean your build if there are files left over from a
previous revision?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Revision 7703 supplies the missing locale_t header but a gcc4 build now
> fails with :-
>
> /home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(stricmp.o):
> In function `strcasecmp_l':
> /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
> reference to `tolower_l'
> /home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
> reference to `tolower_l'
Apologies, I failed to svn add the bits/locale_t.h file from the patch.
I committed that in 7703.
I did a fresh checkout of 7703 and it built for me (Ubuntu 21.10 amd64).
Perhaps you need to clean your build if there are files left over from a
previous revision?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] [PATCH] UnixLib: support for POSIX.1-2008 extendedlocaleAPIs
David Pitt, on 16 Jul, wrote:
> John-Mark Bell, on 31 May, wrote:
>
> > Hi,
> >
> > In the process of upgrading the third-party components required to build
> > NetSurf, it became apparent that OpenSSL 3 makes use of the extended
> > locale APIs introduced in POSIX.1-2008. While it only uses a subset of
> > these APIs, I've taken the opportunity to implement the majority of them
> > in UnixLib.
> >
> > Items outstanding (for the standard APIs -- I've ignored the GNU
> > extensions entirely) are:
> >
> > 1. strftime_l() has not been implemented.
> > 2. The uselocale() implementation does not conform to the specification.
> > It should be setting a thread-local locale (and, further, the global
> > variable it updates is entirely ignored by all the APIs that would
> > ordinarily use the global locale -- these would need updating to
make
> > use of the thread-local locale, if it exists).
> >
> > Additionally, the extended-locale ctype functions (i.e. isalpha_l() and
> > friends) are not in any way optimised like their non-extended
> > counterparts. Doing so will require making parts of the struct pointed
> > to by a locale_t public (which is what glibc does, at least).
>
> Having updated my local autobuilder to revision 7702 to include this patch
> neither gcc4 nor build-world build. The errors are of the form :-
>
> In file included from
> /home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/common/riscosify.c:48:0:
> /home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/include/string.h:97:27: fatal
> error: bits/locale_t.h: No such file or directory
Revision 7703 supplies the missing locale_t header but a gcc4 build now
fails with :-
/home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(stricmp.o):
In function `strcasecmp_l':
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
reference to `tolower_l'
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
reference to `tolower_l'
/home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(strnicmp.o):
In function `strncasecmp_l':
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/strnicmp.c:41: undefined
reference to `tolower_l'
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/strnicmp.c:42: undefined
reference to `tolower_l'
collect2: error: ld returned 1 exit status
--
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
> John-Mark Bell, on 31 May, wrote:
>
> > Hi,
> >
> > In the process of upgrading the third-party components required to build
> > NetSurf, it became apparent that OpenSSL 3 makes use of the extended
> > locale APIs introduced in POSIX.1-2008. While it only uses a subset of
> > these APIs, I've taken the opportunity to implement the majority of them
> > in UnixLib.
> >
> > Items outstanding (for the standard APIs -- I've ignored the GNU
> > extensions entirely) are:
> >
> > 1. strftime_l() has not been implemented.
> > 2. The uselocale() implementation does not conform to the specification.
> > It should be setting a thread-local locale (and, further, the global
> > variable it updates is entirely ignored by all the APIs that would
> > ordinarily use the global locale -- these would need updating to
make
> > use of the thread-local locale, if it exists).
> >
> > Additionally, the extended-locale ctype functions (i.e. isalpha_l() and
> > friends) are not in any way optimised like their non-extended
> > counterparts. Doing so will require making parts of the struct pointed
> > to by a locale_t public (which is what glibc does, at least).
>
> Having updated my local autobuilder to revision 7702 to include this patch
> neither gcc4 nor build-world build. The errors are of the form :-
>
> In file included from
> /home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/common/riscosify.c:48:0:
> /home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/include/string.h:97:27: fatal
> error: bits/locale_t.h: No such file or directory
Revision 7703 supplies the missing locale_t header but a gcc4 build now
fails with :-
/home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(stricmp.o):
In function `strcasecmp_l':
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
reference to `tolower_l'
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/stricmp.c:43: undefined
reference to `tolower_l'
/home/djp/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/scl-module/hard/fpa/libunixlib.a(strnicmp.o):
In function `strncasecmp_l':
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/strnicmp.c:41: undefined
reference to `tolower_l'
/home/djp/gccsdk/gcc4/srcdir/gcc/libunixlib/string/strnicmp.c:42: undefined
reference to `tolower_l'
collect2: error: ld returned 1 exit status
--
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] [PATCH] UnixLib: support for POSIX.1-2008 extended localeAPIs
John-Mark Bell, on 31 May, wrote:
> Hi,
>
> In the process of upgrading the third-party components required to build
> NetSurf, it became apparent that OpenSSL 3 makes use of the extended
> locale APIs introduced in POSIX.1-2008. While it only uses a subset of
> these APIs, I've taken the opportunity to implement the majority of them
> in UnixLib.
>
> Items outstanding (for the standard APIs -- I've ignored the GNU
> extensions entirely) are:
>
> 1. strftime_l() has not been implemented.
> 2. The uselocale() implementation does not conform to the specification.
> It should be setting a thread-local locale (and, further, the global
> variable it updates is entirely ignored by all the APIs that would
> ordinarily use the global locale -- these would need updating to make
> use of the thread-local locale, if it exists).
>
> Additionally, the extended-locale ctype functions (i.e. isalpha_l() and
> friends) are not in any way optimised like their non-extended
> counterparts. Doing so will require making parts of the struct pointed
> to by a locale_t public (which is what glibc does, at least).
Having updated my local autobuilder to revision 7702 to include this patch
neither gcc4 nor build-world build. The errors are of the form :-
In file included from
/home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/common/riscosify.c:48:0:
/home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/include/string.h:97:27: fatal
error: bits/locale_t.h: No such file or directory
Have I missed something, or is there more to come?
--
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
> Hi,
>
> In the process of upgrading the third-party components required to build
> NetSurf, it became apparent that OpenSSL 3 makes use of the extended
> locale APIs introduced in POSIX.1-2008. While it only uses a subset of
> these APIs, I've taken the opportunity to implement the majority of them
> in UnixLib.
>
> Items outstanding (for the standard APIs -- I've ignored the GNU
> extensions entirely) are:
>
> 1. strftime_l() has not been implemented.
> 2. The uselocale() implementation does not conform to the specification.
> It should be setting a thread-local locale (and, further, the global
> variable it updates is entirely ignored by all the APIs that would
> ordinarily use the global locale -- these would need updating to make
> use of the thread-local locale, if it exists).
>
> Additionally, the extended-locale ctype functions (i.e. isalpha_l() and
> friends) are not in any way optimised like their non-extended
> counterparts. Doing so will require making parts of the struct pointed
> to by a locale_t public (which is what glibc does, at least).
Having updated my local autobuilder to revision 7702 to include this patch
neither gcc4 nor build-world build. The errors are of the form :-
In file included from
/home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/common/riscosify.c:48:0:
/home/pi/gccsdk/gcc4/srcdir/gcc/libunixlib/include/string.h:97:27: fatal
error: bits/locale_t.h: No such file or directory
Have I missed something, or is there more to come?
--
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
[gccsdk] Old messages, [PATCH] UnixLib: support for POSIX.1-2008 extended locale APIs
I've just released a couple of old messages with patches that I
discovered snagged on the mailing list moderation interface (which it
turns out had a ridiculously low maximum message size of 40KB, now
increased to 5MB).
I approved them but I'm not sure they will make it out since they are
old. It appears one regarding OpenSSH was already merged anyway.
The other was from a few weeks ago from John-Mark Bell adding support
for POSIX.1-2008 extended locale APIs. I managed to extract the patch
from the logs and I've applied it as r7702.
Apologies that it took so long to apply :-(
There are a couple of other older ones:
From: nicholasjkingsley@gmail.com on Sun May 15 21:29:36 2016
Subject: Re: [gccsdk] Failed to init stdio
Cause: Message has implicit destination
(contents say 'problem fixed now')
From: michael.grunditz@gmail.com on Mon Apr 9 15:05:43 2018
Subject: Re: [gccsdk] gccsdk gcc4 fails to build
Cause: Message body is too big: 1969933 bytes with a limit of 40 KB
(contains logs, that I can't see directly)
that are I think of no relevance now, so I'll delete those unless
there's a good reason to keep them.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
discovered snagged on the mailing list moderation interface (which it
turns out had a ridiculously low maximum message size of 40KB, now
increased to 5MB).
I approved them but I'm not sure they will make it out since they are
old. It appears one regarding OpenSSH was already merged anyway.
The other was from a few weeks ago from John-Mark Bell adding support
for POSIX.1-2008 extended locale APIs. I managed to extract the patch
from the logs and I've applied it as r7702.
Apologies that it took so long to apply :-(
There are a couple of other older ones:
From: nicholasjkingsley@gmail.com on Sun May 15 21:29:36 2016
Subject: Re: [gccsdk] Failed to init stdio
Cause: Message has implicit destination
(contents say 'problem fixed now')
From: michael.grunditz@gmail.com on Mon Apr 9 15:05:43 2018
Subject: Re: [gccsdk] gccsdk gcc4 fails to build
Cause: Message body is too big: 1969933 bytes with a limit of 40 KB
(contains logs, that I can't see directly)
that are I think of no relevance now, so I'll delete those unless
there's a good reason to keep them.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 15 July 2022
Re: How to build with framebuffer usage?
Thanks to your info I managed to build a "nsfb" program file and I can run it. But it immediatly exits with an error message:
--------
Unable to open display
Error initialising wayland connection
Unable to initialise framebuffer
--------
I run it from text terminal, not from X. I wonder why it tries to open a display (that seems to be X!) and why it tries to init a Wayland connection.
Any chance to get it to work on text console framebuffer? Maybe I need to install FB support in the kernel?
Greetings
Peter
Wednesday, 13 July 2022
Re: How to build with framebuffer usage?
Thanks for the hint about the quickstart guide. The docs are a bit difficult to find (for a newbie) because they hide in the netsurf sub-directory. The quickstart guide did atually not help, but I saw a framebuffer doc file. On first glance it seems to solve my problem (I haven't the time to check it right now).
Greetings
Peter
On Di, Jul 12, 2022 at 08:47, Rob Kendrick <rjek@netsurf-browser.org> wrote:
On Sun, Jul 10, 2022 at 05:51:41PM +0200, Peter Wiehe wrote:Hi all, how do I build netsurf on Linux with framebuffer usage instead of gtk? (I tried already TARGET=framebuffer in the makefile, but that didn't work.)How precisely did you try? Using env.sh as described in our quickstart guide, this just worked for me first try. What did you type in? What errors did you see? B. _______________________________________________ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Tuesday, 12 July 2022
Re: How to build with framebuffer usage?
On Sun, Jul 10, 2022 at 05:51:41PM +0200, Peter Wiehe wrote:
> Hi all,
>
> how do I build netsurf on Linux with framebuffer usage instead of gtk?
>
> (I tried already TARGET=framebuffer in the makefile, but that didn't
> work.)
How precisely did you try? Using env.sh as described in our quickstart
guide, this just worked for me first try.
What did you type in? What errors did you see?
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> Hi all,
>
> how do I build netsurf on Linux with framebuffer usage instead of gtk?
>
> (I tried already TARGET=framebuffer in the makefile, but that didn't
> work.)
How precisely did you try? Using env.sh as described in our quickstart
guide, this just worked for me first try.
What did you type in? What errors did you see?
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Sunday, 10 July 2022
How to build with framebuffer usage?
Hi all,
how do I build netsurf on Linux with framebuffer usage instead of gtk?
(I tried already TARGET=framebuffer in the makefile, but that didn't work.)
Greetings
Peter
Sunday, 3 July 2022
Re: [gccsdk] IPv6
On Sun, Jul 03, 2022 at 07:53:23AM +0100, Chris Johns wrote:
> With RISC OS Development's new TCP/IP stack, does anyone have a
> rough "finger in the air" guess as to what would be required to use
> IPv6? Is it likely to be a case of rebuilding network libs with it
> enabled, or are there going to be a bunch of changes lower down too?
I would think new #defines for socket types and a new structure for the
address type, and getaddrinfo() being updated to support IPv6?
I have not looked at the new IP stack as I don't have a system to run it
on (RPCEmu only here), but if it uses broadly the same SWI interface
then this should already be pretty protocol-agnostic.
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
> With RISC OS Development's new TCP/IP stack, does anyone have a
> rough "finger in the air" guess as to what would be required to use
> IPv6? Is it likely to be a case of rebuilding network libs with it
> enabled, or are there going to be a bunch of changes lower down too?
I would think new #defines for socket types and a new structure for the
address type, and getaddrinfo() being updated to support IPv6?
I have not looked at the new IP stack as I don't have a system to run it
on (RPCEmu only here), but if it uses broadly the same SWI interface
then this should already be pretty protocol-agnostic.
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
Saturday, 2 July 2022
[gccsdk] IPv6
A quick question...
With RISC OS Development's new TCP/IP stack, does anyone have a rough
"finger in the air" guess as to what would be required to use IPv6? Is
it likely to be a case of rebuilding network libs with it enabled, or
are there going to be a bunch of changes lower down too?
Best Regards,
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
With RISC OS Development's new TCP/IP stack, does anyone have a rough
"finger in the air" guess as to what would be required to use IPv6? Is
it likely to be a case of rebuilding network libs with it enabled, or
are there going to be a bunch of changes lower down too?
Best Regards,
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
Subscribe to:
Posts (Atom)