Fw: Use nsws_find_resource to find ca-bundle.crt

Resending this to the mailing list.

On Fri, Jul 28, 2017 at 09:50:00 +0000, Daniel Silverstone wrote:

> On Thu, Jul 27, 2017 at 21:06:21 +0000, James Woodcock wrote:
> > I have attached a patch, which should do the trick.

> Unfortunately it turned up mangled.  Can you please ensure you attach it rather than paste it in?

Sorry about that.  I have attached the patch to this email.

Re: Use nsws_find_resource to find ca-bundle.crt

On Thu, Jul 27, 2017 at 21:06:21 +0000, James Woodcock wrote:
> I cross compiled the Windows version of NetSurf on Linux and ran it under
> Wine.  It failed to find the ca-bundle.crt file.
>
> I think nsws_find_resource() should be used to find the file instead of the
> Windows SearchPathA() API so that NetSurf will look in the NetSurf resources
> directory.

That sounds sensible.

> I have attached a patch, which should do the trick.

Unfortunately it turned up mangled. Can you please ensure you attach it rather than paste it in?

D.


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

Use nsws_find_resource to find ca-bundle.crt

I cross compiled the Windows version of NetSurf on Linux and ran it under Wine.  It failed to find the ca-bundle.crt file.

I think nsws_find_resource() should be used to find the file instead of the Windows SearchPathA() API so that NetSurf will look in the NetSurf resources directory.

I have attached a patch, which should do the trick.

diff --git a/frontends/windows/main.c b/frontends/windows/main.c

index d019f10..8e86a29 100644

--- a/frontends/windows/main.c

+++ b/frontends/windows/main.c

@@ -156,32 +156,14 @@ static nserror set_defaults(struct nsoption_s *defaults)

        /* locate CA bundle and set as default, cannot rely on curl

         * compiled in default on windows.

         */

-       DWORD res_len;

-       DWORD buf_tchar_size = PATH_MAX + 1;

-       DWORD buf_bytes_size = sizeof(TCHAR) * buf_tchar_size;

-       char *ptr = NULL;

-       char *buf;

+       char buf[PATH_MAX];

        char *fname;

        HRESULT hres;

        char dldir[] = "Downloads";

-       buf = malloc(buf_bytes_size);

-       if (buf== NULL) {

-               return NSERROR_NOMEM;

-       }

-       buf[0] = '\0';

-

        /* locate certificate bundle */

-       res_len = SearchPathA(NULL,

-                             "ca-bundle.crt",

-                             NULL,

-                             buf_tchar_size,

-                             buf,

-                             &ptr);

-       if (res_len > 0) {

-               nsoption_setnull_charp(ca_bundle, strdup(buf));

-       }

-

+       nsws_find_resource(buf, "ca-bundle.crt", "windows/res/ca-bundle.crt");

+       nsoption_setnull_charp(ca_bundle, strdup(buf));

        /* download directory default

         *

@@ -204,8 +186,6 @@ static nserror set_defaults(struct nsoption_s *defaults)

                }

        }

-       free(buf);

-

        /* ensure homepage option has a default */

        nsoption_setnull_charp(homepage_url, strdup(NETSURF_HOMEPAGE));

Windows redraw issue when resizing screen

I noticed that the redraw logic goes a bit funny when you maximise the browser window on Windows. A race condition with WM_PAINT can cause win32_window_set_scroll() to use the old window size. If this happens, the page data will not get drawn from the top left of the window but offset quite a large distance down and to the right.


To recreate:
1. start NetSurf and resize the browser window to be 1/2 size of the screen

2. load a page (any page will do)
3. click the maximise window button

It usually fails, but you might need to give it a few tries.
The following patch fixes it.

diff --git a/frontends/windows/window.c b/frontends/windows/window.c
index 976974c..0addc35 100644
--- a/frontends/windows/window.c
+++ b/frontends/windows/window.c
@@ -1366,7 +1366,7 @@ nsws_window_resize(struct gui_window *gw,
}
nsws_window_update_forward_back(gw);

- win32_window_set_scroll(gw, &rect);
+ browser_window_update(gw->bw, false);

if (gw->toolbar != NULL) {
SendMessage(gw->toolbar, TB_SETSTATE,

Re: [Rpcemu] Networking

In message <b7c2fac9f16213be5d7a90b1ab6a83a4@ascinfo.fr>
on 18 Jul 2017 dfeugey@ascinfo.fr wrote:

> Other subject, the crash when you go from window mode to fullscreen
> mode. It's linked to the 'follow host mouse' option. The solution could
> be to deactivate it before the mode change, and to reactive it after.
> But once again, no one has time for this :(

I tried looking at this a few months ago, because I have had this problem on
the Linux laptop I run RPCEmu on. However, I was not able to follow the C
source code sufficiently well to work out how to fix it. Too many possible
programming projects, so I tend to concentrate on things I already
understand.

Matthew

--
Matthew Phillips
Durham

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

[gccsdk] GNU gettimeofday causes recurring sys/time.h

I found an old cygwin forum and they were having the same problem with
the rpl_gettimeofday already defined .
Apparently the GNU gettimeofday is incompatible with the fact that system
/sys/time.h and /sys/select.h referr to each other and it causes a
re-occurence.
By commenting out #include <sys/select.h> from sys/time.h (the one in a
rm-unknown-riscos/include ) the gettimeofdays blues were magically gone.

If this is a reliable cure for this common porting issue, It would require
a fix in the gcc include.

Assuming there is sometimes a need for #include <sys/select.h> would it be
possible to have an ifdef that recognises a GNU gettimeofday is active?
It appears that the GNU gettimeofday additional libraries are fairly
standardised in the ports.

Ron M.



_______________________________________________
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: [Rpcemu] Networking

On Mon, 17 Jul 2017 18:19:09 +0100, Dave Symes wrote:
> Thanks for the suggestion, but I'm not able or permitted to make any
> changes to the shared machine... I do understand that position...
>
> Dave

Unfortunately, no one (including me) seems to have some time to work on
user mode networking. Perhaps Qemu code could be used here.

Other subject, the crash when you go from window mode to fullscreen
mode. It's linked to the 'follow host mouse' option. The solution could
be to deactivate it before the mode change, and to reactive it after.
But once again, no one has time for this :(

Bye, David


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

Re: [Rpcemu] Networking

In article <20170717134738.GF14778@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:
Dave Symes wrote:
> > >>Has anyone yet worked out a way to get RPCEmu networking without
> > >>messing with the underlying networking setup?

[Snip]

> One slightly nasty thing you could try is installing RPCEmu inside a
> virtual machine (Windows, Linux, whatever you like) - eg install
> VirtualBox on the machine, create a new VM and install Windows into it,
> install RPCEmu inside the VM and configure RPCEmu networking. The VM
> will handle connecting RPCEmu to the outside world - it'll be harder to
> get into it from outside, but maybe you don't need that.

> It's possible to put the VM containing RPCEmu on a USB stick so you just
> need to install VirtualBox on the target machine, and it plays fairly
> nicely with the host networking. It's likely to be slower and eat
> battery, but maybe that's not so much of a problem.

> Getting more technical, I wonder if RPCEmu would run in a Docker
> container...?

> Theo

Thanks for the suggestion, but I'm not able or permitted to make any
changes to the shared machine... I do understand that position...

Dave

--

Dave Triffid

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

Re: [Rpcemu] Networking

On Mon, Jul 17, 2017 at 02:48:03PM +0200, dfeugey@ascinfo.fr wrote:
> On Mon, 17 Jul 2017 14:47:39 +0200, dfeugey@ascinfo.fr wrote:
> >On Mon, 17 Jul 2017 12:01:29 +0100, Dave Symes wrote:
> >>Has anyone yet worked out a way to get RPCEmu networking without messing
> >>with the underlying networking setup?
> >>
> >Unfortunately there is no user mode networking.
> >Sorry.
> >
> >It would be quite useful to distribute RISC OS software + RPCEmu as a rea
> ...dy to run package :)

One slightly nasty thing you could try is installing RPCEmu inside a virtual
machine (Windows, Linux, whatever you like) - eg install VirtualBox on the
machine, create a new VM and install Windows into it, install RPCEmu inside
the VM and configure RPCEmu networking. The VM will handle connecting
RPCEmu to the outside world - it'll be harder to get into it from outside,
but maybe you don't need that.

It's possible to put the VM containing RPCEmu on a USB stick so you just
need to install VirtualBox on the target machine, and it plays fairly nicely
with the host networking. It's likely to be slower and eat battery, but
maybe that's not so much of a problem.

Getting more technical, I wonder if RPCEmu would run in a Docker
container...?

Theo

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

Re: [Rpcemu] Networking

On Mon, 17 Jul 2017 14:47:39 +0200, dfeugey@ascinfo.fr wrote:
> On Mon, 17 Jul 2017 12:01:29 +0100, Dave Symes wrote:
>> My Main machine has gone to the recycling as it died of a broken
>> MOBO.
>> In the meanwhile, until my new machine is built and delivered, I
>> have my
>> RPCEmu & ROOL RISC OS install temporarily sharing someone elses
>> machine.
>>
>> As there is no way, I can FU their machine by changing anything
>> relating
>> to networking...
>>
>> Has anyone yet worked out a way to get RPCEmu networking without
>> messing
>> with the underlying networking setup?
>>
> Unfortunately there is no user mode networking.
> Sorry.
>
> It would be quite useful to distribute RISC OS software + RPCEmu as a
> rea
>
...dy to run package :)


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

Re: [Rpcemu] Networking

On Mon, 17 Jul 2017 12:01:29 +0100, Dave Symes wrote:
> My Main machine has gone to the recycling as it died of a broken
> MOBO.
> In the meanwhile, until my new machine is built and delivered, I have
> my
> RPCEmu & ROOL RISC OS install temporarily sharing someone elses
> machine.
>
> As there is no way, I can FU their machine by changing anything
> relating
> to networking...
>
> Has anyone yet worked out a way to get RPCEmu networking without
> messing
> with the underlying networking setup?
>
Unfortunately there is no user mode networking.
Sorry.

It would be quite useful to distribute RISC OS software + RPCEmu as a
rea

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

[Rpcemu] Networking

My Main machine has gone to the recycling as it died of a broken MOBO.
In the meanwhile, until my new machine is built and delivered, I have my
RPCEmu & ROOL RISC OS install temporarily sharing someone elses machine.

As there is no way, I can FU their machine by changing anything relating
to networking...

Has anyone yet worked out a way to get RPCEmu networking without messing
with the underlying networking setup?

Dave

--

Dave Triffid

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

Re: UTF-8 processing

On 14 Jul, chris.young@unsatisfactorysoftware.co.uk typed:

> I don't know if it's a known problem, but certainly the first form is
> incorrect. The semicolon is required to separate the parameters.

Thanks, that's interesting, though websites I've so far looked at
aren't consistent on this point. The particular originator's email
headers include:

Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
X-Mailer: Apple Mail (2.3273)

suggesting that it's the Apple software that is not to standard in
coding the <meta> tag, but that seems surprising.

> If NetSurf doesn't know the encoding it will assume ASCII/ISO-8859-1,
> or maybe default character encoding of the OS.

Yes, but in this case I think Netsurf might be expected to acknowledge
the charset attribute, so I've posted bug report 0002549 to
http://bugs.netsurf-browser.org/mantis/ in case developers can throw
any light on the issue.

--
Bernard

Re: UTF-8 processing

On 14 July 2017 12:10:47 BST, Bernard Boase <b.boase@bcs.org> wrote:
>Looking in detail at some recent HTML email attachments (received in
>Messenger Pro), Netsurf's rendering of them seems to have a dependence
>on the coding of the <meta content=""> tag.
>
>When this tag is present and includes:
>
> content="text/html charset=utf-8"
>
>any non-ASCII characters are shown as the three bytes of their UTF-8
>encoding, whereas if the two attributes are separated by semicolon:
>
> content="text/html; charset=utf-8"
>
>the rendering (using Unicode font DejaVu) looks correct.
>
>Is this a known problem?

I don't know if it's a known problem, but certainly the first form is incorrect. The semicolon is required to separate the parameters.

If NetSurf doesn't know the encoding it will assume ASCII/ISO-8859-1, or maybe default character encoding of the OS.

Chris

UTF-8 processing

Looking in detail at some recent HTML email attachments (received in
Messenger Pro), Netsurf's rendering of them seems to have a dependence
on the coding of the <meta content=""> tag.

When this tag is present and includes:

content="text/html charset=utf-8"

any non-ASCII characters are shown as the three bytes of their UTF-8
encoding, whereas if the two attributes are separated by semicolon:

content="text/html; charset=utf-8"

the rendering (using Unicode font DejaVu) looks correct.

Is this a known problem?

--
Bernard

Re: NetSurf failing at startup

In article <565961bfecStuartlists@orpheusinternet.co.uk>,
lists <Stuartlists@orpheusinternet.co.uk> wrote:
> In article <56591fa972Stuartlists@orpheusinternet.co.uk>,
> lists <Stuartlists@orpheusinternet.co.uk> wrote:
> > I accept this might be "bad form" to post it here but I think this might
> > be specific to my setup. NetSurf crashes out when attempting to load for
> > the first time, even after a complete computer switch-off and re-start.
> > All other programs seem to be running normally.

> > Kinetic RPC, RO 4.39

> Problem now solved. This started two days ago and I sat and thought what I
> had done that could cause a problem. I had installed some free fonts
> provided by Mathew Phillips, FreeMono, FreeSans and FreeSerif.

> http://sinenomine.co.uk/software/freefonts.zip

> After I had removed these (FreeMono required a shutdown and Shift power-up
> to avoid the computer running !Boot) all seems to be back to normal. It
> would seem that FreeMono was the culprit.

Interesting. I tried to add those fonts to Easy Font Pro (APDL) and it
crashed irredeemably Had to re-install it.

--
Chris

Re: NetSurf failing at startup

In article <56591fa972Stuartlists@orpheusinternet.co.uk>,
lists <Stuartlists@orpheusinternet.co.uk> wrote:
> I accept this might be "bad form" to post it here but I think this might
> be specific to my setup. NetSurf crashes out when attempting to load for
> the first time, even after a complete computer switch-off and re-start.
> All other programs seem to be running normally.

> Kinetic RPC, RO 4.39

Problem now solved. This started two days ago and I sat and thought what I
had done that could cause a problem. I had installed some free fonts
provided by Mathew Phillips, FreeMono, FreeSans and FreeSerif.

http://sinenomine.co.uk/software/freefonts.zip

After I had removed these (FreeMono required a shutdown and Shift power-up
to avoid the computer running !Boot) all seems to be back to normal. It
would seem that FreeMono was the culprit.

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

NetSurf failing at startup

I accept this might be "bad form" to post it here but I think this might
be specific to my setup. NetSurf crashes out when attempting to load for
the first time, even after a complete computer switch-off and re-start.
All other programs seem to be running normally.

Kinetic RPC, RO 4.39



(0.000000) utils/log.c:101 nslog_init: NetSurf version '3.7 (Dev CI #4086)'
(0.000000) utils/log.c:110 nslog_init: NetSurf on <RISC OS>, node
<Ruth.workgroup>, release <4.39>, version <20040511-001>, machine <armv4l>
(0.010000) utils/nsoption.c:655 nsoption_read: Successfully opened
'NetSurf:Choices' for Options file
(0.030000) utils/messages.c:205 messages_add_from_file: Loading Messages
from 'NetSurf:Resources.en.Messages'
(0.100000) content/handlers/image/image_cache.c:426 image_cache_init:
Image cache initialised with a limit of 3145728 hysteresis of 629145
(0.100000) render/html_css_fetcher.c:64 html_css_fetcher_initialise:
html_css_fetcher_initialise called for x-ns-css
(0.110000) content/fetchers/curl.c:1430 fetch_curl_register: curl_version
libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 c-ares/1.12.0
(0.190000) utils/useragent.c:68 user_agent_build_string: Built user agent
"NetSurf/3.7 (RISC OS)"
(0.190000) content/fetchers/curl.c:1500 fetch_curl_register: ca_bundle:
'NetSurf:Resources.ca-bundle'
(0.190000) content/fetchers/curl.c:1516 fetch_curl_register: cURL linked
against openssl
(0.190000) content/fetchers/curl.c:158 fetch_curl_initialise: Initialise
cURL fetcher for http
(0.190000) content/fetchers/curl.c:158 fetch_curl_initialise: Initialise
cURL fetcher for https
(0.190000) content/fetchers/data.c:60 fetch_data_initialise:
fetch_data_initialise called for data
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for adblock.css
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for default.css
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for internal.css
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for quirks.css
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for user.css
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for credits.html
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for licence.html
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for welcome.html
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for maps.html
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for favicon.ico
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for default.ico
(0.190000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for netsurf.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/arrow-l.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/content.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/directory.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/directory2.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/hotlist-add.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/hotlist-rmv.png
(0.200000) content/fetchers/resource.c:286 fetch_resource_initialise:
redirect url for icons/search.png
(0.200000) content/llcache.c:3367 llcache_initialise: llcache initialising
with a limit of 9437184 bytes
(0.200000) utils/messages.c:205 messages_add_from_file: Loading Messages
from 'NetSurf:Resources.LangNames'
(0.340000) utils/filename.c:185 filename_initialise: Creating
"<Wimp$ScrapDir>"
(0.340000) utils/filename.c:185 filename_initialise: Creating
"<Wimp$ScrapDir>/WWW"
(0.340000) utils/filename.c:185 filename_initialise: Creating
"<Wimp$ScrapDir>/WWW/NetSurf"
(0.340000) utils/filename.c:197 filename_initialise: Temporary directory
location: <Wimp$ScrapDir>/WWW/NetSurf/Misc
(0.430000) frontends/riscos/font.c:121 nsfont_init: Initialise RUfl
http_proxy:0
http_proxy_host:
http_proxy_port:8080
http_proxy_auth:0
http_proxy_auth_user:
http_proxy_auth_pass:
http_proxy_noproxy:localhost
treeview_font_size:120
font_size:128
font_min_size:85
font_sans:Homerton
font_serif:Trinity
font_mono:Corpus
font_cursive:Homerton
font_fantasy:Sassoon
accept_language:en
accept_charset:
memory_cache_size:12582912
disc_cache_size:0
disc_cache_age:28
block_advertisements:0
do_not_track:0
minimum_gif_delay:10
send_referer:1
foreground_images:1
background_images:1
animate_images:1
enable_javascript:1
script_timeout:10
expire_url:28
font_default:0
ca_bundle:NetSurf:Resources.ca-bundle
ca_path:
cookie_file:NetSurf:Cookies
cookie_jar:<Choices$Write>.WWW.NetSurf.Cookies
homepage_url:
search_url_bar:0
search_provider:0
url_suggestion:1
window_x:0
window_y:0
window_width:0
window_height:0
window_screen_width:0
window_screen_height:0
toolbar_status_size:6667
scale:100
incremental_reflow:1
min_reflow_period:100
core_select_menu:0
display_decoded_idn:0
max_fetchers:24
max_fetchers_per_host:5
max_cached_fetch_handles:6
max_retried_fetches:1
curl_fetch_timeout:30
suppress_curl_debug:1
target_blank:1
button_2_tab:1
margin_top:10
margin_bottom:10
margin_left:10
margin_right:10
export_scale:70
suppress_images:0
remove_backgrounds:0
enable_loosening:1
enable_PDF_compression:1
enable_PDF_password:0
sys_colour_ActiveBorder:000000
sys_colour_ActiveCaption:eeeebb
sys_colour_AppWorkspace:dddddd
sys_colour_Background:dddddd
sys_colour_ButtonFace:dddddd
sys_colour_ButtonHighlight:555555
sys_colour_ButtonShadow:777777
sys_colour_ButtonText:000000
sys_colour_CaptionText:000000
sys_colour_GrayText:999999
sys_colour_Highlight:000000
sys_colour_HighlightText:ffffff
sys_colour_InactiveBorder:000000
sys_colour_InactiveCaption:bbbbbb
sys_colour_InactiveCaptionText:000000
sys_colour_InfoBackground:eeeebb
sys_colour_InfoText:000000
sys_colour_Menu:ffffff
sys_colour_MenuText:000000
sys_colour_Scrollbar:bbbbbb
sys_colour_ThreeDDarkShadow:777777
sys_colour_ThreeDFace:dddddd
sys_colour_ThreeDHighlight:ffffff
sys_colour_ThreeDLightShadow:ffffff
sys_colour_ThreeDShadow:777777
sys_colour_Window:dddddd
sys_colour_WindowFrame:000000
sys_colour_WindowText:000000
theme:Aletheia
language:en
plot_fg_quality:8
plot_bg_quality:4
history_tooltip:1
toolbar_show_buttons:1
toolbar_show_address:1
toolbar_show_throbber:1
toolbar_browser:0123|58|9
toolbar_hotlist:40|12|3
toolbar_history:0|12|3
toolbar_cookies:0|12
window_stagger:1
window_size_clone:1
buffer_animations:1
buffer_everything:1
open_browser_at_startup:0
no_plugins:0
block_popups:0
strip_extensions:0
confirm_overwrite:1
confirm_hotlist_remove:1
url_path:NetSurf:URL
url_save:<Choices$Write>.WWW.NetSurf.URL
hotlist_path:NetSurf:Hotlist
hotlist_save:<Choices$Write>.WWW.NetSurf.Hotlist
recent_path:NetSurf:Recent
recent_save:<Choices$Write>.WWW.NetSurf.Recent
theme_path:NetSurf:Themes
theme_save:<Choices$Write>.WWW.NetSurf.Themes
thumbnail_iconise:1
interactive_help:1
external_hotlists:0
external_hotlist_app:

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x768ea8 (Main Thread)
( 779ee0) pc: 521d30 lr: 17217c sp: 779ee4 __write_backtrace()
( 779f08) pc: 1720fc lr: 52265c sp: 779f0c ro_gui_signal()
( 779f30) pc: 522644 lr: 522338 sp: 779f34 __unixlib_exec_sig()
( 779fa0) pc: 521e50 lr: 522c44 sp: 779fa4
__unixlib_raise_signal()
( 779fb0) pc: 522b48 lr: 3973938 sp: 1c07f40 __h_cback()

Register dump at 00779fb4:

a1: 19c5a40c a2: 850100 a3: 1770 a4: 0
v1: 1 v2: 0 v3: 1940a2f8 v4: 19407ee4
v5: 194080f4 v6: 1940a30c sl: 19409df8 fp: 7789d0
ip: 2198234 sp: 1c07f40 lr: 397393b pc: 3973ecb
Mode SVC, flags set: nzcvif

[Disassembly not available]

( 7789d0) pc: 0 lr: 52edec sp: 2052ac4c ?()

Register dump at 007789d4:

a1: 0 a2: 0 a3: ffffffff a4: 0
v1: 0 v2: 0 v3: 0 v4: 0
v5: 1770 v6: 120041 sl: 1 fp: 0
ip: 202f sp: 0 lr: 2078d6d0 pc: 764d64
Mode USR, flags set: nzcvif

00764d50 : .... : 00000000 : ANDEQ R0,R0,R0
00764d54 : .... : 00000000 : ANDEQ R0,R0,R0
00764d58 : .... : 00000000 : ANDEQ R0,R0,R0
00764d5c : .... : 00000001 : ANDEQ R0,R0,R1
00764d60 : .... : 00000001 : ANDEQ R0,R0,R1
00764d64 : .... : 00000000 : ANDEQ R0,R0,R0
00764d68 : .... : 00000000 : ANDEQ R0,R0,R0
00764d6c : .... : 00000000 : ANDEQ R0,R0,R0
00764d70 : 0... : 00000130 : ANDEQ R0,R0,R0,LSR R1

fp unchanged at 7789d0

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

Re: toolchains: branch master updated. c113b768e24439447e0306011ca2743606f227f9

On 09/05/17 23:13, NetSurf Browser Project (Commit Mailer) wrote:

> Gitweb links:
>
> ...log http://git.netsurf-browser.org/toolchains.git/shortlog/c113b768e24439447e0306011ca2743606f227f9
> ...commit http://git.netsurf-browser.org/toolchains.git/commit/c113b768e24439447e0306011ca2743606f227f9
> ...tree http://git.netsurf-browser.org/toolchains.git/tree/c113b768e24439447e0306011ca2743606f227f9
>
> The branch, master has been updated
> via c113b768e24439447e0306011ca2743606f227f9 (commit)
> from eb01b89e3e2cd6f74053b825cd1a31e07a60dd36 (commit)
>
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
>
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/toolchains.git/commit/?id=c113b768e24439447e0306011ca2743606f227f9
> commit c113b768e24439447e0306011ca2743606f227f9
> Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Set an OpenSSL environment path
> OpenSSL sometimes tries to read a config file which by default is in /opt. On AmigaOS this causes a request for volume opt:
> The way NetSurf uses curl/openssl doesn't appear to trigger this, but adding the option as a precaution as I've seen the problem with this OpenSSL build when used in other software.
>
> diff --git a/sdk/Makefile b/sdk/Makefile
> index 47efd13..629ddc8 100644
> --- a/sdk/Makefile
> +++ b/sdk/Makefile
> @@ -114,6 +114,7 @@ ifeq ($(TARGET),ppc-amigaos)
> SDK_ITEMS := $(addprefix $(BUILDSTEPS)/, libiconv.d libtre.d libpbl.d $(COMMON_SDK_ITEMS) libjpeg-turbo.d)
> EXTRAARGS_LIBCARES := --disable-shared
> EXTRAARGS_LIBCURL := --disable-ntlm-wb --without-random --enable-threaded-resolver LIBS=-lpthread
> + EXTRAARGS_OPENSSL := --openssldir="/env/openssl"
> endif
>
> ifeq ($(TARGET),i686-w64-mingw32)
>

I'm afraid I've had to revert this change, as it breaks CI toolchain
builds[1]: --openssldir overrides --prefix, and so this change causes
the OpenSSL buildsystem to try to install into /env/openssl, rather than
{PREFIX}/ssl. /env does not exist, and thus this fails (and, even if it
did exist, and was writable, you'd still end up with a toolchain tarball
that didn't contain OpenSSL, and a build environment that no longer
worked, as OpenSSL headers and libraries would no longer be found).

If the problem this change is trying to solve is that, at runtime, in
the absence of an explicitly provided path to openssl.cnf, it will
default to looking in the computed openssldir (i.e. {prefix}/ssl), then
you're probably better off patching lines 83-86 of crypto/cryptlib.h to
ignore OPENSSLDIR on AmigaOS (as these macros are the only thing that
determines where OpenSSL looks for things by default).


J.

1. http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/60/

Re: [gccsdk] Is there activity here?

In message <a55c725756.DaveMeUK@my.inbox.com>
Dave Higton <dave@davehigton.me.uk> wrote:

>In message <79e0f25356.DaveMeUK@my.inbox.com> I wrote:
>
>>... and, if there is: have I failed to notice it, or did it not
>>arrive in my inbox?
>
>Theo diagnosed the problem as an incorrect RDNS configuration of the
>list's server, and that it should now be fixed.

I'm pleased to report that I am indeed receiving mail from the
list.

Thank you, Theo.

Dave

_______________________________________________
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 there activity here?

In message <79e0f25356.DaveMeUK@my.inbox.com> I wrote:

>... and, if there is: have I failed to notice it, or did it not
>arrive in my inbox?

Theo diagnosed the problem as an incorrect RDNS configuration of the
list's server, and that it should now be fixed.

Dave

_______________________________________________
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] pthread shutdown in atexit

Hi Alan,

> I have a mysterious crash in a SDL based program when it attempts to
> do a pthread_wait in an atexit handler. The error is: pthreads:
> ***fatal error, aborting*** pthread_yield called with context
> switching disabled.
>
> My guess is this means that GCC is shutting down the threads system
> before the atexit handler is being called.

Are you calling atexit(3) before or after your initialise pthreads? I'd
call it after as the registered functions are called in reverse order so
if pthreads is registering one itself to "shutdown" then you want that
called after yours.

Cheers, Ralph.

_______________________________________________
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