Mailing Lists

Monday, 6 February 2017

Re: [gccsdk] Problem with autobuilder (newbie questions)

In message <5605f55f4echrisg@care4free.net>
on 29 Jan 2017 Chris Gransden wrote:

> In article <399fb40556.Matthew@sinenomine.freeserve.co.uk>,
> Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
>
> > $ cd build
> > $ ../autobuilder/build -v wget
>
> > as instructed. As with gpsbabel the first thing it tries to do is fetch
> > and compile native-zip. Again, after doing the patching, make starts and
> > we get the same errors as before:

[snip]

> native-zip should be getting built by the host compiler but instead it
> looks like the autobuilder installed compiler is being used.
> Have you set any envionment variables? Does echo $CC output anything.
> Are any of the autobuilder folders in your PATH? e.g.
> /home/matthew/gccsdk/env.

Again, it was a result of my being stupid. I had been reading a posting on
the ROOL forum in which someone sought advice on getting started with GCCSDK
(see https://www.riscosopen.org/forum/forums/11/topics/6289 ) and the fifth
posting, from Jeffrey Lee, suggested doing:

cd path/to/gccsdk
source env/ro-path

The second time I was vaguely aware this was not necessary but had run it to
check what needed to go in build-setvars and stupidly used the same shell for
the next steps.

Anyway, with a fresh shell I have now tried:

cd ~/gccsdk/build
../autobuilder/build -v wget

I get a report which concludes with:

Package wget: Success

This looks quite promising. I tried to locate the compiled wget, but when I
looked in ./gccsdk/autobuilder/network/wget there was a !Wget but nothing
executable in it. Using the Unix find command did not locate it.

I have now found in ./gccsdk/autobuilder/autobuilder_packages/Network that a
new wget_1.18-2.zip had been created and inside Apps.Network.!Wget there is a
wget executable. So I think everything is OK.

I then managed to update my autobuilder installation to pick up your new
commits relating to gpsbabel

I tried running

cd ~/gccsdk/build
../autobuilder/build -v gpsbabel

It starts by trying Qt5Base, but this fails, and if I grep the last-failure
file for "error" case insensitively I get these lines at the end:

/home/matthew/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: error: /home/matthew/gccsdk/env/lib/libQt5PlatformSupport.a(qgenericunixeventdispatcher.o) uses FPA instructions, whereas libqminimal.so does not
/home/matthew/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: error: /home/matthew/gccsdk/env/lib/libQt5PlatformSupport.a(qunixeventdispatcher.o) uses FPA instructions, whereas libqminimal.so does not
collect2: error: ld returned 1 exit status
make[4]: *** [../../../../plugins/platforms/libqminimal.so] Error 1
make[3]: *** [sub-minimal-make_first] Error 2
make[2]: *** [sub-platforms-make_first] Error 2
make[1]: *** [sub-plugins-make_first] Error 2
make: *** [sub-src-make_first] Error 2

Do you have any further suggestions? It looks like a build incompatibility
between a couple of components to do with the floating point.

> You can download gpsbabel from
> http://www.riscosports.co.uk/gpsbabel_1.5.3-1.zip. It also depends on
> Qt5Base being installed. If you use PackMan to install it the rest of the
> dependencies will be installed as well.

I've installed this successfully and tried converting a file. It seems to
work, but one of the points ended up with a latitude of "nan" rather than a
number, and that caused RiscOSM to crash when loading it. (Obviously we need
to make RiscOSM more robust in case this happens.)

Not sure why this happened: a version of the file supplied to us converted by
the online gpsbabel web site was identical for all the other 4213 lines in
the file, but has a sensible number for the latitude for this point.

So, almost perfect!

--
Matthew Phillips
Durham

_______________________________________________
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

Frontend maintainership

At the recent NetSurf developer weekend[1] we discussed many topics
one of which was our regular review of the frontends.

Except for Amiga and GTK none of the frontends have a active maintainer.

The cocoa and atari frontends are however causing a great deal of concern.

cocoa - Unless a maintainer can be found (or at least someone willing
to fix it) before 11th Febuarary 2017 the CI for this target
will be disabled. The code will be removed during the next
developer weekend on the 10th June.

This decision has been made because the effort to keep this
frontend building is large and we have many reports that the
resulting binary simply crashes when started.

atari - The atari frontend is built for m68k and coldfire variants
using a variant of the netsurf cross compliation
toolchain/sdk. No serious updates have been made to this
toolchain in some time and it has become a burden.

Unless this is addressed before the next developer weekend the
frontend will be disabled in the CI and subsequently code
removed.

riscos - Still lacks a full time maintainer but due to its userbase
the team keeps it working. Gets a reprieve again and will be
reconsidered next time.

windows - Lacks a full maintainer but has been fixed up to be at least
useful. A maintainer for this frontend would be welcome.

amiga - Chris Young continues to provide excellent maintainership no
problems noted.

monkey - test frontend is useful and we envisage expanding the scope
of its usage.

beos - The Beos port is generally only tested on Haiku at this
point. The frontend is kept useful by mmu man and
pulkomandy. Main issues revolve around the CI slave and its
crashy java port.

gtk - Vince looks after this and despite gtk+ changing API a lot it
remains useful.

framebuffer - generally good shape but the Linux framebuffer and input
need attention. It has been agreed we will look into
using libinput to improve this area.

[1] http://wiki.netsurf-browser.org/developer-weekend/feb-2017/

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

Sunday, 5 February 2017

w3 schools

I just had a quick look at w3 schools and noticed that the
left-hand code pane is rendered too small.

The right-hand pane isn't shown at all, it's an iframecontainer.

http://www.w3schools.com/jsref/tryit.asp?filename=try_dom_event_target

This is in the Atari build 3978.

Is it the same for other builds ?

Peter

Saturday, 4 February 2017

Re: [gccsdk] abi-1/0 and abi-2/0

On 04/02/17 11:55, Gavin Wraith wrote:
> In $.!Boot.Resources.!SharedLibs.lib I have directories
> abi-1/0 and abi-2/0. Am I right in suspecting that the
> latter replaces the former and that only applications compiled
> before a certain date will be need what is in abi-1/0?
>
> I have not dared to try renaming abi-1/0 to see what fails.
> If nothing does, can I safely delete it?

abi-1/0 is for libraries compiled with GCC 4.1.2. When we changed
to a newer version of GCC (then 4.6, now 4.7), I came up with a
better PIC layout that was incompatible with the previous version.
So GCC 4.7 uses abi-2/0. If you don't use GCC 4.1.2 or any programs
compiled with it, then you don't need abi-1/0.

I think it best to think of GCC 4.1.2 as obsolete.

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] abi-1/0 and abi-2/0

In $.!Boot.Resources.!SharedLibs.lib I have directories
abi-1/0 and abi-2/0. Am I right in suspecting that the
latter replaces the former and that only applications compiled
before a certain date will be need what is in abi-1/0?

I have not dared to try renaming abi-1/0 to see what fails.
If nothing does, can I safely delete it?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.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

Friday, 3 February 2017

Re: [gccsdk] GCC for RISC OS 4.7.4 release 3

On Fri, Feb 03, 2017 at 08:54:38AM +0000, alan buckley wrote:
> This time the create-gcckit packages have been built OK, the riscpkg
> packages haven't.
>
> It may be that ./create-gcckit -pkg corrupts the directories so the packages
> can't be built.
>
> I hope you don't mind, I've rearranged the order of the calls of
> ./create-gcckit and ./create-riscpkg in Jenkins and started build #127 to
> see if this fixes it.

No problem, that's what it's for. I'm happy to give access to anyone else
who wants to push or tweak builds too.

(slightly annoyingly it's decided to run on 'bivalve', which is a slow Atom,
while ab-slave-1 is a fast Xeon - evidently the load balancing needs
tweaking)

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] GCCSDK buglist inaccessible

On 03/02/17 09:23, Duncan Moore wrote:
> I'm unable to access the GCCSDK buglist page
> http://www.riscos.info/bugzilla/ .
>
> This is what I get:
>
> Not Found
> The requested URL /bugzilla/ was not found on this server.
> Apache/2.2.16 (Debian) Server at www.riscos.info Port 80
>
> Has it been moved?

Theo had to disable it temporarily due to spam.

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