On 27/07/2020 14:12, Lee Noar wrote:
> On 05/07/2020 21:27, alan buckley wrote:
>> I�m about to start rebuilding the autobuilder packages and
>> uploading new versions where appropriate. If you have updated items
>> or their packaging in the autobuilder recently and would like me to
>> build and upload those first please let me know.
>>
>> I�m not getting much time on this at the moment so any help in
>> fixing packages or testing them will be much appreciated.
>
> Just to let you know that I am working on updating some packages.
This is great news - Thanks.
>
> I've noticed a growing trend, particularly in the GTK family of
> packages, to move away from the use of autotools (autoconf, automake)
> towards more modern alternatives such as meson/ninja and cmake.
> That's certainly not a bad thing, but I think for us, it's going
> to cause a slight bump in the road as we find packages fail to
> build because the autobuilder doesn't support these "new" methods.
> It's not a major issue as packages can be transitioned as required,
> and things can be made easier by adding new variables to the
> autobuilder, for example, AB_MESON_CROSS_FILE that points to a ready
> made cross file for meson or AB_CMAKE_TOOLCHAIN_FILE for cmake.
> I'm already working on those, but I may also look at adding better
> meson/ninja support to the autobuilder as well.
>
There is some support for cmake in the autobuilder at the moment, but it
probably can be improved.
It would be good to get other new methods in there as well.
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
Wednesday, 29 July 2020
Monday, 27 July 2020
[Rpcemu] Shut down message
In article <5896c8e3fbdave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> In article
> <CANc9Z=wia7s0VN5eLM83cFAEWBo2k0+OojdO0rkmKwVmnmbrNA@mail.gmail.com>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > On Mon, 27 Jul 2020 at 19:16, Dave <dave@triffid.co.uk> wrote:
> > > Nb: Any particular reason why that message was added in recent
> > > versions of RPCEmu?
> > >
> > Yes.
> > Peter
> Ah! A man of many words... ;-)
> You could also have said. Because. (I just wanted to.)
> But seriously, why?
> Thanks
> Dave
> I have a vague recollection that VRPC also has a shutdown warning, but it
> can be switched Off or On from Configuration.
> D.
I got around to checking, and find it's RISC OS itself that has the On/Off
shutdown warning.
Paah!
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Dave <dave@triffid.co.uk> wrote:
> In article
> <CANc9Z=wia7s0VN5eLM83cFAEWBo2k0+OojdO0rkmKwVmnmbrNA@mail.gmail.com>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > On Mon, 27 Jul 2020 at 19:16, Dave <dave@triffid.co.uk> wrote:
> > > Nb: Any particular reason why that message was added in recent
> > > versions of RPCEmu?
> > >
> > Yes.
> > Peter
> Ah! A man of many words... ;-)
> You could also have said. Because. (I just wanted to.)
> But seriously, why?
> Thanks
> Dave
> I have a vague recollection that VRPC also has a shutdown warning, but it
> can be switched Off or On from Configuration.
> D.
I got around to checking, and find it's RISC OS itself that has the On/Off
shutdown warning.
Paah!
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Shut down message
In article
<CANc9Z=wia7s0VN5eLM83cFAEWBo2k0+OojdO0rkmKwVmnmbrNA@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Mon, 27 Jul 2020 at 19:16, Dave <dave@triffid.co.uk> wrote:
> > Nb: Any particular reason why that message was added in recent
> > versions of RPCEmu?
> >
> Yes.
> Peter
Ah! A man of many words... ;-)
You could also have said. Because. (I just wanted to.)
But seriously, why?
Thanks
Dave
I have a vague recollection that VRPC also has a shutdown warning, but it
can be switched Off or On from Configuration.
D.
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CANc9Z=wia7s0VN5eLM83cFAEWBo2k0+OojdO0rkmKwVmnmbrNA@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Mon, 27 Jul 2020 at 19:16, Dave <dave@triffid.co.uk> wrote:
> > Nb: Any particular reason why that message was added in recent
> > versions of RPCEmu?
> >
> Yes.
> Peter
Ah! A man of many words... ;-)
You could also have said. Because. (I just wanted to.)
But seriously, why?
Thanks
Dave
I have a vague recollection that VRPC also has a shutdown warning, but it
can be switched Off or On from Configuration.
D.
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Shut down message
On Mon, 27 Jul 2020 at 19:16, Dave <dave@triffid.co.uk> wrote:
Nb: Any particular reason why that message was added in recent versions of
RPCEmu?
Yes.
Peter
Re: [Rpcemu] Shut down message
In article <A2F25D01-B195-4560-B20F-51CAA0FB8FAE@maemagel.com>,
Timothy Coltman <lists@maemagel.com> wrote:
[Snip]
[Snip]
> Not without editing the source and recompiling - see the
> "MainWindow::closeEvent" method in the "src/qt5/main_window.cpp" file.
> Tim
Thanks Tim, I also received privately... :-)
I think there's more chance of me going to the Moon, than doing that. :-)
Dave
Nb: Any particular reason why that message was added in recent versions of
RPCEmu?
D.
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Timothy Coltman <lists@maemagel.com> wrote:
[Snip]
[Snip]
> Not without editing the source and recompiling - see the
> "MainWindow::closeEvent" method in the "src/qt5/main_window.cpp" file.
> Tim
Thanks Tim, I also received privately... :-)
I think there's more chance of me going to the Moon, than doing that. :-)
Dave
Nb: Any particular reason why that message was added in recent versions of
RPCEmu?
D.
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Shut down message
On 27 Jul 2020, at 16:16, Dave <dave@triffid.co.uk> wrote:Every time I shut down RPCEmu I get...
"Are you sure you want to exit?
Any unsaved data will be lost."
Is there any way to excise this annoyance?
Thanks
Dave
Been using computers for 39 years, so I think by now I know what happens
when you close them down. ;-)
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tim
[Rpcemu] Shut down message
Every time I shut down RPCEmu I get...
"Are you sure you want to exit?
Any unsaved data will be lost."
Is there any way to excise this annoyance?
Thanks
Dave
Been using computers for 39 years, so I think by now I know what happens
when you close them down. ;-)
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
"Are you sure you want to exit?
Any unsaved data will be lost."
Is there any way to excise this annoyance?
Thanks
Dave
Been using computers for 39 years, so I think by now I know what happens
when you close them down. ;-)
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [gccsdk] Rebuilding the autobuilder packages
On 05/07/2020 21:27, alan buckley wrote:
> I�m about to start rebuilding the autobuilder packages and uploading new
> versions where appropriate. If you have updated items or their packaging
> in the autobuilder recently and would like me to build and upload those
> first please let me know.
>
> I�m not getting much time on this at the moment so any help in fixing
> packages or testing them will be much appreciated.
Just to let you know that I am working on updating some packages.
I've noticed a growing trend, particularly in the GTK family of
packages, to move away from the use of autotools (autoconf, automake)
towards more modern alternatives such as meson/ninja and cmake.
That's certainly not a bad thing, but I think for us, it's going
to cause a slight bump in the road as we find packages fail to
build because the autobuilder doesn't support these "new" methods.
It's not a major issue as packages can be transitioned as required,
and things can be made easier by adding new variables to the
autobuilder, for example, AB_MESON_CROSS_FILE that points to a ready
made cross file for meson or AB_CMAKE_TOOLCHAIN_FILE for cmake.
I'm already working on those, but I may also look at adding better
meson/ninja support to the autobuilder as well.
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
> I�m about to start rebuilding the autobuilder packages and uploading new
> versions where appropriate. If you have updated items or their packaging
> in the autobuilder recently and would like me to build and upload those
> first please let me know.
>
> I�m not getting much time on this at the moment so any help in fixing
> packages or testing them will be much appreciated.
Just to let you know that I am working on updating some packages.
I've noticed a growing trend, particularly in the GTK family of
packages, to move away from the use of autotools (autoconf, automake)
towards more modern alternatives such as meson/ninja and cmake.
That's certainly not a bad thing, but I think for us, it's going
to cause a slight bump in the road as we find packages fail to
build because the autobuilder doesn't support these "new" methods.
It's not a major issue as packages can be transitioned as required,
and things can be made easier by adding new variables to the
autobuilder, for example, AB_MESON_CROSS_FILE that points to a ready
made cross file for meson or AB_CMAKE_TOOLCHAIN_FILE for cmake.
I'm already working on those, but I may also look at adding better
meson/ninja support to the autobuilder as well.
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
Thursday, 23 July 2020
Re: [gccsdk] New SharedLibs incompatibility
In message <cad908a1-72cd-ba2a-348d-60dd77fe365c@sky.com>
Lee Noar <lee.noar@sky.com> wrote:
> On 23/07/2020 16:05, Chris Johns wrote:
>> I'd better get compiling.
>>
>> However, if I build it again the new libs I assume it won't work with
>> the older ones?
[snip]
> In hind sight, I should have placed "clock_id" *after* "waiting". The
> code in python is attempting to access "waiting", but getting "clock_id"
> instead, hence the value of 1 being used as an address. A rebuild
> against the new pthread.h will fix this but not for old libraries.
> I will swap the order of "clock_id" and "waiting" now.
> If python is then compiled against this new pthread.h and run using an
> old unixlib, then it will allocate an object larger than necessary
> (which is OK) and "waiting" will be in the right place.
To confirm that the current python38a6, built with GCCSDK GCC 4.7.4
Release 3, does start up with SharedLibs built from r7348.
--
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
Lee Noar <lee.noar@sky.com> wrote:
> On 23/07/2020 16:05, Chris Johns wrote:
>> I'd better get compiling.
>>
>> However, if I build it again the new libs I assume it won't work with
>> the older ones?
[snip]
> In hind sight, I should have placed "clock_id" *after* "waiting". The
> code in python is attempting to access "waiting", but getting "clock_id"
> instead, hence the value of 1 being used as an address. A rebuild
> against the new pthread.h will fix this but not for old libraries.
> I will swap the order of "clock_id" and "waiting" now.
> If python is then compiled against this new pthread.h and run using an
> old unixlib, then it will allocate an object larger than necessary
> (which is OK) and "waiting" will be in the right place.
To confirm that the current python38a6, built with GCCSDK GCC 4.7.4
Release 3, does start up with SharedLibs built from r7348.
--
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
NetSurf + MUSL (framebuffer;aarch64;Alpine Linux)
Alpine:RPi3:arm64:~/dev-netsurf/netsurf >>> make TARGET=framebuffer
M.CONFIG: JPEG (libjpeg) enabled (NETSURF_USE_JPEG := YES)
M.CONFIG: PDF export (haru) disabled (NETSURF_USE_HARU_PDF := NO)
M.CONFIG: glibc internal iconv enabled (NETSURF_USE_LIBICONV_PLUG := YES)
M.CONFIG: Javascript (Duktape) enabled (NETSURF_USE_DUKTAPE := YES)
PKG.CNFG: CSS (libcss) enabled
PKG.CNFG: DOM (libdom) enabled
PKG.CNFG: nsutils (libnsutils) enabled
M.CONFIG: Curl (libcurl) enabled (NETSURF_USE_CURL := YES)
M.CONFIG: OpenSSL (openssl) auto-enabled (NETSURF_USE_OPENSSL := AUTO)
M.CONFIG: utf8 (libutf8proc) enabled (NETSURF_USE_UTF8PROC := YES)
M.CONFIG: WEBP (libwebp) auto-disabled (NETSURF_USE_WEBP := AUTO)
M.CONFIG: PNG (libpng) auto-enabled (NETSURF_USE_PNG := AUTO)
M.CONFIG: BMP (libnsbmp) auto-enabled (NETSURF_USE_BMP := AUTO)
M.CONFIG: GIF (libnsgif) auto-enabled (NETSURF_USE_GIF := AUTO)
M.CONFIG: SVG (libsvgtiny) auto-disabled (NETSURF_USE_NSSVG := AUTO)
M.CONFIG: Sprite (librosprite) auto-enabled (NETSURF_USE_ROSPRITE := AUTO)
M.CONFIG: PSL (libnspsl) auto-enabled (NETSURF_USE_NSPSL := AUTO)
M.CONFIG: LOG (libnslog) auto-enabled (NETSURF_USE_NSLOG := AUTO)
PKG.CNFG: libnsfb (libnsfb) enabled
PKG.CNFG: Check (check) disabled
TESTMENT: unchanged
LINK: nsfb
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content__init':
/home/kend/dev-netsurf/netsurf/content/content.c:201: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_scaled_redraw':
/home/kend/dev-netsurf/netsurf/content/content.c:605: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_add_user':
/home/kend/dev-netsurf/netsurf/content/content.c:664: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_remove_user':
/home/kend/dev-netsurf/netsurf/content/content.c:693: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/content/content.c:703: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o:/home/kend/dev-netsurf/netsurf/content/content.c:79: more undefined references to `nslog_log' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:723: nsfb] Error 1
Alpine:RPi3:arm64:~/dev-netsurf/netsurf >>> exit
exit
M.CONFIG: JPEG (libjpeg) enabled (NETSURF_USE_JPEG := YES)
M.CONFIG: PDF export (haru) disabled (NETSURF_USE_HARU_PDF := NO)
M.CONFIG: glibc internal iconv enabled (NETSURF_USE_LIBICONV_PLUG := YES)
M.CONFIG: Javascript (Duktape) enabled (NETSURF_USE_DUKTAPE := YES)
PKG.CNFG: CSS (libcss) enabled
PKG.CNFG: DOM (libdom) enabled
PKG.CNFG: nsutils (libnsutils) enabled
M.CONFIG: Curl (libcurl) enabled (NETSURF_USE_CURL := YES)
M.CONFIG: OpenSSL (openssl) auto-enabled (NETSURF_USE_OPENSSL := AUTO)
M.CONFIG: utf8 (libutf8proc) enabled (NETSURF_USE_UTF8PROC := YES)
M.CONFIG: WEBP (libwebp) auto-disabled (NETSURF_USE_WEBP := AUTO)
M.CONFIG: PNG (libpng) auto-enabled (NETSURF_USE_PNG := AUTO)
M.CONFIG: BMP (libnsbmp) auto-enabled (NETSURF_USE_BMP := AUTO)
M.CONFIG: GIF (libnsgif) auto-enabled (NETSURF_USE_GIF := AUTO)
M.CONFIG: SVG (libsvgtiny) auto-disabled (NETSURF_USE_NSSVG := AUTO)
M.CONFIG: Sprite (librosprite) auto-enabled (NETSURF_USE_ROSPRITE := AUTO)
M.CONFIG: PSL (libnspsl) auto-enabled (NETSURF_USE_NSPSL := AUTO)
M.CONFIG: LOG (libnslog) auto-enabled (NETSURF_USE_NSLOG := AUTO)
PKG.CNFG: libnsfb (libnsfb) enabled
PKG.CNFG: Check (check) disabled
TESTMENT: unchanged
LINK: nsfb
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content__init':
/home/kend/dev-netsurf/netsurf/content/content.c:201: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_scaled_redraw':
/home/kend/dev-netsurf/netsurf/content/content.c:605: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_add_user':
/home/kend/dev-netsurf/netsurf/content/content.c:664: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_remove_user':
/home/kend/dev-netsurf/netsurf/content/content.c:693: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/content/content.c:703: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o:/home/kend/dev-netsurf/netsurf/content/content.c:79: more undefined references to `nslog_log' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:723: nsfb] Error 1
Alpine:RPi3:arm64:~/dev-netsurf/netsurf >>> exit
exit
Process shell exited abnormally with code 2
Alpine:RPi3:arm64:~/dev-netsurf/netsurf >>> make clean && make TARGET=framebuffer
CLEAN: testament.h
CLEAN: frontends/gtk/res/de/Messages frontends/gtk/res/en/Messages frontends/gtk/res/fr/Messages frontends/gtk/res/it/Messages frontends/gtk/res/nl/Messages
CLEAN: nsgtk3
CLEAN: build/Linux-gtk3
CLEAN: build/Linux-test
CLEAN: build/Linux-coverage
M.CONFIG: JPEG (libjpeg) enabled (NETSURF_USE_JPEG := YES)
M.CONFIG: PDF export (haru) enabled (NETSURF_USE_HARU_PDF := YES)
M.CONFIG: glibc internal iconv enabled (NETSURF_USE_LIBICONV_PLUG := YES)
M.CONFIG: Javascript (Duktape) enabled (NETSURF_USE_DUKTAPE := YES)
PKG.CNFG: CSS (libcss) enabled
PKG.CNFG: DOM (libdom) enabled
PKG.CNFG: nsutils (libnsutils) enabled
M.CONFIG: Curl (libcurl) enabled (NETSURF_USE_CURL := YES)
M.CONFIG: OpenSSL (openssl) auto-enabled (NETSURF_USE_OPENSSL := AUTO)
M.CONFIG: utf8 (libutf8proc) enabled (NETSURF_USE_UTF8PROC := YES)
M.CONFIG: WEBP (libwebp) auto-disabled (NETSURF_USE_WEBP := AUTO)
M.CONFIG: PNG (libpng) auto-enabled (NETSURF_USE_PNG := AUTO)
M.CONFIG: BMP (libnsbmp) auto-enabled (NETSURF_USE_BMP := AUTO)
M.CONFIG: GIF (libnsgif) auto-enabled (NETSURF_USE_GIF := AUTO)
M.CONFIG: SVG (libsvgtiny) auto-disabled (NETSURF_USE_NSSVG := AUTO)
M.CONFIG: Sprite (librosprite) auto-enabled (NETSURF_USE_ROSPRITE := AUTO)
M.CONFIG: PSL (libnspsl) auto-enabled (NETSURF_USE_NSPSL := AUTO)
M.CONFIG: LOG (libnslog) disabled (NETSURF_USE_NSLOG := NO)
PKG.CNFG: libnsfb (libnsfb) enabled
PKG.CNFG: Check (check) disabled
TESTMENT: build/Linux-framebuffer/testament.h
COMPILE: content/fetchers/about.c
COMPILE: desktop/version.c
LINK: nsfb
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/frontends_framebuffer_gui.o: in function `set_defaults':
/home/kend/dev-netsurf/netsurf/frontends/framebuffer/gui.c:565: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/frontends_framebuffer_gui.o: in function `fb_warn_user':
/home/kend/dev-netsurf/netsurf/frontends/framebuffer/gui.c:123: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/frontends_framebuffer_gui.o: in function `fb_browser_window_input':
/home/kend/dev-netsurf/netsurf/frontends/framebuffer/gui.c:856: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/frontends_framebuffer_gui.o: in function `gui_quit':
/home/kend/dev-netsurf/netsurf/frontends/framebuffer/gui.c:643: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/frontends_framebuffer_gui.o: in function `fb_browser_window_redraw':
/home/kend/dev-netsurf/netsurf/frontends/framebuffer/gui.c:416: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/frontends_framebuffer_gui.o:/home/kend/dev-netsurf/netsurf/frontends/framebuffer/gui.c:1650: more undefined references to `nslog__log' follow
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content__init':
/home/kend/dev-netsurf/netsurf/content/content.c:201: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_scaled_redraw':
/home/kend/dev-netsurf/netsurf/content/content.c:605: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_add_user':
/home/kend/dev-netsurf/netsurf/content/content.c:664: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o: in function `content_remove_user':
/home/kend/dev-netsurf/netsurf/content/content.c:693: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/content/content.c:703: undefined reference to `nslog_log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_content.o:/home/kend/dev-netsurf/netsurf/content/content.c:79: more undefined references to `nslog_log' follow
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_handlers_javascript_duktape_dukky.o: in function `dukky_populate_object':
/home/kend/dev-netsurf/netsurf/content/handlers/javascript/duktape/dukky.c:91: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_handlers_javascript_duktape_dukky.o: in function `dukky_dump_error':
/home/kend/dev-netsurf/netsurf/content/handlers/javascript/duktape/dukky.c:861: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_handlers_javascript_duktape_dukky.o: in function `dukky_push_node_stacked':
/home/kend/dev-netsurf/netsurf/content/handlers/javascript/duktape/dukky.c:180: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_handlers_javascript_duktape_dukky.o: in function `dukky_push_node_klass':
/home/kend/dev-netsurf/netsurf/content/handlers/javascript/duktape/dukky.c:427: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_handlers_javascript_duktape_dukky.o: in function `js_newthread':
/home/kend/dev-netsurf/netsurf/content/handlers/javascript/duktape/dukky.c:704: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/content_handlers_javascript_duktape_dukky.o:/home/kend/dev-netsurf/netsurf/content/handlers/javascript/duktape/dukky.c:732: more undefined references to `nslog__log' follow
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_log.o: in function `netsurf_render_log':
/home/kend/dev-netsurf/netsurf/utils/log.c:111: undefined reference to `nslog_short_level_name'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_log.o: in function `nslog_set_filter':
/home/kend/dev-netsurf/netsurf/utils/log.c:136: undefined reference to `nslog_filter_from_text'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:144: undefined reference to `nslog_filter_set_active'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:145: undefined reference to `nslog_filter_unref'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_log.o: in function `nslog_init':
/home/kend/dev-netsurf/netsurf/utils/log.c:256: undefined reference to `nslog_set_render_callback'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:259: undefined reference to `nslog_uncork'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:268: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:273: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:270: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_log.o: in function `nslog_finalise':
/home/kend/dev-netsurf/netsurf/utils/log.c:300: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/log.c:308: undefined reference to `nslog_cleanup'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_messages.o: in function `messages_add_from_file':
/home/kend/dev-netsurf/netsurf/utils/messages.c:183: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_messages.o: in function `messages_load_ctx':
/home/kend/dev-netsurf/netsurf/utils/messages.c:129: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_messages.o: in function `messages_add_from_inline':
/home/kend/dev-netsurf/netsurf/utils/messages.c:197: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_nsoption.o: in function `nsoption_read':
/home/kend/dev-netsurf/netsurf/utils/nsoption.c:746: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/kend/dev-netsurf/netsurf/utils/nsoption.c:742: undefined reference to `nslog__log'
/usr/lib/gcc/aarch64-alpine-linux-musl/9.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: build/Linux-framebuffer/utils_nsoption.o:/home/kend/dev-netsurf/netsurf/utils/nsoption.c:789: more undefined references to `nslog__log' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:723: nsfb] Error 1
Alpine:RPi3:arm64:~/dev-netsurf/netsurf >>> Greetings,
I am attempting to build NetSurf with TARGET=framebuffer on Alpine Linux
(musl,busybox,aarch64) but am having a bit of trouble and have not used
C in a couple of decades, so am not fast.
I was wondered if you could point me in the right direction.
Thanks a bunch!
-KenD
===================
Alpine:RPi3:arm64:~ >>> uname -a
Linux alpine 5.4.43-0-rpi #1-Alpine SMP PREEMPT Thu May 28 09:54:02 UTC
2020 aarch64 GNU/Linux
Alpine:RPi3:arm64:~ >>> gcc --version
gcc (Alpine 9.3.0) 9.3.0
===================
Re: [gccsdk] New SharedLibs incompatibility
On 23/07/2020 16:05, Chris Johns wrote:
> I'd better get compiling.
>
> However, if I build it again the new libs I assume it won't work with
> the older ones?
In theory, we might get away with it, but only if I change
__pthread_cond again. The original one was:
struct __pthread_cond
{
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};
and the new one:
struct __pthread_cond
{
/* Absolute (CLOCK_REALTIME) or relative (CLOCK_MONOTONIC) clock? */
clockid_t clock_id;
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};
In hind sight, I should have placed "clock_id" *after* "waiting". The
code in python is attempting to access "waiting", but getting "clock_id"
instead, hence the value of 1 being used as an address. A rebuild
against the new pthread.h will fix this but not for old libraries.
I will swap the order of "clock_id" and "waiting" now.
If python is then compiled against this new pthread.h and run using an
old unixlib, then it will allocate an object larger than necessary
(which is OK) and "waiting" will be in the right place.
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
> I'd better get compiling.
>
> However, if I build it again the new libs I assume it won't work with
> the older ones?
In theory, we might get away with it, but only if I change
__pthread_cond again. The original one was:
struct __pthread_cond
{
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};
and the new one:
struct __pthread_cond
{
/* Absolute (CLOCK_REALTIME) or relative (CLOCK_MONOTONIC) clock? */
clockid_t clock_id;
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};
In hind sight, I should have placed "clock_id" *after* "waiting". The
code in python is attempting to access "waiting", but getting "clock_id"
instead, hence the value of 1 being used as an address. A rebuild
against the new pthread.h will fix this but not for old libraries.
I will swap the order of "clock_id" and "waiting" now.
If python is then compiled against this new pthread.h and run using an
old unixlib, then it will allocate an object larger than necessary
(which is OK) and "waiting" will be in the right place.
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] New SharedLibs incompatibility
I'd better get compiling.
However, if I build it again the new libs I assume it won't work with
the older ones?
Cheers
Chris
On 23/07/2020 15:56, Lee Noar wrote:
> On 23/07/2020 12:38, David Pitt wrote:
>
>> Is r7347 the full fix?
>
> Yes, that fixes the Invalid argument error.
>
>> Previously running Python38a6 this was the error ;-
>>
>> pthread_cond_init: Invalid argument
>> Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
>> threads for interpreter
>> Python runtime state: unknown
>>
>> With r7347 and full rebuild of both build-world and ronative I get
>> this :-
>>
>> Fatal signal received: Segmentation fault
>>
>> Stack backtrace:
>>
>> Running thread 0x293344 (Main Thread)
>> ( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
>> __write_backtrace()
>> ( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
>> __unixlib_raise_signal()
>> ( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
>>
>> Register dump at 00807fb4:
>>
>> a1: 204da3b0 a2: 1 a3: 1 a4: 1
>> v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
>> v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
>> ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
>> cpsr: 20000010
>>
>> 474ca414 : ��� : ebfdee8a : BL &47445E44
>> 474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
>> 474ca41c : ..S� : e3530000 : CMP R3,#0
>> 474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
>> 474ca424 : ..�. : 13a01007 : MOVNE R1,#7
>> 474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
>> 474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
>> 474ca430 : ���� : ebfdf0ff : BL &47446834
>> 474ca434 : ..�� : e3a00000 : MOV R0,#0
>>
>> ( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
>> pthread_cond_signal()
>> ( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
>> PyThread_release_lock()
>> ( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
>> PyInterpreterState_New()
>> ( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
>> pyinit_core.constprop.10()
>> ( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
>> Py_InitializeFromConfig()
>> ( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
>> ( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
>> ( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
>
> I've just realised that this could be due to __pthread_cond
> increasing in size to support a relative clock_id. Any old code
> will assume the old size, so if python is built against an old
> pthread.h header, it will be using the old size.
>
> 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
--
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
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] New SharedLibs incompatibility
On 23/07/2020 12:38, David Pitt wrote:
> Is r7347 the full fix?
Yes, that fixes the Invalid argument error.
> Previously running Python38a6 this was the error ;-
>
> pthread_cond_init: Invalid argument
> Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
> threads for interpreter
> Python runtime state: unknown
>
> With r7347 and full rebuild of both build-world and ronative I get
> this :-
>
> Fatal signal received: Segmentation fault
>
> Stack backtrace:
>
> Running thread 0x293344 (Main Thread)
> ( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
> __write_backtrace()
> ( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
> __unixlib_raise_signal()
> ( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
>
> Register dump at 00807fb4:
>
> a1: 204da3b0 a2: 1 a3: 1 a4: 1
> v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
> v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
> ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
> cpsr: 20000010
>
> 474ca414 : ��� : ebfdee8a : BL &47445E44
> 474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
> 474ca41c : ..S� : e3530000 : CMP R3,#0
> 474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
> 474ca424 : ..�. : 13a01007 : MOVNE R1,#7
> 474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
> 474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
> 474ca430 : ���� : ebfdf0ff : BL &47446834
> 474ca434 : ..�� : e3a00000 : MOV R0,#0
>
> ( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
> pthread_cond_signal()
> ( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
> PyThread_release_lock()
> ( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
> PyInterpreterState_New()
> ( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
> pyinit_core.constprop.10()
> ( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
> Py_InitializeFromConfig()
> ( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
> ( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
> ( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
I've just realised that this could be due to __pthread_cond
increasing in size to support a relative clock_id. Any old code
will assume the old size, so if python is built against an old
pthread.h header, it will be using the old size.
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] New SharedLibs incompatibility
In message <589496c3efronanon@zoho.com>
Ron <ronanon@zoho.com> wrote:
> In article <d6bd8b9458.pittdj+@iyonix.home>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> With r7347 and full rebuild of both build-world and ronative I get
>> this :-
> I made the mistake of not doing make ronative-clean (or clean-ronative?)
> and got another copy of release 3, just saying in case someone assumes
> that it's already done.
Initially I did 'make clean' in gcc4 to get build-world to run again.
Then to make sure the build really was clean gccdsk was deleted and a
completely new build done. The Titanium was rebooted before every
test.
--
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
Ron <ronanon@zoho.com> wrote:
> In article <d6bd8b9458.pittdj+@iyonix.home>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> With r7347 and full rebuild of both build-world and ronative I get
>> this :-
> I made the mistake of not doing make ronative-clean (or clean-ronative?)
> and got another copy of release 3, just saying in case someone assumes
> that it's already done.
Initially I did 'make clean' in gcc4 to get build-world to run again.
Then to make sure the build really was clean gccdsk was deleted and a
completely new build done. The Titanium was rebooted before every
test.
--
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
Re: [gccsdk] New SharedLibs incompatibility
In message <a39ee097-8988-9994-1353-2323af3355bf@sky.com>
Lee Noar <lee.noar@sky.com> wrote:
> On 22/07/2020 08:04, alan buckley wrote:
>> The new version of the shared C libraries I�ve just released alongside
>> the new GCC release for RISC OS seem to be incompatible with programs
>> compiled against the previous version of GCC.
>>
>> I tried the Python3 download yesterday against the new shared libs and
>> it crashed complaining about pthread_cond.
[snip]
>> How should this be fixed?
> Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> It effects both the shared and static Unixlib libraries, but nothing
> else.
Is r7347 the full fix?
Previously running Python38a6 this was the error ;-
pthread_cond_init: Invalid argument
Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
threads for interpreter
Python runtime state: unknown
With r7347 and full rebuild of both build-world and ronative I get
this :-
Fatal signal received: Segmentation fault
Stack backtrace:
Running thread 0x293344 (Main Thread)
( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
__write_backtrace()
( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
__unixlib_raise_signal()
( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
Register dump at 00807fb4:
a1: 204da3b0 a2: 1 a3: 1 a4: 1
v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
cpsr: 20000010
474ca414 : ��� : ebfdee8a : BL &47445E44
474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
474ca41c : ..S� : e3530000 : CMP R3,#0
474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
474ca424 : ..�. : 13a01007 : MOVNE R1,#7
474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
474ca430 : ���� : ebfdf0ff : BL &47446834
474ca434 : ..�� : e3a00000 : MOV R0,#0
( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
pthread_cond_signal()
( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
PyThread_release_lock()
( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
PyInterpreterState_New()
( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
pyinit_core.constprop.10()
( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
Py_InitializeFromConfig()
( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
--
David Pitt
Titanium
Lee Noar <lee.noar@sky.com> wrote:
> On 22/07/2020 08:04, alan buckley wrote:
>> The new version of the shared C libraries I�ve just released alongside
>> the new GCC release for RISC OS seem to be incompatible with programs
>> compiled against the previous version of GCC.
>>
>> I tried the Python3 download yesterday against the new shared libs and
>> it crashed complaining about pthread_cond.
[snip]
>> How should this be fixed?
> Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> It effects both the shared and static Unixlib libraries, but nothing
> else.
Is r7347 the full fix?
Previously running Python38a6 this was the error ;-
pthread_cond_init: Invalid argument
Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
threads for interpreter
Python runtime state: unknown
With r7347 and full rebuild of both build-world and ronative I get
this :-
Fatal signal received: Segmentation fault
Stack backtrace:
Running thread 0x293344 (Main Thread)
( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
__write_backtrace()
( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
__unixlib_raise_signal()
( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
Register dump at 00807fb4:
a1: 204da3b0 a2: 1 a3: 1 a4: 1
v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
cpsr: 20000010
474ca414 : ��� : ebfdee8a : BL &47445E44
474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
474ca41c : ..S� : e3530000 : CMP R3,#0
474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
474ca424 : ..�. : 13a01007 : MOVNE R1,#7
474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
474ca430 : ���� : ebfdf0ff : BL &47446834
474ca434 : ..�� : e3a00000 : MOV R0,#0
( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
pthread_cond_signal()
( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
PyThread_release_lock()
( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
PyInterpreterState_New()
( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
pyinit_core.constprop.10()
( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
Py_InitializeFromConfig()
( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
--
David Pitt
Titanium
Wednesday, 22 July 2020
Re: [gccsdk] New SharedLibs incompatibility
On 22/07/2020 16:57, alan buckley wrote:
> Lee Noar <mailto:lee.noar@sky.com> wrote on 22 July 2020 11:30:
> > Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> > It effects both the shared and static Unixlib libraries, but nothing
> > else.
>
> Thanks for that Lee. How to I go about getting this into the wild?
>
> svn update and then ./build-world?
./build-world only does the cross compiler, you'll have to do:
make ronative
as well to rebuild the libraries in the native compiler. I think that's
where the packaged libraries come from.
> I assume I�ll have to create GCC 4.7.4 release 5 packages as I assume
> I can�t get away with just updating the shared c library package.
That's right, the static libraries within !GCC will need updating also.
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
> Lee Noar <mailto:lee.noar@sky.com> wrote on 22 July 2020 11:30:
> > Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> > It effects both the shared and static Unixlib libraries, but nothing
> > else.
>
> Thanks for that Lee. How to I go about getting this into the wild?
>
> svn update and then ./build-world?
./build-world only does the cross compiler, you'll have to do:
make ronative
as well to rebuild the libraries in the native compiler. I think that's
where the packaged libraries come from.
> I assume I�ll have to create GCC 4.7.4 release 5 packages as I assume
> I can�t get away with just updating the shared c library package.
That's right, the static libraries within !GCC will need updating also.
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] New SharedLibs incompatibility
Lee Noar wrote on 22 July 2020 11:30:
> > On 22/07/2020 08:04, alan buckley wrote:
> > The new version of the shared C libraries I�ve just released alongside
> > the new GCC release for RISC OS seem to be incompatible with programs
> > compiled against the previous version of GCC.
> >
> > I tried the Python3 download yesterday against the new shared libs and
> > it crashed complaining about pthread_cond.
> >
> > Any ideas why this may be? Has the abi changed? or is it something more
> > subtle?
> The good news is that this is nothing to do with dynamic linking. The
> (mildly) bad news is that I made a mistake in r7252. I must have misread
> the spec for pthread_cond_init and changed it to reject a NULL
> attribute. In fact a NULL attribute is valid and means use the default
> values.
> > How should this be fixed?
> Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> It effects both the shared and static Unixlib libraries, but nothing
> else.
Thanks for that Lee. How to I go about getting this into the wild?
svn update and then ./build-world?
I assume I'll have to create GCC 4.7.4 release 5 packages as I assume
I can't get away with just updating the shared c library package.
Regards,
Alan
Re: [gccsdk] New SharedLibs incompatibility
On 22/07/2020 08:04, alan buckley wrote:
> The new version of the shared C libraries I�ve just released alongside
> the new GCC release for RISC OS seem to be incompatible with programs
> compiled against the previous version of GCC.
>
> I tried the Python3 download yesterday against the new shared libs and
> it crashed complaining about pthread_cond.
>
> Any ideas why this may be? Has the abi changed? or is it something more
> subtle?
The good news is that this is nothing to do with dynamic linking. The
(mildly) bad news is that I made a mistake in r7252. I must have misread
the spec for pthread_cond_init and changed it to reject a NULL
attribute. In fact a NULL attribute is valid and means use the default
values.
> How should this be fixed?
Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
It effects both the shared and static Unixlib libraries, but nothing
else.
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
> The new version of the shared C libraries I�ve just released alongside
> the new GCC release for RISC OS seem to be incompatible with programs
> compiled against the previous version of GCC.
>
> I tried the Python3 download yesterday against the new shared libs and
> it crashed complaining about pthread_cond.
>
> Any ideas why this may be? Has the abi changed? or is it something more
> subtle?
The good news is that this is nothing to do with dynamic linking. The
(mildly) bad news is that I made a mistake in r7252. I must have misread
the spec for pthread_cond_init and changed it to reject a NULL
attribute. In fact a NULL attribute is valid and means use the default
values.
> How should this be fixed?
Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
It effects both the shared and static Unixlib libraries, but nothing
else.
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] New SharedLibs incompatibility
The new version of the shared C libraries I've just released alongside the new GCC release for RISC OS seem to be incompatible with programs compiled against the previous version of GCC.
I tried the Python3 download yesterday against the new shared libs and it crashed complaining about pthread_cond.
Any ideas why this may be? Has the abi changed? or is it something more subtle?
How should this be fixed?
I'm wondering about asking the few people who are shipping things that use the shared libraries to update there apps to use the new versions, but this may be asking too much.
If not, we need to ship a new version of the Shared libraries with a new version number and in a new package. Will we need new shared libraries for everything that depends on them (like Qt) as well?
Regards,
Alan
Wednesday, 15 July 2020
Re: [gccsdk] Can someone fix libsdl-mixer1.2?
On 14/07/2020 19:34, Alan wrote:
> I have been trying to get libsdl-mixer1.2 to build in the autobuilder
> without success.
>
> The problem seems to be that it won't build the VFP version of the
> shared libraries. I've looked about but couldn't see any obvious problems.
>
> Can someone else have a look and see what the problem is and fix it please?
Hi Alan,
Make sure you have RO_SHAREDLIBS=yes in the build-setvars file in your
build directory. If not, then a lot of the libraries will not build
with shared libraries. Having just started from scratch to look at
your problem, I made the mistake of forgetting it and experienced
the same issue as you. Now that I've added it, libsdl-mixer1.2 builds
successfully (you'll have to rebuild all its dependent libraries as
well).
For libtiff, I also had to remove the AB_CONFLAGS='--disable-static'
line from setvars otherwise it fails to build with the error "Unable
to stat dummy.o". I haven't committed it because I don't know why that
line was added in the first place.
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
> I have been trying to get libsdl-mixer1.2 to build in the autobuilder
> without success.
>
> The problem seems to be that it won't build the VFP version of the
> shared libraries. I've looked about but couldn't see any obvious problems.
>
> Can someone else have a look and see what the problem is and fix it please?
Hi Alan,
Make sure you have RO_SHAREDLIBS=yes in the build-setvars file in your
build directory. If not, then a lot of the libraries will not build
with shared libraries. Having just started from scratch to look at
your problem, I made the mistake of forgetting it and experienced
the same issue as you. Now that I've added it, libsdl-mixer1.2 builds
successfully (you'll have to rebuild all its dependent libraries as
well).
For libtiff, I also had to remove the AB_CONFLAGS='--disable-static'
line from setvars otherwise it fails to build with the error "Unable
to stat dummy.o". I haven't committed it because I don't know why that
line was added in the first place.
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
Tuesday, 14 July 2020
[gccsdk] Can someone fix libsdl-mixer1.2?
I have been trying to get libsdl-mixer1.2 to build in the autobuilder
without success.
The problem seems to be that it won't build the VFP version of the
shared libraries. I've looked about but couldn't see any obvious problems.
Can someone else have a look and see what the problem is and fix it please?
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
without success.
The problem seems to be that it won't build the VFP version of the
shared libraries. I've looked about but couldn't see any obvious problems.
Can someone else have a look and see what the problem is and fix it please?
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
Monday, 13 July 2020
Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released
Lee Noar wrote on 12 July 2020 12:32:
> There is a native RISC OS version of GCC 8 now (autobuilder/develop/gcc),
> so perhaps we could look at doing a release of that. It produces a
> skeleton !SharedLibs with just the new runtime libraries and this is
> merged into to the GCC 4 !SharedLibs (so not standalone).
> The two !GCCs would need to be kept separate though I think,
> I've not looked at how to run two different versions of the
> compiler from the same !GCC.
I wonder if we should just have a !GCC8 and it's expected the user will
boot the correct one or double click on it before compiling to switch
the tools used.
The shared library packaging won't be a problem. I think we just need
a package with the GCC8 shared libraries that depends on the basic
SharedLibs package.
Regards,
Alan
Sunday, 12 July 2020
Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released
Lee
Many thanks for all your support of GCC, it will be great to have Fortran back on RISCOS once again. Norman
On Mon., 13 Jul. 2020, 02:35 Lee Noar, <lee.noar@sky.com> wrote:
On 12/07/2020 13:57, Norman Lawrence wrote:
> Hi Lee
> I understood that the GCC 4.7.2 also has Fortran, is that not the case?
> I know that the Linux version comes with Fortran.
Yes, I will try and enable it it GCC4, if it builds as well as it did in
GCC8, then it shouldn't be a problem.
Sorry about the mix up, looking back I can see we were talking about
different GCC versions.
Lee.
Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released
On 12/07/2020 13:57, Norman Lawrence wrote:
> Hi Lee
> I understood that the GCC 4.7.2 also has Fortran, is that not the case?
> I know that the Linux version comes with Fortran.
Yes, I will try and enable it it GCC4, if it builds as well as it did in
GCC8, then it shouldn't be a problem.
Sorry about the mix up, looking back I can see we were talking about
different GCC versions.
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
> Hi Lee
> I understood that the GCC 4.7.2 also has Fortran, is that not the case?
> I know that the Linux version comes with Fortran.
Yes, I will try and enable it it GCC4, if it builds as well as it did in
GCC8, then it shouldn't be a problem.
Sorry about the mix up, looking back I can see we were talking about
different GCC versions.
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] RISC OS GCC 4.7.4 release 4 has been released
Hi Lee
I understood that the GCC 4.7.2 also has Fortran, is that not the case? I know that the Linux version comes with Fortran.
Best regards
Norman
On Sun., 12 Jul. 2020, 21:32 Lee Noar, <lee.noar@sky.com> wrote:
On 12/07/2020 12:17, alan buckley wrote:
> I�m not sure how the fortran compiler is built. Is it part of the
> build-world process or is it somewhere else?
>
> I didn�t add anything to package it, but if someone can tell me how it�s
> built and where the files are put I can add it to the packages created
> and upload it.
Hi Alan,
The Fortran compiler is actually part of GCC 8 rather than GCC 4.
There is a native RISC OS version of GCC 8 now (autobuilder/develop/gcc),
so perhaps we could look at doing a release of that. It produces a
skeleton !SharedLibs with just the new runtime libraries and this is
merged into to the GCC 4 !SharedLibs (so not standalone).
The two !GCCs would need to be kept separate though I think,
I've not looked at how to run two different versions of the
compiler from the same !GCC.
Thanks,
Lee.
Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released
On 12/07/2020 12:17, alan buckley wrote:
> I�m not sure how the fortran compiler is built. Is it part of the
> build-world process or is it somewhere else?
>
> I didn�t add anything to package it, but if someone can tell me how it�s
> built and where the files are put I can add it to the packages created
> and upload it.
Hi Alan,
The Fortran compiler is actually part of GCC 8 rather than GCC 4.
There is a native RISC OS version of GCC 8 now (autobuilder/develop/gcc),
so perhaps we could look at doing a release of that. It produces a
skeleton !SharedLibs with just the new runtime libraries and this is
merged into to the GCC 4 !SharedLibs (so not standalone).
The two !GCCs would need to be kept separate though I think,
I've not looked at how to run two different versions of the
compiler from the same !GCC.
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
> I�m not sure how the fortran compiler is built. Is it part of the
> build-world process or is it somewhere else?
>
> I didn�t add anything to package it, but if someone can tell me how it�s
> built and where the files are put I can add it to the packages created
> and upload it.
Hi Alan,
The Fortran compiler is actually part of GCC 8 rather than GCC 4.
There is a native RISC OS version of GCC 8 now (autobuilder/develop/gcc),
so perhaps we could look at doing a release of that. It produces a
skeleton !SharedLibs with just the new runtime libraries and this is
merged into to the GCC 4 !SharedLibs (so not standalone).
The two !GCCs would need to be kept separate though I think,
I've not looked at how to run two different versions of the
compiler from the same !GCC.
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] RISC OS GCC 4.7.4 release 4 has been released
I'm not sure how the fortran compiler is built. Is it part of the build-world process or is it somewhere else?
I didn't add anything to package it, but if someone can tell me how it's built and where the files are put I can add it to the packages created and upload it.
Regards,
Alan
From: Norman Lawrence
Sent: 12 July 2020 07:16
To: alan buckley
Cc: gcc@gccsdk.riscos.info
Subject: Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released
Hi Alan
Many thanks for all the hard work that you have put into packaging this release and also to all the other people who helped to create the new release. I was under the impression that this release would include Fortran as part of the new release. Was I mistaken or is there some more work to be done before it can be released with the GCC 4.6.2 pac
Best wishes
Norman
On Mon, 6 Jul 2020 at 06:24, alan buckley <alan_baa@hotmail.com> wrote:
I've finally managed to get all the bits and pieces together and have released GCC 4.7.4 release 4 based on the GCCSDK code this weekend.
I believe I've updated all the relevant pages and entries at www.riscos.info (e.g. http://www.riscos.info/index.php/GCC). If anyone want to check these and either edit them or let me know of any mistakes or omissions it would be appreciated.
I've also posted to comp.sys.acorn.announce and the ROOL forums that it's available.
_______________________________________________
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, 11 July 2020
Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released
Hi Alan
Many thanks for all the hard work that you have put into packaging this release and also to all the other people who helped to create the new release. I was under the impression that this release would include Fortran as part of the new release. Was I mistaken or is there some more work to be done before it can be released with the GCC 4.6.2 pac
Best wishes
Norman
On Mon, 6 Jul 2020 at 06:24, alan buckley <alan_baa@hotmail.com> wrote:
_______________________________________________I've finally managed to get all the bits and pieces together and have released GCC 4.7.4 release 4 based on the GCCSDK code this weekend.
I believe I've updated all the relevant pages and entries at www.riscos.info (e.g. http://www.riscos.info/index.php/GCC). If anyone want to check these and either edit them or let me know of any mistakes or omissions it would be appreciated.
I've also posted to comp.sys.acorn.announce and the ROOL forums that it's available.
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, 10 July 2020
Re: [gccsdk] GCC 4.7.4 Rel 4: isblank()
On 09/07/2020 11:44, Duncan Moore wrote:
> First of all, many thanks to everyone who's contributed to the latest
> release.
>
> There are a couple of issues with isblank():
>
> 1) In <ctype.h>, isblank() is incorrectly defined the same as isspace():
> �� #� define isspace(c) (__ctype[(int) (c)] & ___ctype_white)
> �� #� define isblank(c) (__ctype[(int) (c)] & ___ctype_white)
>
> 2) When there's a function pointer to isblank(), I get a link failure:
> "undefined reference to `isblank'".
>
> So this program:
>
> #include <stdio.h>
> #include <ctype.h>
> int main(void) {
> � int (*space)(int)=isspace;
> � int (*blank)(int)=isblank;������ // Fails to link.
>
> � printf("%i\n",!!isspace('\n'));
> � printf("%i\n",!!space('\n'));
>
> � printf("%i\n",!!isblank('\n'));
> � printf("%i\n",!!blank('\n'));��� // Fails to link.
>
> � return 0;
> }
>
> should give:
>
> 1
> 1
> 0
> 0
>
> whereas, if the 2 lines with comments are removed, I get:
>
> 1
> 1
> 1
>
> and it fails to link otherwise.
Ok, thanks for that, I can see that I failed to provide an isblank()
function to go with the macro.
Some googling shows that isblank() should return true only for a space
character or a tab. I could implement this easily in the function (and
remove the macro) by testing the characters directly, e.g.:
return (c == ' ' || c == '\t');
however, that doesn't go via the territory module like the other
ctype functions/macros do. On the other hand, the territory
module doesn't seem to distinguish this particular combination,
so I may have to cheat as above.
Does anyone know different or do I go with the cheat?
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
> First of all, many thanks to everyone who's contributed to the latest
> release.
>
> There are a couple of issues with isblank():
>
> 1) In <ctype.h>, isblank() is incorrectly defined the same as isspace():
> �� #� define isspace(c) (__ctype[(int) (c)] & ___ctype_white)
> �� #� define isblank(c) (__ctype[(int) (c)] & ___ctype_white)
>
> 2) When there's a function pointer to isblank(), I get a link failure:
> "undefined reference to `isblank'".
>
> So this program:
>
> #include <stdio.h>
> #include <ctype.h>
> int main(void) {
> � int (*space)(int)=isspace;
> � int (*blank)(int)=isblank;������ // Fails to link.
>
> � printf("%i\n",!!isspace('\n'));
> � printf("%i\n",!!space('\n'));
>
> � printf("%i\n",!!isblank('\n'));
> � printf("%i\n",!!blank('\n'));��� // Fails to link.
>
> � return 0;
> }
>
> should give:
>
> 1
> 1
> 0
> 0
>
> whereas, if the 2 lines with comments are removed, I get:
>
> 1
> 1
> 1
>
> and it fails to link otherwise.
Ok, thanks for that, I can see that I failed to provide an isblank()
function to go with the macro.
Some googling shows that isblank() should return true only for a space
character or a tab. I could implement this easily in the function (and
remove the macro) by testing the characters directly, e.g.:
return (c == ' ' || c == '\t');
however, that doesn't go via the territory module like the other
ctype functions/macros do. On the other hand, the territory
module doesn't seem to distinguish this particular combination,
so I may have to cheat as above.
Does anyone know different or do I go with the cheat?
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
Thursday, 9 July 2020
[gccsdk] GCC 4.7.4 Rel 4: isblank()
First of all, many thanks to everyone who's contributed to the latest
release.
There are a couple of issues with isblank():
1) In <ctype.h>, isblank() is incorrectly defined the same as isspace():
# define isspace(c) (__ctype[(int) (c)] & ___ctype_white)
# define isblank(c) (__ctype[(int) (c)] & ___ctype_white)
2) When there's a function pointer to isblank(), I get a link failure:
"undefined reference to `isblank'".
So this program:
#include <stdio.h>
#include <ctype.h>
int main(void) {
int (*space)(int)=isspace;
int (*blank)(int)=isblank; // Fails to link.
printf("%i\n",!!isspace('\n'));
printf("%i\n",!!space('\n'));
printf("%i\n",!!isblank('\n'));
printf("%i\n",!!blank('\n')); // Fails to link.
return 0;
}
should give:
1
1
0
0
whereas, if the 2 lines with comments are removed, I get:
1
1
1
and it fails to link otherwise.
Regards
Duncan Moore
gcc (GCCSDK GCC 4.7.4 Release 4) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISCOS 4.39
_______________________________________________
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
release.
There are a couple of issues with isblank():
1) In <ctype.h>, isblank() is incorrectly defined the same as isspace():
# define isspace(c) (__ctype[(int) (c)] & ___ctype_white)
# define isblank(c) (__ctype[(int) (c)] & ___ctype_white)
2) When there's a function pointer to isblank(), I get a link failure:
"undefined reference to `isblank'".
So this program:
#include <stdio.h>
#include <ctype.h>
int main(void) {
int (*space)(int)=isspace;
int (*blank)(int)=isblank; // Fails to link.
printf("%i\n",!!isspace('\n'));
printf("%i\n",!!space('\n'));
printf("%i\n",!!isblank('\n'));
printf("%i\n",!!blank('\n')); // Fails to link.
return 0;
}
should give:
1
1
0
0
whereas, if the 2 lines with comments are removed, I get:
1
1
1
and it fails to link otherwise.
Regards
Duncan Moore
gcc (GCCSDK GCC 4.7.4 Release 4) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISCOS 4.39
_______________________________________________
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
Tuesday, 7 July 2020
Re: possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly
Hi John,
On 06/07/2020 23:31, jcupitt@gmail.com wrote:
> First, line 438 modifies the input buffer:
>
> http://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c?id=8442a27c2bb8df48029ceea6e64c4930106a57fc#n438
>
> This feels a bit ugly to me, and it doesn't work for us, since the
> input buffer can be a mmaped file. I patched this to just return
> GIF_INSUFFICIENT_FRAME_DATA.
That sounds like a good idea. If we run into problems with partial
gifs we can find another way to display what we have that doesn't
involve modifying the input buffer.
> Second, gif_decode_frame(gif, frame_number) seems like the wrong API.
> You can only call this function with frame_number ascending, and you
> must always start from 0 and loop, but this restriction is not obvious
> from the function.
There are a few reasons for this behaviour.
At the moment in NetSurf, if a web page is showing an animated gif, we
schedule a callback with our scheduler to happen when the gif frame
delay has elapsed. When the callback fires, we simply increment the
number of the frame that should be shown inside NetSurf and cause the
gif to notify its users that its area is "dirty" and needs to be redrawn.
When that bit of the screen is redrawn, the gif redraw code decodes
enough frames to get back to where it should be in the animation and
shows that frame.
An advantage of this is that if there's a gif off-screen further down
the page, or on a tab that's not the current tab, we don't have to waste
time decoding frames that aren't getting rendered.
Another point is that the same gif may be used on many open tabs, and
even many times on the same page. NetSurf shares contents, so all these
instances share the same libnsgif instance for the animation.
This keeps all instances of the animation in lock step, which is
visually pleasing as well as efficient.
Finally, the libnsgif code was originally stripped out of NetSurf into a
separate library, and it still contains some some of this legacy in its API.
> How about having frame_number as a member, and renaming it to
> gif_decode_next_frame(gif)? It could handle looping too.
>
> gif_decode_frame() could be marked as deprecated, and just call
> gif_decode_next_frame() without using the frame_number parameter. It
> should be compatible and the API would be simpler and clearer. I may
> well have misunderstood things, of course
NetSurf could be made to work with your proposed change, and I agree
it's a cleaner API.
I probably wouldn't even keep the old `gif_decode_frame()` as
deprecated. Just change it. I think its API needs quite a bit of
cleaning up before we call it 1.0 and stop making breaking changes.
Cheers,
--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
On 06/07/2020 23:31, jcupitt@gmail.com wrote:
> First, line 438 modifies the input buffer:
>
> http://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c?id=8442a27c2bb8df48029ceea6e64c4930106a57fc#n438
>
> This feels a bit ugly to me, and it doesn't work for us, since the
> input buffer can be a mmaped file. I patched this to just return
> GIF_INSUFFICIENT_FRAME_DATA.
That sounds like a good idea. If we run into problems with partial
gifs we can find another way to display what we have that doesn't
involve modifying the input buffer.
> Second, gif_decode_frame(gif, frame_number) seems like the wrong API.
> You can only call this function with frame_number ascending, and you
> must always start from 0 and loop, but this restriction is not obvious
> from the function.
There are a few reasons for this behaviour.
At the moment in NetSurf, if a web page is showing an animated gif, we
schedule a callback with our scheduler to happen when the gif frame
delay has elapsed. When the callback fires, we simply increment the
number of the frame that should be shown inside NetSurf and cause the
gif to notify its users that its area is "dirty" and needs to be redrawn.
When that bit of the screen is redrawn, the gif redraw code decodes
enough frames to get back to where it should be in the animation and
shows that frame.
An advantage of this is that if there's a gif off-screen further down
the page, or on a tab that's not the current tab, we don't have to waste
time decoding frames that aren't getting rendered.
Another point is that the same gif may be used on many open tabs, and
even many times on the same page. NetSurf shares contents, so all these
instances share the same libnsgif instance for the animation.
This keeps all instances of the animation in lock step, which is
visually pleasing as well as efficient.
Finally, the libnsgif code was originally stripped out of NetSurf into a
separate library, and it still contains some some of this legacy in its API.
> How about having frame_number as a member, and renaming it to
> gif_decode_next_frame(gif)? It could handle looping too.
>
> gif_decode_frame() could be marked as deprecated, and just call
> gif_decode_next_frame() without using the frame_number parameter. It
> should be compatible and the API would be simpler and clearer. I may
> well have misunderstood things, of course
NetSurf could be made to work with your proposed change, and I agree
it's a cleaner API.
I probably wouldn't even keep the old `gif_decode_frame()` as
deprecated. Just change it. I think its API needs quite a bit of
cleaning up before we call it 1.0 and stop making breaking changes.
Cheers,
--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Monday, 6 July 2020
Re: possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly
Thank you Michael! It now renders that test case correctly, and runs
cleanly with valgrind.
I had a couple of other small ideas for improvements to libnsgif, if
changes are being made. I'd be happy to have a go at a patch if they
sound useful.
First, line 438 modifies the input buffer:
http://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c?id=8442a27c2bb8df48029ceea6e64c4930106a57fc#n438
This feels a bit ugly to me, and it doesn't work for us, since the
input buffer can be a mmaped file. I patched this to just return
GIF_INSUFFICIENT_FRAME_DATA.
Second, gif_decode_frame(gif, frame_number) seems like the wrong API.
You can only call this function with frame_number ascending, and you
must always start from 0 and loop, but this restriction is not obvious
from the function.
How about having frame_number as a member, and renaming it to
gif_decode_next_frame(gif)? It could handle looping too.
gif_decode_frame() could be marked as deprecated, and just call
gif_decode_next_frame() without using the frame_number parameter. It
should be compatible and the API would be simpler and clearer. I may
well have misunderstood things, of course.
John
On Mon, 6 Jul 2020 at 17:03, Michael Drake
<michael.drake@codethink.co.uk> wrote:
>
> On 06/07/2020 10:07, Michael Drake wrote:
> > On 04/07/2020 15:25, jcupitt@gmail.com wrote:
> >> On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
>
> >>> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>
> >>> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
>
> > Thanks for this! I hope to have a fix for you to test later today.
>
> Please try with this:
>
> http://source.netsurf-browser.org/libnsgif.git/commit/?id=8442a27c2bb8df48029ceea6e64c4930106a57fc
>
> Cheers,
>
> --
> Michael Drake https://www.codethink.co.uk/
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
cleanly with valgrind.
I had a couple of other small ideas for improvements to libnsgif, if
changes are being made. I'd be happy to have a go at a patch if they
sound useful.
First, line 438 modifies the input buffer:
http://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c?id=8442a27c2bb8df48029ceea6e64c4930106a57fc#n438
This feels a bit ugly to me, and it doesn't work for us, since the
input buffer can be a mmaped file. I patched this to just return
GIF_INSUFFICIENT_FRAME_DATA.
Second, gif_decode_frame(gif, frame_number) seems like the wrong API.
You can only call this function with frame_number ascending, and you
must always start from 0 and loop, but this restriction is not obvious
from the function.
How about having frame_number as a member, and renaming it to
gif_decode_next_frame(gif)? It could handle looping too.
gif_decode_frame() could be marked as deprecated, and just call
gif_decode_next_frame() without using the frame_number parameter. It
should be compatible and the API would be simpler and clearer. I may
well have misunderstood things, of course.
John
On Mon, 6 Jul 2020 at 17:03, Michael Drake
<michael.drake@codethink.co.uk> wrote:
>
> On 06/07/2020 10:07, Michael Drake wrote:
> > On 04/07/2020 15:25, jcupitt@gmail.com wrote:
> >> On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
>
> >>> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>
> >>> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
>
> > Thanks for this! I hope to have a fix for you to test later today.
>
> Please try with this:
>
> http://source.netsurf-browser.org/libnsgif.git/commit/?id=8442a27c2bb8df48029ceea6e64c4930106a57fc
>
> Cheers,
>
> --
> Michael Drake https://www.codethink.co.uk/
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Re: possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly
On 06/07/2020 10:07, Michael Drake wrote:
> On 04/07/2020 15:25, jcupitt@gmail.com wrote:
>> On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
>>> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>>> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
> Thanks for this! I hope to have a fix for you to test later today.
Please try with this:
http://source.netsurf-browser.org/libnsgif.git/commit/?id=8442a27c2bb8df48029ceea6e64c4930106a57fc
Cheers,
--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
> On 04/07/2020 15:25, jcupitt@gmail.com wrote:
>> On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
>>> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>>> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
> Thanks for this! I hope to have a fix for you to test later today.
Please try with this:
http://source.netsurf-browser.org/libnsgif.git/commit/?id=8442a27c2bb8df48029ceea6e64c4930106a57fc
Cheers,
--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Re: possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly
On 04/07/2020 15:25, jcupitt@gmail.com wrote:
> On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
>> Thank you for libnsgif. I think I might have come across a gif that
>> fails to render correctly in libnsgif-0.2.1:
>>
>> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>>
>> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
>> libnsgif does not seem to handle this though, and the tips are left
>> behind.
>
> Hello again, I spent a little time looking at the code.
>
> tldr: I think GIFs which have a COMBINE frame followed by a RESTORE
> frame will not render correctly in libnsgif.
Thanks for this! I hope to have a fix for you to test later today.
Cheers,
--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
> On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
>> Thank you for libnsgif. I think I might have come across a gif that
>> fails to render correctly in libnsgif-0.2.1:
>>
>> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>>
>> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
>> libnsgif does not seem to handle this though, and the tips are left
>> behind.
>
> Hello again, I spent a little time looking at the code.
>
> tldr: I think GIFs which have a COMBINE frame followed by a RESTORE
> frame will not render correctly in libnsgif.
Thanks for this! I hope to have a fix for you to test later today.
Cheers,
--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Sunday, 5 July 2020
[gccsdk] Rebuilding the autobuilder packages
I'm about to start rebuilding the autobuilder packages and uploading new versions where appropriate. If you have updated items or their packaging in the autobuilder recently and would like me to build and upload those first please let me know.
I'm not getting much time on this at the moment so any help in fixing packages or testing them will be much appreciated.
Regards,
Alan
[gccsdk] RISC OS GCC 4.7.4 release 4 has been released
I've finally managed to get all the bits and pieces together and have released GCC 4.7.4 release 4 based on the GCCSDK code this weekend.
I believe I've updated all the relevant pages and entries at www.riscos.info (e.g. http://www.riscos.info/index.php/GCC). If anyone want to check these and either edit them or let me know of any mistakes or omissions it would be appreciated.
I've also posted to comp.sys.acorn.announce and the ROOL forums that it's available.
Saturday, 4 July 2020
Re: possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly
On Fri, 3 Jul 2020 at 12:16, <jcupitt@gmail.com> wrote:
> Thank you for libnsgif. I think I might have come across a gif that
> fails to render correctly in libnsgif-0.2.1:
>
> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>
> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
> libnsgif does not seem to handle this though, and the tips are left
> behind.
Hello again, I spent a little time looking at the code.
tldr: I think GIFs which have a COMBINE frame followed by a RESTORE
frame will not render correctly in libnsgif.
1. The frames in this GIF (except for frame 5) have disposal_method 1,
GIF_FRAME_COMBINE, ie. the frame is not cleared and pixels accumulate.
2. Frame 5 is GIF_FRAME_RESTORE, meaning that after frame 5 is
rendered, the frame should be restored to frame 4. This is detected
when frame 6 rendering starts here:
https://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c#n794
And it calls gif_internal_decode_frame() recursively to put the pixels
for frame 4 back.
3. However, because frame 4 is GIF_FRAME_COMBINE, the frame 4 pixels
are incorrectly painted on top of frame 5.
4. gif_internal_decode_frame() then decode the pixels for frame 6, but
because frame 4 has not been restored, the wingtips are left behind.
The problem is that with GIF_FRAME_COMBINE, the state of a GIF frame
depends on all the previous frames. You can't just call
gif_internal_decode_frame() to put the pixels back --- you need to
re-render the entire animation.
It seems to me that the best way to implement GIF_FRAME_RESTORE is to
have an extra bitmap in the gif struct to hold the restore pixels.
When processing a frame with GIF_FRAME_RESTORE set, a copy should be
made of the frame before painting in the new pixels. When processing a
frame whose /previous/ frame is GIF_FRAME_RESTORE, the frame should be
initialised from the previous bitmap.
Does this sound reasonable? I could try to make a patch if there's interest.
John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
> Thank you for libnsgif. I think I might have come across a gif that
> fails to render correctly in libnsgif-0.2.1:
>
> https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
>
> Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
> libnsgif does not seem to handle this though, and the tips are left
> behind.
Hello again, I spent a little time looking at the code.
tldr: I think GIFs which have a COMBINE frame followed by a RESTORE
frame will not render correctly in libnsgif.
1. The frames in this GIF (except for frame 5) have disposal_method 1,
GIF_FRAME_COMBINE, ie. the frame is not cleared and pixels accumulate.
2. Frame 5 is GIF_FRAME_RESTORE, meaning that after frame 5 is
rendered, the frame should be restored to frame 4. This is detected
when frame 6 rendering starts here:
https://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c#n794
And it calls gif_internal_decode_frame() recursively to put the pixels
for frame 4 back.
3. However, because frame 4 is GIF_FRAME_COMBINE, the frame 4 pixels
are incorrectly painted on top of frame 5.
4. gif_internal_decode_frame() then decode the pixels for frame 6, but
because frame 4 has not been restored, the wingtips are left behind.
The problem is that with GIF_FRAME_COMBINE, the state of a GIF frame
depends on all the previous frames. You can't just call
gif_internal_decode_frame() to put the pixels back --- you need to
re-render the entire animation.
It seems to me that the best way to implement GIF_FRAME_RESTORE is to
have an extra bitmap in the gif struct to hold the restore pixels.
When processing a frame with GIF_FRAME_RESTORE set, a copy should be
made of the frame before painting in the new pixels. When processing a
frame whose /previous/ frame is GIF_FRAME_RESTORE, the frame should be
initialised from the previous bitmap.
Does this sound reasonable? I could try to make a patch if there's interest.
John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Friday, 3 July 2020
possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly
Hello all,
Thank you for libnsgif. I think I might have come across a gif that
fails to render correctly in libnsgif-0.2.1:
https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
libnsgif does not seem to handle this though, and the tips are left
behind. Unless I'm not calling libnsgif correctly.
Here's the original issue for context:
https://github.com/libvips/libvips/issues/1084
And our test libnsgif loader:
https://github.com/libvips/libvips/blob/add-libnsgif/libvips/foreign/gifnsload.c
John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Thank you for libnsgif. I think I might have come across a gif that
fails to render correctly in libnsgif-0.2.1:
https://user-images.githubusercontent.com/580843/86457777-18bd1400-bd1c-11ea-923a-adeed2eba031.gif
Frame 6 is DISPOSE_PREVIOUS and should unpaint the tips of the wings.
libnsgif does not seem to handle this though, and the tips are left
behind. Unless I'm not calling libnsgif correctly.
Here's the original issue for context:
https://github.com/libvips/libvips/issues/1084
And our test libnsgif loader:
https://github.com/libvips/libvips/blob/add-libnsgif/libvips/foreign/gifnsload.c
John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Subscribe to:
Posts (Atom)