Are there any standard header files supplied as part of the GCCSDK for
defining SWI names in Asasm? I've had a grep around the GCCSDK folders, but
can't see anything obvious.
They're not too hard to make, but if something already exists there's little
point duplicating effort.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
_______________________________________________
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, 26 September 2020
Friday, 25 September 2020
Re: [Rpcemu] Installing to Linux
In article
<CANc9Z=wueKQ8XJ95mGVQkq-gzdLAWpQ9ZN+N8Le=R4r67mf3rQ@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, 10 May 2020 at 21:40, Andrew Hodgkinson
> <ahodgkin@riscosopen.org> wrote:
> > On 11 May 2020, at 2:25, John McCartney wrote:
> >
> > [...] interpreter or the dynamic recompiler [...]
> > What's the difference and on what basis should I base
> > my decision?
> >
> > The interpreter is slow but accurate, treating each ARM
> > instruction sequence it encounters as if it were the
> > for first time and translating them over and over. The
> > recompiler tries to remember previously converted
> > sequences, which increases speed a great deal but
> > because of the complexities of CPUs and the
> > recompilation process, this can reduce emulation
> > accuracy and cause problems with some pieces of
> > software.
> >
> > I recommend you build both. Use the recompiler version
> > normally, but if you encounter crashes you wouldn't
> > expect from a normal RISC OS machine, switch to the
> > interpreter version.
I'm sorry I didn't reply to this at the time, Andrew, but
thanks for the explanation. Also, in reply to my post on 28
May, you suggested that rpcemu-recompiler might not have
been set as an executable; in fact it had been.
> A bit more info here; I'll try to remember to update the
> compile pages to link to what the different builds are.
> The most important thing is to report as bugs things that
> don't work in the recompiler but do in the interpreter,
> it's not that the recompiler *can't* be as accurate, it's
> just that it isn't. Unreported bugs are much less likely
> to get fixed.
Another apology for my lack of a reply. I'm aware that bugs
can't be fixed unless they're reported and I'll certainly
do so if and when I find any. However, I'm hardly a power
user and so might not come across (m)any bugs at all.
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CANc9Z=wueKQ8XJ95mGVQkq-gzdLAWpQ9ZN+N8Le=R4r67mf3rQ@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, 10 May 2020 at 21:40, Andrew Hodgkinson
> <ahodgkin@riscosopen.org> wrote:
> > On 11 May 2020, at 2:25, John McCartney wrote:
> >
> > [...] interpreter or the dynamic recompiler [...]
> > What's the difference and on what basis should I base
> > my decision?
> >
> > The interpreter is slow but accurate, treating each ARM
> > instruction sequence it encounters as if it were the
> > for first time and translating them over and over. The
> > recompiler tries to remember previously converted
> > sequences, which increases speed a great deal but
> > because of the complexities of CPUs and the
> > recompilation process, this can reduce emulation
> > accuracy and cause problems with some pieces of
> > software.
> >
> > I recommend you build both. Use the recompiler version
> > normally, but if you encounter crashes you wouldn't
> > expect from a normal RISC OS machine, switch to the
> > interpreter version.
I'm sorry I didn't reply to this at the time, Andrew, but
thanks for the explanation. Also, in reply to my post on 28
May, you suggested that rpcemu-recompiler might not have
been set as an executable; in fact it had been.
> A bit more info here; I'll try to remember to update the
> compile pages to link to what the different builds are.
> The most important thing is to report as bugs things that
> don't work in the recompiler but do in the interpreter,
> it's not that the recompiler *can't* be as accurate, it's
> just that it isn't. Unreported bugs are much less likely
> to get fixed.
Another apology for my lack of a reply. I'm aware that bugs
can't be fixed unless they're reported and I'll certainly
do so if and when I find any. However, I'm hardly a power
user and so might not come across (m)any bugs at all.
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Installing to Linux (John McCartney)
This post and one in another thread are both triggered by
my intention to install RPCEmu on a laptop. Originally, I
installed it on my desktop Linux PC which gave rise to my
queries in this thread.
In article <5878ae9aedj.mccartney@blueyonder.co.uk>,
I <j.mccartney@blueyonder.co.uk> wrote:
> Just a quickie to acknowledge all those who've offered
> advice on this thread. I'm going to have to park it for a
> few days because I have other calls on my limited time at
> the moment.
Well, it's only a few days since May. Or have I missed
something?
Originally, to run RPCEmu, I had used the following lines
in the terminal:
cd rpcemu-0.9.3
./rpcemu-recompiler
After my request for help (and being timid and not having
dealt with scripts before) I put them into a text file and
copied and pasted them into the terminal and hit enter.
As my sophistication grew(!!!) I added a return to the text
so that I didn't have to hit enter.
It all worked but I got fed up with c&p so I today I looked
again at the suggestions I was given.
Brian's method worked when the script was in the
rpcemu-0.9.3 directory but creating a link and putting it
on the desktop failed. No doubt my limited knowledge of
Linux has let me down here.
Jim's and Peter's suggestions were very similar though I
don't know what the significance is between their two first
lines: Jim's ends in /sh and Peter's in /bash -
again, my lack of knowledge is letting me down.
I've ended up using the following:
#!/bin/bash
cd /home/john/rpcemu-0.9.3
./rpcemu-recompiler
This works but, having changed the file permissions to make
it executable, I have to select Run from the resulting four
options after double-clicking on the file on the desktop.
Is it possible to make it RPCEmu run from just a double
click on the file?
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
my intention to install RPCEmu on a laptop. Originally, I
installed it on my desktop Linux PC which gave rise to my
queries in this thread.
In article <5878ae9aedj.mccartney@blueyonder.co.uk>,
I <j.mccartney@blueyonder.co.uk> wrote:
> Just a quickie to acknowledge all those who've offered
> advice on this thread. I'm going to have to park it for a
> few days because I have other calls on my limited time at
> the moment.
Well, it's only a few days since May. Or have I missed
something?
Originally, to run RPCEmu, I had used the following lines
in the terminal:
cd rpcemu-0.9.3
./rpcemu-recompiler
After my request for help (and being timid and not having
dealt with scripts before) I put them into a text file and
copied and pasted them into the terminal and hit enter.
As my sophistication grew(!!!) I added a return to the text
so that I didn't have to hit enter.
It all worked but I got fed up with c&p so I today I looked
again at the suggestions I was given.
Brian's method worked when the script was in the
rpcemu-0.9.3 directory but creating a link and putting it
on the desktop failed. No doubt my limited knowledge of
Linux has let me down here.
Jim's and Peter's suggestions were very similar though I
don't know what the significance is between their two first
lines: Jim's ends in /sh and Peter's in /bash -
again, my lack of knowledge is letting me down.
I've ended up using the following:
#!/bin/bash
cd /home/john/rpcemu-0.9.3
./rpcemu-recompiler
This works but, having changed the file permissions to make
it executable, I have to select Run from the resulting four
options after double-clicking on the file on the desktop.
Is it possible to make it RPCEmu run from just a double
click on the file?
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 22 September 2020
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 2020-09-22 at 19:02 +0100, Peter Howkins wrote:
> On Tue, 22 Sep 2020 at 18:08, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> > > On Tue, 22 Sep 2020 at 16:17, Steven Newbury <
> > steve@snewbury.org.uk>
> > > wrote:
> > > > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > > > I thought I'd add RPCEmu to my Gentoo overlay, but given it
> > only
> > > > > supports a hard-coded data path it doesn't lend itself to
> > > > packaging
> > > > > for
> > > > > system-wide installation on *NIX. So I've added support for
> > > > multiple
> > > > > search directories and XDG-BaseDir through libxdg-basedir.
> > > > >
> > > > Just noticed I didn't finish removing the fixed stack allocated
> > > > filename buffers. Probably not the only issues. Please let me
> > > > know if
> > > > there's anything else to fix.
> > >
> > > Hello Steven, I'm afraid there are fundamental issues with this
> > that
> > > means I'm not interested in merging this approach, or any derived
> > > from it at this point.
> > >
> > Anything specific?
>
> If I'm reading it right
>
> 1) You can no longer run more than one copy of RPCEmu using different
> settings
You can use XDG_DATA_HOME to override the datadir, use multiple copies
with a different path. See:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
> 2) You're using XDG data directories that include system paths for
> things. This breaks horribly on multi-user systems, users shouldn't
> be sharing logs, config files, ide discs, hostfs, cmos files. About
> the only thing that could theoretically be shared is the ROM, as it's
> read-only, but as it's only one thing I can live with that also being
> a per-user-per-configuration thing.
That's exactly what XDG-Basedir is for. You can have system-wide
default config, roms etc, but any user settings override them, and
settings/resources are always saved to the local store. See spec
above.
> 3) You broke windows and macos (but that's a relatively small fix up)
Yes, I realised that, but it isn't easy for me to test, especially
macos. Multiple search paths should work there too I would have
thought.
> 4) By allowing the related config and files for a machine to be
> stored in separate directories on a system you lose the ability to
> keep them grouped for future multi-machine aware rpcemu (admittedly
> you wouldn't have been aware of that).
If I understand, you mean a group of directories for rom/disk/cmos etc
for a RiscPC vs A7000 in separate directorys one level up? Or
something else?
..
As an aside, I have to say RPCEmu is pretty awesome. It makes me want
to dig out my old hard disk from my StrongARM RiscPC, could even
resurrect some of my old RISC OS projects if I can find it and it still
works...
I actually had a support request for a free software application I
released back then a few years ago but couldn't help since my RiscPC
was broken!
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Tue, 22 Sep 2020 at 18:08, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> > > On Tue, 22 Sep 2020 at 16:17, Steven Newbury <
> > steve@snewbury.org.uk>
> > > wrote:
> > > > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > > > I thought I'd add RPCEmu to my Gentoo overlay, but given it
> > only
> > > > > supports a hard-coded data path it doesn't lend itself to
> > > > packaging
> > > > > for
> > > > > system-wide installation on *NIX. So I've added support for
> > > > multiple
> > > > > search directories and XDG-BaseDir through libxdg-basedir.
> > > > >
> > > > Just noticed I didn't finish removing the fixed stack allocated
> > > > filename buffers. Probably not the only issues. Please let me
> > > > know if
> > > > there's anything else to fix.
> > >
> > > Hello Steven, I'm afraid there are fundamental issues with this
> > that
> > > means I'm not interested in merging this approach, or any derived
> > > from it at this point.
> > >
> > Anything specific?
>
> If I'm reading it right
>
> 1) You can no longer run more than one copy of RPCEmu using different
> settings
You can use XDG_DATA_HOME to override the datadir, use multiple copies
with a different path. See:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
> 2) You're using XDG data directories that include system paths for
> things. This breaks horribly on multi-user systems, users shouldn't
> be sharing logs, config files, ide discs, hostfs, cmos files. About
> the only thing that could theoretically be shared is the ROM, as it's
> read-only, but as it's only one thing I can live with that also being
> a per-user-per-configuration thing.
That's exactly what XDG-Basedir is for. You can have system-wide
default config, roms etc, but any user settings override them, and
settings/resources are always saved to the local store. See spec
above.
> 3) You broke windows and macos (but that's a relatively small fix up)
Yes, I realised that, but it isn't easy for me to test, especially
macos. Multiple search paths should work there too I would have
thought.
> 4) By allowing the related config and files for a machine to be
> stored in separate directories on a system you lose the ability to
> keep them grouped for future multi-machine aware rpcemu (admittedly
> you wouldn't have been aware of that).
If I understand, you mean a group of directories for rom/disk/cmos etc
for a RiscPC vs A7000 in separate directorys one level up? Or
something else?
..
As an aside, I have to say RPCEmu is pretty awesome. It makes me want
to dig out my old hard disk from my StrongARM RiscPC, could even
resurrect some of my old RISC OS projects if I can find it and it still
works...
I actually had a support request for a free software application I
released back then a few years ago but couldn't help since my RiscPC
was broken!
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 22 Sep 2020 at 18:08, Steven Newbury <steve@snewbury.org.uk> wrote:
On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > supports a hard-coded data path it doesn't lend itself to
> > packaging
> > > for
> > > system-wide installation on *NIX. So I've added support for
> > multiple
> > > search directories and XDG-BaseDir through libxdg-basedir.
> > >
> > Just noticed I didn't finish removing the fixed stack allocated
> > filename buffers. Probably not the only issues. Please let me
> > know if
> > there's anything else to fix.
>
> Hello Steven, I'm afraid there are fundamental issues with this that
> means I'm not interested in merging this approach, or any derived
> from it at this point.
>
Anything specific?
If I'm reading it right
1) You can no longer run more than one copy of RPCEmu using different settings
2) You're using XDG data directories that include system paths for things. This breaks horribly on multi-user systems, users shouldn't be sharing logs, config files, ide discs, hostfs, cmos files. About the only thing that could theoretically be shared is the ROM, as it's read-only, but as it's only one thing I can live with that also being a per-user-per-configuration thing.
3) You broke windows and macos (but that's a relatively small fix up)
4) By allowing the related config and files for a machine to be stored in separate directories on a system you lose the ability to keep them grouped for future multi-machine aware rpcemu (admittedly you wouldn't have been aware of that).
Peter
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > supports a hard-coded data path it doesn't lend itself to
> > packaging
> > > for
> > > system-wide installation on *NIX. So I've added support for
> > multiple
> > > search directories and XDG-BaseDir through libxdg-basedir.
> > >
> > Just noticed I didn't finish removing the fixed stack allocated
> > filename buffers. Probably not the only issues. Please let me
> > know if
> > there's anything else to fix.
>
> Hello Steven, I'm afraid there are fundamental issues with this that
> means I'm not interested in merging this approach, or any derived
> from it at this point.
>
Anything specific? Using XDG-BaseDir is the Standard approach to
solving this on Linux. I deliberately kept that code in rpc-machdep-
xdg.c, and just expanded the the file handling in the generic code to
accomodate multiple paths, while making sure it still worked as before
if only "./" exists. There is support also in qt5, but that would mean
using qt outside of the GUI support code, which would mean C++.
> There are many issues that need to be resolved for systemwide install
> on multiple platforms and your method actually adds more problems
> than it solves.
It works for me. What are the systemwide install issues? I'm happy to
look at them since I'm quite familiar with the code now after hacking
on this for a couple of days.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > supports a hard-coded data path it doesn't lend itself to
> > packaging
> > > for
> > > system-wide installation on *NIX. So I've added support for
> > multiple
> > > search directories and XDG-BaseDir through libxdg-basedir.
> > >
> > Just noticed I didn't finish removing the fixed stack allocated
> > filename buffers. Probably not the only issues. Please let me
> > know if
> > there's anything else to fix.
>
> Hello Steven, I'm afraid there are fundamental issues with this that
> means I'm not interested in merging this approach, or any derived
> from it at this point.
>
Anything specific? Using XDG-BaseDir is the Standard approach to
solving this on Linux. I deliberately kept that code in rpc-machdep-
xdg.c, and just expanded the the file handling in the generic code to
accomodate multiple paths, while making sure it still worked as before
if only "./" exists. There is support also in qt5, but that would mean
using qt outside of the GUI support code, which would mean C++.
> There are many issues that need to be resolved for systemwide install
> on multiple platforms and your method actually adds more problems
> than it solves.
It works for me. What are the systemwide install issues? I'm happy to
look at them since I'm quite familiar with the code now after hacking
on this for a couple of days.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk> wrote:
On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> supports a hard-coded data path it doesn't lend itself to packaging
> for
> system-wide installation on *NIX. So I've added support for multiple
> search directories and XDG-BaseDir through libxdg-basedir.
>
Just noticed I didn't finish removing the fixed stack allocated
filename buffers. Probably not the only issues. Please let me know if
there's anything else to fix.
Hello Steven, I'm afraid there are fundamental issues with this that means I'm not interested in merging this approach, or any derived from it at this point.
There are many issues that need to be resolved for systemwide install on multiple platforms and your method actually adds more problems than it solves.
Peter
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> supports a hard-coded data path it doesn't lend itself to packaging
> for
> system-wide installation on *NIX. So I've added support for multiple
> search directories and XDG-BaseDir through libxdg-basedir.
>
Just noticed I didn't finish removing the fixed stack allocated
filename buffers. Probably not the only issues. Please let me know if
there's anything else to fix.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> supports a hard-coded data path it doesn't lend itself to packaging
> for
> system-wide installation on *NIX. So I've added support for multiple
> search directories and XDG-BaseDir through libxdg-basedir.
>
Just noticed I didn't finish removing the fixed stack allocated
filename buffers. Probably not the only issues. Please let me know if
there's anything else to fix.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
diff -r 00a162d7e6cd src/cmos.c
--- a/src/cmos.c Wed May 06 20:17:33 2020 +0100
+++ b/src/cmos.c Tue Sep 22 15:32:33 2020 +0100
@@ -173,19 +173,29 @@
{
char fn[512];
FILE *cmosf;
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
- /* Append "cmos.ram" to the given executable path */
- snprintf(fn, sizeof(fn), "%scmos.ram", rpcemu_get_datadir());
- cmosf = fopen(fn, "rb");
+ /* For each datadir, append "cmos.ram" to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ snprintf(fn, sizeof(fn), "%scmos.ram", *dirptr);
+ cmosf = fopen(fn, "rb");
- if (cmosf) {
- /* File open suceeded, load CMOS data */
- if (fread(cmosram, 1, 256, cmosf) != 256) {
- fatal("Unable to read from CMOS file '%s', %s", fn,
- strerror(errno));
- }
- fclose(cmosf);
- } else {
+ if (cmosf) {
+ /* File open suceeded, load CMOS data */
+ if (fread(cmosram, 1, 256, cmosf) != 256) {
+ fatal("Unable to read from CMOS file '%s', %s", fn,
+ strerror(errno));
+ }
+ fclose(cmosf);
+ break;
+ }
+ }
+
+ if (!cmosf) {
/* Report failure and initialise the array */
fprintf(stderr, "Could not open CMOS file '%s': %s\n", fn,
strerror(errno));
@@ -219,19 +229,25 @@
savecmos(void)
{
char fn[512];
- FILE *cmosf;
+ FILE *cmosf = NULL;
+ char **datadirs;
- snprintf(fn, sizeof(fn), "%scmos.ram", rpcemu_get_datadir());
- cmosf = fopen(fn, "wb");
+ /* Get first entry which should resolve tothe user home config dir */
+ datadirs = rpcemu_get_datadir();
+
+ /* For each datadir, append "cmos.ram" to the path */
+ snprintf(fn, sizeof(fn), "%scmos.ram", datadirs[0]);
+
+ cmosf = fopen(fn, "wb");
if (cmosf) {
if(fwrite(cmosram, 256, 1, cmosf) != 1) {
- fatal("Unable to write CMOS file '%s': %s", fn,
- strerror(errno));
- // TODO does it have to be fatal?
+ fatal("Unable to write CMOS file '%s': %s", fn,
+ strerror(errno));
+ // TODO does it have to be fatal?
}
fclose(cmosf);
- } else {
+ } else {
fprintf(stderr, "Could not open CMOS file '%s' for writing: %s\n", fn,
strerror(errno));
}
diff -r 00a162d7e6cd src/hostfs.c
--- a/src/hostfs.c Wed May 06 20:17:33 2020 +0100
+++ b/src/hostfs.c Tue Sep 22 15:32:33 2020 +0100
@@ -2092,8 +2092,21 @@
hostfs_init(void)
{
int c;
+ char **datadirs;
+ char **dirptr;
+ struct stat sb;
- snprintf(HOSTFS_ROOT, sizeof(HOSTFS_ROOT), "%shostfs", rpcemu_get_datadir());
+ datadirs = rpcemu_get_datadir();
+
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ snprintf(HOSTFS_ROOT, 512 * sizeof(char), "%shostfs", *dirptr);
+ if (stat(HOSTFS_ROOT, &sb)) {
+ if (errno == ENOENT)
+ continue;
+ } else if S_ISDIR(sb.st_mode)
+ break;
+ }
for (c = 0; c < 511; c++) {
if (HOSTFS_ROOT[c] == '\\') {
HOSTFS_ROOT[c] = '/';
diff -r 00a162d7e6cd src/ide.c
--- a/src/ide.c Wed May 06 20:17:33 2020 +0100
+++ b/src/ide.c Tue Sep 22 15:32:33 2020 +0100
@@ -31,6 +31,7 @@
#include <string.h>
#include <sys/types.h>
+#include <sys/stat.h>
#include "rpcemu.h"
#include "vidc20.h"
@@ -312,29 +313,47 @@
loadhd(int d, const char *filename)
{
char pathname[512];
+ char **datadirs;
+ char **dirptr;
+ struct stat sb;
+
+ datadirs = rpcemu_get_datadir();
- snprintf(pathname, sizeof(pathname), "%s%s", rpcemu_get_datadir(), filename);
-
- if (ide.hdfile[d] == NULL) {
+ /* For each datadir, append filename to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ snprintf(pathname, sizeof(pathname), "%s%s", *dirptr, filename);
/* Try to open existing hard disk image */
ide.hdfile[d] = fopen64(pathname, "rb+");
if (ide.hdfile[d] == NULL) {
- /* Failed to open existing hard disk image */
- if (errno == ENOENT) {
- /* Failed because it does not exist,
- so try to create new file */
- ide.hdfile[d] = fopen64(pathname, "wb+");
- if (ide.hdfile[d] == NULL) {
- fatal("Cannot create file '%s': %s",
- pathname, strerror(errno));
- }
- } else {
+ if (errno == ENOENT) {
+ /* Failed: no file, try next path */
+ continue;
+ } else {
/* Failed for another reason */
fatal("Cannot open file '%s': %s",
pathname, strerror(errno));
}
+ }
+ break;
+ }
+
+ if (ide.hdfile[d] == NULL) {
+ snprintf(pathname, sizeof(pathname), "%s%s", datadirs[0], filename);
+ /*
+ Already failed to open existing hard disk image, so skip
+ any existing files
+ */
+ if (stat(pathname, &sb)) {
+ if (errno == ENOENT) {
+ /* Does not exist, so try to create new file */
+ ide.hdfile[d] = fopen64(pathname, "wb+");
+ if (ide.hdfile[d] == NULL)
+ fatal("Cannot create file '%s': %s",
+ pathname, strerror(errno));
+ }
}
- }
+ }
fseek(ide.hdfile[d], 0xfc1, SEEK_SET);
ide.spt[d] = getc(ide.hdfile[d]);
diff -r 00a162d7e6cd src/podulerom.c
--- a/src/podulerom.c Wed May 06 20:17:33 2020 +0100
+++ b/src/podulerom.c Tue Sep 22 15:32:33 2020 +0100
@@ -34,7 +34,7 @@
#include "podulerom.h"
#define MAXROMS 16
-static char romfns[MAXROMS + 1][256];
+static char romfns[MAXROMS + 1][2048];
static uint8_t *podulerom = NULL;
static uint32_t poduleromsize = 0;
@@ -109,39 +109,52 @@
{
int file = 0;
int i;
- char romdirectory[512];
- DIR *dir;
const struct dirent *d;
-
- /* Build podulerom directory path */
- snprintf(romdirectory, sizeof(romdirectory), "%spoduleroms/", rpcemu_get_datadir());
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
if (podulerom != NULL) {
free(podulerom);
}
poduleromsize = 0;
- /* Scan directory for podule files */
- dir = opendir(romdirectory);
- if (dir != NULL) {
- while ((d = readdir(dir)) != NULL && file < MAXROMS) {
- const char *ext = rpcemu_file_get_extension(d->d_name);
- char filepath[512];
- struct stat buf;
+ /* For each datadir, append filename to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ size_t buflen = (strlen(*dirptr) + 12) * sizeof(char);
+ char *romdirectory = malloc(buflen);
+
+ /* Build podulerom directory path */
+ snprintf(romdirectory, buflen, "%spoduleroms/", *dirptr);
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, d->d_name);
+ /* Scan directory for podule files */
+ DIR *dir = opendir(romdirectory);
+ if (dir != NULL) {
+ while ((d = readdir(dir)) != NULL && file < MAXROMS) {
+ const char *ext = rpcemu_file_get_extension(d->d_name);
+ buflen = (strlen(romdirectory) + strlen(d->d_name) +1) * sizeof(char);
+ char *filepath = malloc(buflen);
+ struct stat buf;
- if (stat(filepath, &buf) == 0) {
- /* Skip directories or files with a .txt extension or starting with '.' */
- if (S_ISREG(buf.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
- strcpy(romfns[file++], d->d_name);
+ snprintf(filepath, buflen, "%s%s", romdirectory, d->d_name);
+
+ if (stat(filepath, &buf) == 0) {
+ /* Skip directories or files with a .txt extension or starting with '.' */
+ if (S_ISREG(buf.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
+ strcpy(romfns[file++], filepath);
+ }
}
+ free(filepath);
}
+ closedir(dir);
}
- closedir(dir);
- } else {
- rpclog("Could not open podulerom directory '%s': %s\n",
- romdirectory, strerror(errno));
+ free(romdirectory);
+ }
+
+ if (file == 0) {
+ rpclog("Could not find any poduleroms in search paths\n");
}
/* Build podulerom header */
@@ -170,12 +183,9 @@
/* Add each file into the podule's rom */
for (i = 0; i < file; i++) {
FILE *f;
- char filepath[512];
long len;
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, romfns[i]);
-
- f = fopen(filepath, "rb");
+ f = fopen(romfns[i], "rb");
if (f == NULL) {
fatal("initpodulerom: Can't open podulerom file '%s': '%s'", romfns[i], strerror(errno));
}
diff -r 00a162d7e6cd src/qt5/rpcemu.pro
--- a/src/qt5/rpcemu.pro Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpcemu.pro Tue Sep 22 15:32:33 2020 +0100
@@ -50,7 +50,7 @@
../podules.c \
../podulerom.c \
../icside.c \
- ../rpc-machdep.c \
+ ../rpc-machdep-xdg.c \
../arm_common.c \
../i8042.c \
settings.cpp \
@@ -189,4 +189,4 @@
TARGET = $$join(TARGET, , , -debug)
}
-LIBS +=
+LIBS += -lxdg-basedir
diff -r 00a162d7e6cd src/qt5/settings.cpp
--- a/src/qt5/settings.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/settings.cpp Tue Sep 22 15:32:33 2020 +0100
@@ -33,15 +33,12 @@
void
config_load(Config * config)
{
- char filename[512];
const char *p;
Model model;
int i;
QString sText;
QByteArray ba;
- snprintf(filename, sizeof(filename), "%srpc.cfg", rpcemu_get_datadir());
-
QSettings settings("rpc.cfg", QSettings::IniFormat);
/* Copy the contents of the configfile to the log */
@@ -194,11 +191,8 @@
void
config_save(Config *config)
{
- char filename[512];
QString sText;
- snprintf(filename, sizeof(filename), "%srpc.cfg", rpcemu_get_datadir());
-
QSettings settings("rpc.cfg", QSettings::IniFormat);
char s[256];
diff -r 00a162d7e6cd src/romload.c
--- a/src/romload.c Wed May 06 20:17:33 2020 +0100
+++ b/src/romload.c Tue Sep 22 15:32:33 2020 +0100
@@ -121,45 +121,53 @@
int pos = 0;
const char *dirname = "roms";
char *romfilenames[MAXROMS];
- char romdirectory[512];
- DIR *dir;
const struct dirent *d;
-
- /* Build rom directory path */
- snprintf(romdirectory, sizeof(romdirectory), "%s%s/", rpcemu_get_datadir(), dirname);
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
- /* Scan directory for ROM files */
- dir = opendir(romdirectory);
- if (dir != NULL) {
- while ((d = readdir(dir)) != NULL && number_of_files < MAXROMS) {
- const char *ext = rpcemu_file_get_extension(d->d_name);
- char filepath[512];
- struct stat buf;
+ /* For each datadir, append "cmos.ram" to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ size_t buflen = (strlen(*dirptr) + strlen(dirname) + 2) * sizeof(char);
+ char *romdirectory = malloc(buflen);
+ /* Build rom directory path */
+ snprintf(romdirectory, buflen, "%s%s/", *dirptr, dirname);
+ /* Scan directory for ROM files */
+ DIR *dir = opendir(romdirectory);
+ if (dir != NULL) {
+ while ((d = readdir(dir)) != NULL && number_of_files < MAXROMS) {
+ const char *ext = rpcemu_file_get_extension(d->d_name);
+ char *filepath;
+ struct stat sb;
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, d->d_name);
-
- if (stat(filepath, &buf) == 0) {
- /* Skip directories or files with a .txt extension or starting with '.' */
- if (S_ISREG(buf.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
- romfilenames[number_of_files] = strdup(d->d_name);
- if (romfilenames[number_of_files] == NULL) {
- fatal("Out of memory in loadroms()");
+ buflen = (strlen(romdirectory) + strlen(d->d_name) + 1) * sizeof(char);
+ filepath = malloc(buflen);
+ snprintf(filepath, buflen, "%s%s", romdirectory, d->d_name);
+ if (stat(filepath, &sb) == 0) {
+ /* Skip directories or files with a .txt extension or starting with '.' */
+ if (S_ISREG(sb.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
+ romfilenames[number_of_files] = strdup(filepath);
+ if (romfilenames[number_of_files] == NULL) {
+ free(filepath);
+ free(romdirectory);
+ fatal("Out of memory in loadroms()");
+ }
+ number_of_files++;
}
- number_of_files++;
}
+ free(filepath);
}
+ closedir(dir);
}
- closedir(dir);
- } else {
- fatal("Could not open ROM files directory '%s': %s\n",
- romdirectory, strerror(errno));
+ free(romdirectory);
}
/* Empty directory? or only .txt files? */
if (number_of_files == 0) {
- fatal("Could not load ROM files from directory '%s'\n\n"
- ROM_WEB_SITE_STRING "\n",
- dirname);
+ fatal("Could not load ROM files from directory\n\n"
+ ROM_WEB_SITE_STRING "\n");
}
/* Sort filenames into alphabetical order */
@@ -169,13 +177,10 @@
for (c = 0; c < number_of_files; c++) {
FILE *f;
long len;
- char filepath[512];
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, romfilenames[c]);
-
- f = fopen(filepath, "rb");
+ f = fopen(romfilenames[c], "rb");
if (f == NULL) {
- fatal("Can't open ROM file '%s': %s", filepath,
+ fatal("Can't open ROM file '%s': %s", romfilenames[c],
strerror(errno));
}
diff -r 00a162d7e6cd src/rpc-machdep.c
--- a/src/rpc-machdep.c Wed May 06 20:17:33 2020 +0100
+++ b/src/rpc-machdep.c Tue Sep 22 15:32:33 2020 +0100
@@ -19,6 +19,7 @@
*/
#include <string.h>
+#include <unistd.h>
#include "rpcemu.h"
@@ -26,22 +27,38 @@
be, but currently this version is used by Linux, all the other autoconf
based builds and Windows. Only Mac OS X GUI version needs to override */
-static char datadir[512] = "./";
static char logpath[1024] = "";
+char **datadir = NULL;
/**
* Return the path of the data directory containing all the sub data parts
* used by the program, eg romload, hostfs etc.
*
- * @return Pointer to static zero-terminated string of path
+ * @return Pointer to array of static zero-terminated string(s) of path(s)
*/
-const char *
-rpcemu_get_datadir(void)
+char **rpcemu_get_datadir(void)
{
+ if (!datadir) {
+ datadir = malloc(2 * sizeof(char*));
+ datadir[0] = malloc(3 * sizeof(char));
+ strncpy(datadir[0], "./\0", 3 * sizeof(char));
+ datadir[1] = NULL;
+ }
return datadir;
}
/**
+ * Free filesystem data resource path array
+ */
+void rpcemu_free_datadir(void) {
+ char **dirptr;
+ if (datadir) {
+ for(dirptr = datadir; *dirptr; dirptr++) { free(*dirptr); }
+ free(datadir);
+ }
+}
+
+/**
* Return the full path to the RPCEmu log file.
*
* @return Pointer to static zero-terminated string of full path to log file
@@ -49,9 +66,20 @@
const char *
rpcemu_get_log_path(void)
{
- if (logpath[0] == '\0') {
- strcpy(logpath, rpcemu_get_datadir());
- strcat(logpath, "rpclog.txt");
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
+
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ if (access(*dirptr, W_OK) == 0) {
+ if (logpath[0] == '\0') {
+ strcpy(logpath, *dirptr);
+ strcat(logpath, "rpclog.txt");
+ }
+ break;
+ }
}
return logpath;
diff -r 00a162d7e6cd src/rpcemu.c
--- a/src/rpcemu.c Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.c Tue Sep 22 15:32:33 2020 +0100
@@ -436,6 +436,7 @@
free(rom);
savecmos();
config_save(&config);
+ rpcemu_free_datadir();
#ifdef RPCEMU_NETWORKING
network_reset();
diff -r 00a162d7e6cd src/rpcemu.h
--- a/src/rpcemu.h Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.h Tue Sep 22 15:32:33 2020 +0100
@@ -171,7 +171,8 @@
/* These functions can optionally be overridden by a platform. If not
needed to be overridden, there is a generic version in rpc-machdep.c */
-extern const char *rpcemu_get_datadir(void);
+extern char **rpcemu_get_datadir(void);
+extern void rpcemu_free_datadir(void);
extern const char *rpcemu_get_log_path(void);
/* rpc-[linux|win].c */
--- /dev/null 2020-09-20 22:59:01.110995488 +0100
+++ b/src/rpc-machdep-xdg.c 2020-09-22 15:29:39.557383311 +0100
@@ -0,0 +1,113 @@
+/*
+ RPCEmu - An Acorn system emulator
+
+ Copyright (C) 2005-2010 Sarah Walker
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <string.h>
+#include <basedir_fs.h>
+#include <unistd.h>
+#include <sys/stat.h>
+
+#include "rpcemu.h"
+
+/* These are functions that can be overridden by platforms if need
+ be, but currently this version is used by Linux, all the other autoconf
+ based builds and Windows. Only Mac OS X GUI version needs to override */
+
+static char logpath[1024] = "";
+char **datadir = NULL;
+xdgHandle xdg;
+
+/**
+ * Return the path of the data directory containing all the sub data parts
+ * used by the program, eg romload, hostfs etc.
+ *
+ * @return Pointer to array of static zero-terminated string(s) of path(s)
+ */
+char **rpcemu_get_datadir(void)
+{
+ const char * const *dirptr;
+ size_t num_paths = 0, i = 0;
+
+ if (!datadir) {
+ struct stat buf;
+ xdgInitHandle(&xdg);
+
+ /* Determine number of elements */
+ dirptr = xdgSearchableDataDirectories(&xdg);
+ while (dirptr[num_paths] != NULL) {
+ num_paths++;
+ };
+
+ /* Create array of paths including subdir */
+ datadir = malloc((num_paths + 1) * sizeof(char*));
+
+ while (i < num_paths) {
+ size_t buflen = (strlen(dirptr[i]) + 9) * sizeof(char);
+ datadir[i] = malloc(buflen);
+ snprintf(datadir[i], buflen, "%s/rpcemu/", dirptr[i]);
+ i++;
+ }
+ /* NULL terminate list */
+ datadir[i] = NULL;
+
+ if (stat(datadir[0], &buf))
+ xdgMakePath(datadir[0], S_IRWXU | S_IRWXG);
+
+ xdgWipeHandle(&xdg);
+ }
+ return datadir;
+}
+
+/**
+ * Free filesystem data resource path array
+ */
+void rpcemu_free_datadir(void) {
+ char ** dirptr;
+ if (datadir) {
+ for(dirptr = datadir; *dirptr; dirptr++) { free(*dirptr); }
+ free(datadir);
+ }
+}
+
+/**
+ * Return the full path to the RPCEmu log file.
+ *
+ * @return Pointer to static zero-terminated string of full path to log file
+ */
+const char *
+rpcemu_get_log_path(void)
+{
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
+
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ if (access(*dirptr, W_OK) == 0) {
+ if (logpath[0] == '\0') {
+ strcpy(logpath, *dirptr);
+ strcat(logpath, "rpclog.txt");
+ }
+ break;
+ }
+ }
+
+ return logpath;
+}
I thought I'd add RPCEmu to my Gentoo overlay, but given it only
supports a hard-coded data path it doesn't lend itself to packaging for
system-wide installation on *NIX. So I've added support for multiple
search directories and XDG-BaseDir through libxdg-basedir.
--- a/src/cmos.c Wed May 06 20:17:33 2020 +0100
+++ b/src/cmos.c Tue Sep 22 15:32:33 2020 +0100
@@ -173,19 +173,29 @@
{
char fn[512];
FILE *cmosf;
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
- /* Append "cmos.ram" to the given executable path */
- snprintf(fn, sizeof(fn), "%scmos.ram", rpcemu_get_datadir());
- cmosf = fopen(fn, "rb");
+ /* For each datadir, append "cmos.ram" to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ snprintf(fn, sizeof(fn), "%scmos.ram", *dirptr);
+ cmosf = fopen(fn, "rb");
- if (cmosf) {
- /* File open suceeded, load CMOS data */
- if (fread(cmosram, 1, 256, cmosf) != 256) {
- fatal("Unable to read from CMOS file '%s', %s", fn,
- strerror(errno));
- }
- fclose(cmosf);
- } else {
+ if (cmosf) {
+ /* File open suceeded, load CMOS data */
+ if (fread(cmosram, 1, 256, cmosf) != 256) {
+ fatal("Unable to read from CMOS file '%s', %s", fn,
+ strerror(errno));
+ }
+ fclose(cmosf);
+ break;
+ }
+ }
+
+ if (!cmosf) {
/* Report failure and initialise the array */
fprintf(stderr, "Could not open CMOS file '%s': %s\n", fn,
strerror(errno));
@@ -219,19 +229,25 @@
savecmos(void)
{
char fn[512];
- FILE *cmosf;
+ FILE *cmosf = NULL;
+ char **datadirs;
- snprintf(fn, sizeof(fn), "%scmos.ram", rpcemu_get_datadir());
- cmosf = fopen(fn, "wb");
+ /* Get first entry which should resolve tothe user home config dir */
+ datadirs = rpcemu_get_datadir();
+
+ /* For each datadir, append "cmos.ram" to the path */
+ snprintf(fn, sizeof(fn), "%scmos.ram", datadirs[0]);
+
+ cmosf = fopen(fn, "wb");
if (cmosf) {
if(fwrite(cmosram, 256, 1, cmosf) != 1) {
- fatal("Unable to write CMOS file '%s': %s", fn,
- strerror(errno));
- // TODO does it have to be fatal?
+ fatal("Unable to write CMOS file '%s': %s", fn,
+ strerror(errno));
+ // TODO does it have to be fatal?
}
fclose(cmosf);
- } else {
+ } else {
fprintf(stderr, "Could not open CMOS file '%s' for writing: %s\n", fn,
strerror(errno));
}
diff -r 00a162d7e6cd src/hostfs.c
--- a/src/hostfs.c Wed May 06 20:17:33 2020 +0100
+++ b/src/hostfs.c Tue Sep 22 15:32:33 2020 +0100
@@ -2092,8 +2092,21 @@
hostfs_init(void)
{
int c;
+ char **datadirs;
+ char **dirptr;
+ struct stat sb;
- snprintf(HOSTFS_ROOT, sizeof(HOSTFS_ROOT), "%shostfs", rpcemu_get_datadir());
+ datadirs = rpcemu_get_datadir();
+
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ snprintf(HOSTFS_ROOT, 512 * sizeof(char), "%shostfs", *dirptr);
+ if (stat(HOSTFS_ROOT, &sb)) {
+ if (errno == ENOENT)
+ continue;
+ } else if S_ISDIR(sb.st_mode)
+ break;
+ }
for (c = 0; c < 511; c++) {
if (HOSTFS_ROOT[c] == '\\') {
HOSTFS_ROOT[c] = '/';
diff -r 00a162d7e6cd src/ide.c
--- a/src/ide.c Wed May 06 20:17:33 2020 +0100
+++ b/src/ide.c Tue Sep 22 15:32:33 2020 +0100
@@ -31,6 +31,7 @@
#include <string.h>
#include <sys/types.h>
+#include <sys/stat.h>
#include "rpcemu.h"
#include "vidc20.h"
@@ -312,29 +313,47 @@
loadhd(int d, const char *filename)
{
char pathname[512];
+ char **datadirs;
+ char **dirptr;
+ struct stat sb;
+
+ datadirs = rpcemu_get_datadir();
- snprintf(pathname, sizeof(pathname), "%s%s", rpcemu_get_datadir(), filename);
-
- if (ide.hdfile[d] == NULL) {
+ /* For each datadir, append filename to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ snprintf(pathname, sizeof(pathname), "%s%s", *dirptr, filename);
/* Try to open existing hard disk image */
ide.hdfile[d] = fopen64(pathname, "rb+");
if (ide.hdfile[d] == NULL) {
- /* Failed to open existing hard disk image */
- if (errno == ENOENT) {
- /* Failed because it does not exist,
- so try to create new file */
- ide.hdfile[d] = fopen64(pathname, "wb+");
- if (ide.hdfile[d] == NULL) {
- fatal("Cannot create file '%s': %s",
- pathname, strerror(errno));
- }
- } else {
+ if (errno == ENOENT) {
+ /* Failed: no file, try next path */
+ continue;
+ } else {
/* Failed for another reason */
fatal("Cannot open file '%s': %s",
pathname, strerror(errno));
}
+ }
+ break;
+ }
+
+ if (ide.hdfile[d] == NULL) {
+ snprintf(pathname, sizeof(pathname), "%s%s", datadirs[0], filename);
+ /*
+ Already failed to open existing hard disk image, so skip
+ any existing files
+ */
+ if (stat(pathname, &sb)) {
+ if (errno == ENOENT) {
+ /* Does not exist, so try to create new file */
+ ide.hdfile[d] = fopen64(pathname, "wb+");
+ if (ide.hdfile[d] == NULL)
+ fatal("Cannot create file '%s': %s",
+ pathname, strerror(errno));
+ }
}
- }
+ }
fseek(ide.hdfile[d], 0xfc1, SEEK_SET);
ide.spt[d] = getc(ide.hdfile[d]);
diff -r 00a162d7e6cd src/podulerom.c
--- a/src/podulerom.c Wed May 06 20:17:33 2020 +0100
+++ b/src/podulerom.c Tue Sep 22 15:32:33 2020 +0100
@@ -34,7 +34,7 @@
#include "podulerom.h"
#define MAXROMS 16
-static char romfns[MAXROMS + 1][256];
+static char romfns[MAXROMS + 1][2048];
static uint8_t *podulerom = NULL;
static uint32_t poduleromsize = 0;
@@ -109,39 +109,52 @@
{
int file = 0;
int i;
- char romdirectory[512];
- DIR *dir;
const struct dirent *d;
-
- /* Build podulerom directory path */
- snprintf(romdirectory, sizeof(romdirectory), "%spoduleroms/", rpcemu_get_datadir());
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
if (podulerom != NULL) {
free(podulerom);
}
poduleromsize = 0;
- /* Scan directory for podule files */
- dir = opendir(romdirectory);
- if (dir != NULL) {
- while ((d = readdir(dir)) != NULL && file < MAXROMS) {
- const char *ext = rpcemu_file_get_extension(d->d_name);
- char filepath[512];
- struct stat buf;
+ /* For each datadir, append filename to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ size_t buflen = (strlen(*dirptr) + 12) * sizeof(char);
+ char *romdirectory = malloc(buflen);
+
+ /* Build podulerom directory path */
+ snprintf(romdirectory, buflen, "%spoduleroms/", *dirptr);
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, d->d_name);
+ /* Scan directory for podule files */
+ DIR *dir = opendir(romdirectory);
+ if (dir != NULL) {
+ while ((d = readdir(dir)) != NULL && file < MAXROMS) {
+ const char *ext = rpcemu_file_get_extension(d->d_name);
+ buflen = (strlen(romdirectory) + strlen(d->d_name) +1) * sizeof(char);
+ char *filepath = malloc(buflen);
+ struct stat buf;
- if (stat(filepath, &buf) == 0) {
- /* Skip directories or files with a .txt extension or starting with '.' */
- if (S_ISREG(buf.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
- strcpy(romfns[file++], d->d_name);
+ snprintf(filepath, buflen, "%s%s", romdirectory, d->d_name);
+
+ if (stat(filepath, &buf) == 0) {
+ /* Skip directories or files with a .txt extension or starting with '.' */
+ if (S_ISREG(buf.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
+ strcpy(romfns[file++], filepath);
+ }
}
+ free(filepath);
}
+ closedir(dir);
}
- closedir(dir);
- } else {
- rpclog("Could not open podulerom directory '%s': %s\n",
- romdirectory, strerror(errno));
+ free(romdirectory);
+ }
+
+ if (file == 0) {
+ rpclog("Could not find any poduleroms in search paths\n");
}
/* Build podulerom header */
@@ -170,12 +183,9 @@
/* Add each file into the podule's rom */
for (i = 0; i < file; i++) {
FILE *f;
- char filepath[512];
long len;
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, romfns[i]);
-
- f = fopen(filepath, "rb");
+ f = fopen(romfns[i], "rb");
if (f == NULL) {
fatal("initpodulerom: Can't open podulerom file '%s': '%s'", romfns[i], strerror(errno));
}
diff -r 00a162d7e6cd src/qt5/rpcemu.pro
--- a/src/qt5/rpcemu.pro Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpcemu.pro Tue Sep 22 15:32:33 2020 +0100
@@ -50,7 +50,7 @@
../podules.c \
../podulerom.c \
../icside.c \
- ../rpc-machdep.c \
+ ../rpc-machdep-xdg.c \
../arm_common.c \
../i8042.c \
settings.cpp \
@@ -189,4 +189,4 @@
TARGET = $$join(TARGET, , , -debug)
}
-LIBS +=
+LIBS += -lxdg-basedir
diff -r 00a162d7e6cd src/qt5/settings.cpp
--- a/src/qt5/settings.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/settings.cpp Tue Sep 22 15:32:33 2020 +0100
@@ -33,15 +33,12 @@
void
config_load(Config * config)
{
- char filename[512];
const char *p;
Model model;
int i;
QString sText;
QByteArray ba;
- snprintf(filename, sizeof(filename), "%srpc.cfg", rpcemu_get_datadir());
-
QSettings settings("rpc.cfg", QSettings::IniFormat);
/* Copy the contents of the configfile to the log */
@@ -194,11 +191,8 @@
void
config_save(Config *config)
{
- char filename[512];
QString sText;
- snprintf(filename, sizeof(filename), "%srpc.cfg", rpcemu_get_datadir());
-
QSettings settings("rpc.cfg", QSettings::IniFormat);
char s[256];
diff -r 00a162d7e6cd src/romload.c
--- a/src/romload.c Wed May 06 20:17:33 2020 +0100
+++ b/src/romload.c Tue Sep 22 15:32:33 2020 +0100
@@ -121,45 +121,53 @@
int pos = 0;
const char *dirname = "roms";
char *romfilenames[MAXROMS];
- char romdirectory[512];
- DIR *dir;
const struct dirent *d;
-
- /* Build rom directory path */
- snprintf(romdirectory, sizeof(romdirectory), "%s%s/", rpcemu_get_datadir(), dirname);
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
- /* Scan directory for ROM files */
- dir = opendir(romdirectory);
- if (dir != NULL) {
- while ((d = readdir(dir)) != NULL && number_of_files < MAXROMS) {
- const char *ext = rpcemu_file_get_extension(d->d_name);
- char filepath[512];
- struct stat buf;
+ /* For each datadir, append "cmos.ram" to the path */
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ size_t buflen = (strlen(*dirptr) + strlen(dirname) + 2) * sizeof(char);
+ char *romdirectory = malloc(buflen);
+ /* Build rom directory path */
+ snprintf(romdirectory, buflen, "%s%s/", *dirptr, dirname);
+ /* Scan directory for ROM files */
+ DIR *dir = opendir(romdirectory);
+ if (dir != NULL) {
+ while ((d = readdir(dir)) != NULL && number_of_files < MAXROMS) {
+ const char *ext = rpcemu_file_get_extension(d->d_name);
+ char *filepath;
+ struct stat sb;
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, d->d_name);
-
- if (stat(filepath, &buf) == 0) {
- /* Skip directories or files with a .txt extension or starting with '.' */
- if (S_ISREG(buf.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
- romfilenames[number_of_files] = strdup(d->d_name);
- if (romfilenames[number_of_files] == NULL) {
- fatal("Out of memory in loadroms()");
+ buflen = (strlen(romdirectory) + strlen(d->d_name) + 1) * sizeof(char);
+ filepath = malloc(buflen);
+ snprintf(filepath, buflen, "%s%s", romdirectory, d->d_name);
+ if (stat(filepath, &sb) == 0) {
+ /* Skip directories or files with a .txt extension or starting with '.' */
+ if (S_ISREG(sb.st_mode) && (strcasecmp(ext, "txt") != 0) && d->d_name[0] != '.') {
+ romfilenames[number_of_files] = strdup(filepath);
+ if (romfilenames[number_of_files] == NULL) {
+ free(filepath);
+ free(romdirectory);
+ fatal("Out of memory in loadroms()");
+ }
+ number_of_files++;
}
- number_of_files++;
}
+ free(filepath);
}
+ closedir(dir);
}
- closedir(dir);
- } else {
- fatal("Could not open ROM files directory '%s': %s\n",
- romdirectory, strerror(errno));
+ free(romdirectory);
}
/* Empty directory? or only .txt files? */
if (number_of_files == 0) {
- fatal("Could not load ROM files from directory '%s'\n\n"
- ROM_WEB_SITE_STRING "\n",
- dirname);
+ fatal("Could not load ROM files from directory\n\n"
+ ROM_WEB_SITE_STRING "\n");
}
/* Sort filenames into alphabetical order */
@@ -169,13 +177,10 @@
for (c = 0; c < number_of_files; c++) {
FILE *f;
long len;
- char filepath[512];
- snprintf(filepath, sizeof(filepath), "%s%s", romdirectory, romfilenames[c]);
-
- f = fopen(filepath, "rb");
+ f = fopen(romfilenames[c], "rb");
if (f == NULL) {
- fatal("Can't open ROM file '%s': %s", filepath,
+ fatal("Can't open ROM file '%s': %s", romfilenames[c],
strerror(errno));
}
diff -r 00a162d7e6cd src/rpc-machdep.c
--- a/src/rpc-machdep.c Wed May 06 20:17:33 2020 +0100
+++ b/src/rpc-machdep.c Tue Sep 22 15:32:33 2020 +0100
@@ -19,6 +19,7 @@
*/
#include <string.h>
+#include <unistd.h>
#include "rpcemu.h"
@@ -26,22 +27,38 @@
be, but currently this version is used by Linux, all the other autoconf
based builds and Windows. Only Mac OS X GUI version needs to override */
-static char datadir[512] = "./";
static char logpath[1024] = "";
+char **datadir = NULL;
/**
* Return the path of the data directory containing all the sub data parts
* used by the program, eg romload, hostfs etc.
*
- * @return Pointer to static zero-terminated string of path
+ * @return Pointer to array of static zero-terminated string(s) of path(s)
*/
-const char *
-rpcemu_get_datadir(void)
+char **rpcemu_get_datadir(void)
{
+ if (!datadir) {
+ datadir = malloc(2 * sizeof(char*));
+ datadir[0] = malloc(3 * sizeof(char));
+ strncpy(datadir[0], "./\0", 3 * sizeof(char));
+ datadir[1] = NULL;
+ }
return datadir;
}
/**
+ * Free filesystem data resource path array
+ */
+void rpcemu_free_datadir(void) {
+ char **dirptr;
+ if (datadir) {
+ for(dirptr = datadir; *dirptr; dirptr++) { free(*dirptr); }
+ free(datadir);
+ }
+}
+
+/**
* Return the full path to the RPCEmu log file.
*
* @return Pointer to static zero-terminated string of full path to log file
@@ -49,9 +66,20 @@
const char *
rpcemu_get_log_path(void)
{
- if (logpath[0] == '\0') {
- strcpy(logpath, rpcemu_get_datadir());
- strcat(logpath, "rpclog.txt");
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
+
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ if (access(*dirptr, W_OK) == 0) {
+ if (logpath[0] == '\0') {
+ strcpy(logpath, *dirptr);
+ strcat(logpath, "rpclog.txt");
+ }
+ break;
+ }
}
return logpath;
diff -r 00a162d7e6cd src/rpcemu.c
--- a/src/rpcemu.c Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.c Tue Sep 22 15:32:33 2020 +0100
@@ -436,6 +436,7 @@
free(rom);
savecmos();
config_save(&config);
+ rpcemu_free_datadir();
#ifdef RPCEMU_NETWORKING
network_reset();
diff -r 00a162d7e6cd src/rpcemu.h
--- a/src/rpcemu.h Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.h Tue Sep 22 15:32:33 2020 +0100
@@ -171,7 +171,8 @@
/* These functions can optionally be overridden by a platform. If not
needed to be overridden, there is a generic version in rpc-machdep.c */
-extern const char *rpcemu_get_datadir(void);
+extern char **rpcemu_get_datadir(void);
+extern void rpcemu_free_datadir(void);
extern const char *rpcemu_get_log_path(void);
/* rpc-[linux|win].c */
--- /dev/null 2020-09-20 22:59:01.110995488 +0100
+++ b/src/rpc-machdep-xdg.c 2020-09-22 15:29:39.557383311 +0100
@@ -0,0 +1,113 @@
+/*
+ RPCEmu - An Acorn system emulator
+
+ Copyright (C) 2005-2010 Sarah Walker
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <string.h>
+#include <basedir_fs.h>
+#include <unistd.h>
+#include <sys/stat.h>
+
+#include "rpcemu.h"
+
+/* These are functions that can be overridden by platforms if need
+ be, but currently this version is used by Linux, all the other autoconf
+ based builds and Windows. Only Mac OS X GUI version needs to override */
+
+static char logpath[1024] = "";
+char **datadir = NULL;
+xdgHandle xdg;
+
+/**
+ * Return the path of the data directory containing all the sub data parts
+ * used by the program, eg romload, hostfs etc.
+ *
+ * @return Pointer to array of static zero-terminated string(s) of path(s)
+ */
+char **rpcemu_get_datadir(void)
+{
+ const char * const *dirptr;
+ size_t num_paths = 0, i = 0;
+
+ if (!datadir) {
+ struct stat buf;
+ xdgInitHandle(&xdg);
+
+ /* Determine number of elements */
+ dirptr = xdgSearchableDataDirectories(&xdg);
+ while (dirptr[num_paths] != NULL) {
+ num_paths++;
+ };
+
+ /* Create array of paths including subdir */
+ datadir = malloc((num_paths + 1) * sizeof(char*));
+
+ while (i < num_paths) {
+ size_t buflen = (strlen(dirptr[i]) + 9) * sizeof(char);
+ datadir[i] = malloc(buflen);
+ snprintf(datadir[i], buflen, "%s/rpcemu/", dirptr[i]);
+ i++;
+ }
+ /* NULL terminate list */
+ datadir[i] = NULL;
+
+ if (stat(datadir[0], &buf))
+ xdgMakePath(datadir[0], S_IRWXU | S_IRWXG);
+
+ xdgWipeHandle(&xdg);
+ }
+ return datadir;
+}
+
+/**
+ * Free filesystem data resource path array
+ */
+void rpcemu_free_datadir(void) {
+ char ** dirptr;
+ if (datadir) {
+ for(dirptr = datadir; *dirptr; dirptr++) { free(*dirptr); }
+ free(datadir);
+ }
+}
+
+/**
+ * Return the full path to the RPCEmu log file.
+ *
+ * @return Pointer to static zero-terminated string of full path to log file
+ */
+const char *
+rpcemu_get_log_path(void)
+{
+ char **datadirs;
+ char **dirptr;
+
+ datadirs = rpcemu_get_datadir();
+
+ for (dirptr = datadirs; *dirptr; dirptr++)
+ {
+ if (access(*dirptr, W_OK) == 0) {
+ if (logpath[0] == '\0') {
+ strcpy(logpath, *dirptr);
+ strcat(logpath, "rpclog.txt");
+ }
+ break;
+ }
+ }
+
+ return logpath;
+}
I thought I'd add RPCEmu to my Gentoo overlay, but given it only
supports a hard-coded data path it doesn't lend itself to packaging for
system-wide installation on *NIX. So I've added support for multiple
search directories and XDG-BaseDir through libxdg-basedir.
Friday, 18 September 2020
Re: Help me please
On Fri, Sep 18, 2020 at 00:37:28 +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
> Hello I am trying to port netsurf to an gtk application to make it work
> across platforms (linux, windows and mac)
There is already a GTK frontend for NetSurf
> to make an "electron-like" app.
However we've not put effort (yet) into making the binding to the core more
widget-like.
> Is it possible?
In theory? Yes. In practice it will be a significant quantity of work. If
you're serious about this, then we're intending to have a developer hack
session in a few weeks 2nd-5th October which you would be welcome to join us
for. It'll be online, naturally, and if you join us in our developer channel
(#netsurf on Freenode) then we can discuss things.
Please be aware though that we're all volunteers and so we have day-jobs making
it likely that any questions will take a while to be responded to. Until the
developer weekend.
If you have further discussion on this topic, I also suggest you use the
developers mailing list rather than this users list (use
netsurf-dev@netsurf-browser.org instead)
Thanks,
Daniel.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> Hello I am trying to port netsurf to an gtk application to make it work
> across platforms (linux, windows and mac)
There is already a GTK frontend for NetSurf
> to make an "electron-like" app.
However we've not put effort (yet) into making the binding to the core more
widget-like.
> Is it possible?
In theory? Yes. In practice it will be a significant quantity of work. If
you're serious about this, then we're intending to have a developer hack
session in a few weeks 2nd-5th October which you would be welcome to join us
for. It'll be online, naturally, and if you join us in our developer channel
(#netsurf on Freenode) then we can discuss things.
Please be aware though that we're all volunteers and so we have day-jobs making
it likely that any questions will take a while to be responded to. Until the
developer weekend.
If you have further discussion on this topic, I also suggest you use the
developers mailing list rather than this users list (use
netsurf-dev@netsurf-browser.org instead)
Thanks,
Daniel.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Thursday, 17 September 2020
Help me please
Hello I am trying to port netsurf to an gtk application to make it work across platforms (linux, windows and mac) to make an "electron-like" app. Is it possible?
Wednesday, 9 September 2020
Re: [gccsdk] Build problems for crosscompiler
Now that I got the gccsdk building, I tried my next step, which is building it on my NAS. It's a QNAP TS-431P2, which is an ARM model. I tried building a docker image for it, using this docker image here: https://github.com/kuroneko/docker-riscos-gccsdk .
It seems to do the correct thing, but it also fails during build. It builds under an ubuntu image, so it should be pretty close to the build on my machine which was OK, so I think it has to do something with it being an ARM model, which causes a problem. The problem seems to be this:
gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/home/gccsdk/gcc4/srcdir/gcc/gcc -I/home/gccsdk/gcc4/srcdir/gcc/gcc/. -I/home/gccsdk/gcc4/srcdir/gcc/gcc/../include -I/home/gccsdk/gcc4/srcdir/gcc/gcc/../libcpp/include -I/home/gccsdk/gcc4/builddir/installed-libs-for-cross-gcc/include -I/home/gccsdk/gcc4/builddir/installed-libs-for-cross-gcc/include -I/home/gccsdk/gcc4/builddir/installed-libs-for-cross-gcc/include -I/home/gccsdk/gcc4/srcdir/gcc/gcc/../libdecnumber -I/home/gccsdk/gcc4/srcdir/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/gccsdk/gcc4/builddir/installed-libs-for-cross-gcc/include -I/home/gccsdk/gcc4/builddir/installed-libs-for-cross-gcc/include \
-DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/home/gccsdk/cross/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/home/gccsdk/cross/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.7.4\" -DDEFAULT_TARGET_MACHINE=\"arm-unknown-riscos\" -DSTANDARD_BINDIR_PREFIX=\"/home/gccsdk/cross/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB}" = "X" || test "yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` -DCONFIGURE_SPECS="\"\"" \
-c /home/gccsdk/gcc4/srcdir/gcc/gcc/gcc.c -o gcc.o)
In file included from ./tm.h:21:0,
from /home/gccsdk/gcc4/srcdir/gcc/gcc/gcc.c:37:
/home/gccsdk/gcc4/srcdir/gcc/gcc/config/arm/arm.h:2229:31: error: 'SUBTARGET_EXTRA_SPEC_FUNCTIONS' undeclared here (not in a function); did you mean 'SUBTARGET_EXTRA_SPECS'?
# define EXTRA_SPEC_FUNCTIONS SUBTARGET_EXTRA_SPEC_FUNCTIONS \
^
/home/gccsdk/gcc4/srcdir/gcc/gcc/gcc.c:1270:3: note: in expansion of macro 'EXTRA_SPEC_FUNCTIONS'
EXTRA_SPEC_FUNCTIONS
^~~~~~~~~~~~~~~~~~~~
/home/gccsdk/gcc4/srcdir/gcc/gcc/config/arm/arm.h:2230:3: error: expected '}' before '{' token
I found a reference to this problem at https://www.riscosopen.org/forum/forums/11/topics/9097 (search for SUBTARGET_EXTRA_SPEC_FUNCTIONS) but that again references a mail in this list saying the problem has gone away, but that doesn't seem to be the case for me.
I'll try to do the same solution as in that posting, but is there a proper solution?
Thanks
Jan-Jaap
-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas! 15GB disk space!
Commercial and Bulk Mail Options!
Tuesday, 8 September 2020
Re: [gccsdk] Build problems for crosscompiler
Quoting Chris Gransden <chrisg@care4free.net>:
In article <mpro.qg4ee9005joo01yec.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:jjvdgeer@vfemail.net, on 3 Sep, wrote:
I'm trying to build gccsdk but it fails because it doesn't find the
ppl-1.2.tar.gz package:[snip]
It tries to download it
from ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz but
that link seems to be dead. I think I did find a place to download it
at the bottom of this page:
http://www.prismmodelchecker.org/other-downloads.phpI found it at :-
https://www.bugseng.com/products/ppl/download/ftp/releases/1.2/
It should work again now. I've check in a change to download ppl fromIf one has an existing working autobuilder it can be retrieved from that. If
the package is put in gcc4/srcdir.orig then the autobuilder does not try to
fetch it.
www.bugseng.com.
Thanks a lot! I didn't see the replies before now (haven't followed on this list & this email account for a while and everything apparently went into the spam bin... Inclusive my own post, so I thought it hadn't even been posted..).
It's working now :)
Cheers,
Jan-Jaap
-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas! 15GB disk space!
Commercial and Bulk Mail Options!
Sunday, 6 September 2020
Friday, 4 September 2020
Re: [gccsdk] Build problems for crosscompiler
Chris Gransden, on 4 Sep, wrote:
> In article <mpro.qg4ee9005joo01yec.pittdj@pittdj.co.uk>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
> > jjvdgeer@vfemail.net, on 3 Sep, wrote:
>
> > > I'm trying to build gccsdk but it fails because it doesn't find the
> > > ppl-1.2.tar.gz package:
[snip]
> It should work again now. I've check in a change to download ppl from
> www.bugseng.com.
Many thanks, on a new autobuilder instance build-world has completed.
Using Ubuntu 20.04.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In article <mpro.qg4ee9005joo01yec.pittdj@pittdj.co.uk>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
> > jjvdgeer@vfemail.net, on 3 Sep, wrote:
>
> > > I'm trying to build gccsdk but it fails because it doesn't find the
> > > ppl-1.2.tar.gz package:
[snip]
> It should work again now. I've check in a change to download ppl from
> www.bugseng.com.
Many thanks, on a new autobuilder instance build-world has completed.
Using Ubuntu 20.04.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Build problems for crosscompiler
In article <mpro.qg4ee9005joo01yec.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> jjvdgeer@vfemail.net, on 3 Sep, wrote:
> > I'm trying to build gccsdk but it fails because it doesn't find the
> > ppl-1.2.tar.gz package:
> [snip]
> > It tries to download it
> > from ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz but
> > that link seems to be dead. I think I did find a place to download it
> > at the bottom of this page:
> > http://www.prismmodelchecker.org/other-downloads.php
> I found it at :-
> https://www.bugseng.com/products/ppl/download/ftp/releases/1.2/
> If one has an existing working autobuilder it can be retrieved from that. If
> the package is put in gcc4/srcdir.orig then the autobuilder does not try to
> fetch it.
It should work again now. I've check in a change to download ppl from
www.bugseng.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
David Pitt <pittdj@pittdj.co.uk> wrote:
> jjvdgeer@vfemail.net, on 3 Sep, wrote:
> > I'm trying to build gccsdk but it fails because it doesn't find the
> > ppl-1.2.tar.gz package:
> [snip]
> > It tries to download it
> > from ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz but
> > that link seems to be dead. I think I did find a place to download it
> > at the bottom of this page:
> > http://www.prismmodelchecker.org/other-downloads.php
> I found it at :-
> https://www.bugseng.com/products/ppl/download/ftp/releases/1.2/
> If one has an existing working autobuilder it can be retrieved from that. If
> the package is put in gcc4/srcdir.orig then the autobuilder does not try to
> fetch it.
It should work again now. I've check in a change to download ppl from
www.bugseng.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
Thursday, 3 September 2020
Re: [gccsdk] Build problems for crosscompiler
jjvdgeer@vfemail.net, on 3 Sep, wrote:
> I'm trying to build gccsdk but it fails because it doesn't find the
> ppl-1.2.tar.gz package:
[snip]
> It tries to download it
> from ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz but
> that link seems to be dead. I think I did find a place to download it
> at the bottom of this page:
> http://www.prismmodelchecker.org/other-downloads.php
I found it at :-
https://www.bugseng.com/products/ppl/download/ftp/releases/1.2/
If one has an existing working autobuilder it can be retrieved from that. If
the package is put in gcc4/srcdir.orig then the autobuilder does not try to
fetch it.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> I'm trying to build gccsdk but it fails because it doesn't find the
> ppl-1.2.tar.gz package:
[snip]
> It tries to download it
> from ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz but
> that link seems to be dead. I think I did find a place to download it
> at the bottom of this page:
> http://www.prismmodelchecker.org/other-downloads.php
I found it at :-
https://www.bugseng.com/products/ppl/download/ftp/releases/1.2/
If one has an existing working autobuilder it can be retrieved from that. If
the package is put in gcc4/srcdir.orig then the autobuilder does not try to
fetch it.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] Build problems for crosscompiler
I'm trying to build gccsdk but it fails because it doesn't find the ppl-1.2.tar.gz package:
-------------------------------
make[2]: Leaving directory '/home/jjvdgeer/gccsdk_new/gcc4/builddir/cross-mpc'
make[2]: Leaving directory '/home/jjvdgeer/gccsdk_new/gcc4/builddir/cross-mpc'
touch buildstepsdir/cross-mpc-built
mkdir -p /home/jjvdgeer/gccsdk_new/gcc4/srcdir.orig
cd /home/jjvdgeer/gccsdk_new/gcc4/srcdir.orig && wget -c ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz
--2020-09-03 23:41:24-- ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz
=> ‘ppl-1.2.tar.gz’
Resolving ftp.cs.unipr.it (ftp.cs.unipr.it)... 160.78.167.140
Connecting to ftp.cs.unipr.it (ftp.cs.unipr.it)|160.78.167.140|:21... connected.
Logging in as anonymous ...
Login incorrect.
make[1]: *** [Makefile:723: /home/jjvdgeer/gccsdk_new/gcc4/srcdir.orig/ppl-1.2.tar.gz] Error 6
make[1]: Leaving directory '/home/jjvdgeer/gccsdk_new/gcc4'
make: *** [Makefile:256: getenv] Error 2
Looks like the build failed. You might want to check out the README for what to do now.
If 'build-cross-output.txt' exists, this will contain a record of the failure. You can send the end of it to the GCCSDK mailing list for help.
Once you fix the problem, you can simply run this script again. Note doing this will overwrite 'build-cross-output.txt' log file.
-------------------------------
It tries to download it from ftp://ftp.cs.unipr.it/pub/ppl/releases/1.2/ppl-1.2.tar.gz but that link seems to be dead. I think I did find a place to download it at the bottom of this page:
http://www.prismmodelchecker.org/other-downloads.php
Cheers,
Jan-Jaap
-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas! 15GB disk space!
Commercial and Bulk Mail Options!
Wednesday, 2 September 2020
Re: [gccsdk] Recommended distros for autobuilder
In article <mpro.qg1urj002ppce1t6z.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> >
> >
> > curl should now build as well.
> It did with r7415 but r7416 errors.
> checking that c-ares is good and recent enough... no
> configure: error: c-ares library defective or too old
> Autobuilder: Running make command: /home/djp/gccsdk/env/ro-make
> Autobuilder: No known build method
> Package curl: ***Failure***
> Build for package "curl" failed
> That was resolved by building c-ares. curl then built.
Now fixed. c-ares will now get built first.
_______________________________________________
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
David Pitt <pittdj@pittdj.co.uk> wrote:
> >
> >
> > curl should now build as well.
> It did with r7415 but r7416 errors.
> checking that c-ares is good and recent enough... no
> configure: error: c-ares library defective or too old
> Autobuilder: Running make command: /home/djp/gccsdk/env/ro-make
> Autobuilder: No known build method
> Package curl: ***Failure***
> Build for package "curl" failed
> That was resolved by building c-ares. curl then built.
Now fixed. c-ares will now get built first.
_______________________________________________
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] Recommended distros for autobuilder
Chris Gransden, on 2 Sep, wrote:
[snip]
> pdf should also now build.
It has, many thanks.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[snip]
> pdf should also now build.
It has, many thanks.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Recommended distros for autobuilder
Chris Gransden, on 2 Sep, wrote:
> On 02 Sep, chrisg@care4free.net wrote:
> > In article <58a9c68443chrisg@care4free.net>,
> > Chris Gransden <chrisg@care4free.net> wrote:
> > > In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> > > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > > David Pitt, on 2 Sep, wrote:
>
> > > > [snip]
>
> > > > > My general view is that little now builds on Ubuntu 20.04 or
> > > > > 18.04.
>
> > > > Some examples from Ubuntu 18.04
>
> > > > curl
> > > >
>
> > > > wget
>
>
> > > > pdf
>
>
> > > None of those are due to the version of Ubuntu you are using. The
> > > upstream versions have changed so the patches need updating.
>
>
> > wget should build now.
>
>
> curl should now build as well.
It did with r7415 but r7416 errors.
checking that c-ares is good and recent enough... no
configure: error: c-ares library defective or too old
Autobuilder: Running make command: /home/djp/gccsdk/env/ro-make
Autobuilder: No known build method
Package curl: ***Failure***
Build for package "curl" failed
That was resolved by building c-ares. curl then built.
Thanks.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> On 02 Sep, chrisg@care4free.net wrote:
> > In article <58a9c68443chrisg@care4free.net>,
> > Chris Gransden <chrisg@care4free.net> wrote:
> > > In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> > > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > > David Pitt, on 2 Sep, wrote:
>
> > > > [snip]
>
> > > > > My general view is that little now builds on Ubuntu 20.04 or
> > > > > 18.04.
>
> > > > Some examples from Ubuntu 18.04
>
> > > > curl
> > > >
>
> > > > wget
>
>
>
>
> > > None of those are due to the version of Ubuntu you are using. The
> > > upstream versions have changed so the patches need updating.
>
>
> > wget should build now.
>
>
> curl should now build as well.
It did with r7415 but r7416 errors.
checking that c-ares is good and recent enough... no
configure: error: c-ares library defective or too old
Autobuilder: Running make command: /home/djp/gccsdk/env/ro-make
Autobuilder: No known build method
Package curl: ***Failure***
Build for package "curl" failed
That was resolved by building c-ares. curl then built.
Thanks.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Recommended distros for autobuilder
In article <58a9d80ba7chrisg@care4free.net>,
Chris Gransden <chrisg@care4free.net> wrote:
> On 02 Sep, chrisg@care4free.net wrote:
> > In article <58a9c68443chrisg@care4free.net>,
> > Chris Gransden <chrisg@care4free.net> wrote:
> > > In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> > > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > > David Pitt, on 2 Sep, wrote:
> > > > [snip]
> > > > > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> > > > Some examples from Ubuntu 18.04
> > > > curl
> > > >
> > > > wget
> > > > pdf
> > wget should build now.
> curl should now build as well.
pdf should also now build.
_______________________________________________
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
Chris Gransden <chrisg@care4free.net> wrote:
> On 02 Sep, chrisg@care4free.net wrote:
> > In article <58a9c68443chrisg@care4free.net>,
> > Chris Gransden <chrisg@care4free.net> wrote:
> > > In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> > > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > > David Pitt, on 2 Sep, wrote:
> > > > [snip]
> > > > > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> > > > Some examples from Ubuntu 18.04
> > > > curl
> > > >
> > > > wget
> > wget should build now.
> curl should now build as well.
pdf should also now build.
_______________________________________________
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] Recommended distros for autobuilder
On 02 Sep, chrisg@care4free.net wrote:
> In article <58a9c68443chrisg@care4free.net>,
> Chris Gransden <chrisg@care4free.net> wrote:
> > In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > David Pitt, on 2 Sep, wrote:
> > > [snip]
> > > > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> > > Some examples from Ubuntu 18.04
> > > curl
> > >
> > > wget
> > > pdf
> > None of those are due to the version of Ubuntu you are using. The upstream
> > versions have changed so the patches need updating.
> wget should build now.
curl should now build as well.
_______________________________________________
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
> In article <58a9c68443chrisg@care4free.net>,
> Chris Gransden <chrisg@care4free.net> wrote:
> > In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > David Pitt, on 2 Sep, wrote:
> > > [snip]
> > > > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> > > Some examples from Ubuntu 18.04
> > > curl
> > >
> > > wget
> > None of those are due to the version of Ubuntu you are using. The upstream
> > versions have changed so the patches need updating.
> wget should build now.
curl should now build as well.
_______________________________________________
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] Recommended distros for autobuilder
Chris Gransden, on 2 Sep, wrote:
> In article <58a9c68443chrisg@care4free.net>,
> Chris Gransden <chrisg@care4free.net> wrote:
[snip]
> wget should build now.
It has, thanks.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In article <58a9c68443chrisg@care4free.net>,
> Chris Gransden <chrisg@care4free.net> wrote:
[snip]
> wget should build now.
It has, thanks.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Recommended distros for autobuilder
In article <58a9c68443chrisg@care4free.net>,
Chris Gransden <chrisg@care4free.net> wrote:
> In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
> > David Pitt, on 2 Sep, wrote:
> > [snip]
> > > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> > Some examples from Ubuntu 18.04
> > curl
> >
> > wget
> > pdf
> None of those are due to the version of Ubuntu you are using. The upstream
> versions have changed so the patches need updating.
wget should build now.
_______________________________________________
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
Chris Gransden <chrisg@care4free.net> wrote:
> In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
> > David Pitt, on 2 Sep, wrote:
> > [snip]
> > > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> > Some examples from Ubuntu 18.04
> > curl
> >
> > wget
> None of those are due to the version of Ubuntu you are using. The upstream
> versions have changed so the patches need updating.
wget should build now.
_______________________________________________
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] Recommended distros for autobuilder
In article <20200902172547.m43xjcsk7xr7lxbl@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:
> On Wed, Sep 02, 2020 at 06:00:15PM +0100, Chris Gransden wrote:
> > None of those are due to the version of Ubuntu you are using. The upstream
> > versions have changed so the patches need updating.
> I suppose what I'm getting at is two things:
> 1) What are the build platform and source repository that is likely to cause
> least breakage building things?
> 2) If the answers to 1) are 'use something ancient', what would be the least
> painful way to make it less ancient?
> If people (Chris, Alan, Lee, others) are currently building stuff and fixing
> up problems, it would be good to understand which versions the patches going
> in to the autobuilder are intended for.
> Theo
A lot of recipes have been updated to build with 'Stable' so that is the
best one to use for now. Any that don't build in stable can be set back to
the previous build that worked using AB_URL or similar.
There are only a few that don't build in Debian Bullseye but do in Ubuntu
16.0.4 LTS.
As an example Qt5Webkit needed an older version of bison.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <theo@markettos.org.uk> wrote:
> On Wed, Sep 02, 2020 at 06:00:15PM +0100, Chris Gransden wrote:
> > None of those are due to the version of Ubuntu you are using. The upstream
> > versions have changed so the patches need updating.
> I suppose what I'm getting at is two things:
> 1) What are the build platform and source repository that is likely to cause
> least breakage building things?
> 2) If the answers to 1) are 'use something ancient', what would be the least
> painful way to make it less ancient?
> If people (Chris, Alan, Lee, others) are currently building stuff and fixing
> up problems, it would be good to understand which versions the patches going
> in to the autobuilder are intended for.
> Theo
A lot of recipes have been updated to build with 'Stable' so that is the
best one to use for now. Any that don't build in stable can be set back to
the previous build that worked using AB_URL or similar.
There are only a few that don't build in Debian Bullseye but do in Ubuntu
16.0.4 LTS.
As an example Qt5Webkit needed an older version of bison.
_______________________________________________
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] Recommended distros for autobuilder
Den ons 2 sep. 2020 19:28Theo Markettos <theo@markettos.org.uk> skrev:
On Wed, Sep 02, 2020 at 06:00:15PM +0100, Chris Gransden wrote:
> None of those are due to the version of Ubuntu you are using. The upstream
> versions have changed so the patches need updating.
I suppose what I'm getting at is two things:
1) What are the build platform and source repository that is likely to cause
least breakage building things?
2) If the answers to 1) are 'use something ancient', what would be the least
painful way to make it less ancient?
If people (Chris, Alan, Lee, others) are currently building stuff and fixing
up problems, it would be good to understand which versions the patches going
in to
I think it really is time to stop using debian as source. I built the whole gtk 3 stack some time ago. I ended up fetching original source tar balls. I hand patched and at least in most cases created patch diffs and added to autobuilder.
Michael
Re: [gccsdk] Recommended distros for autobuilder
On Wed, Sep 02, 2020 at 06:00:15PM +0100, Chris Gransden wrote:
> None of those are due to the version of Ubuntu you are using. The upstream
> versions have changed so the patches need updating.
I suppose what I'm getting at is two things:
1) What are the build platform and source repository that is likely to cause
least breakage building things?
2) If the answers to 1) are 'use something ancient', what would be the least
painful way to make it less ancient?
If people (Chris, Alan, Lee, others) are currently building stuff and fixing
up problems, it would be good to understand which versions the patches going
in to the autobuilder are intended for.
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
> None of those are due to the version of Ubuntu you are using. The upstream
> versions have changed so the patches need updating.
I suppose what I'm getting at is two things:
1) What are the build platform and source repository that is likely to cause
least breakage building things?
2) If the answers to 1) are 'use something ancient', what would be the least
painful way to make it less ancient?
If people (Chris, Alan, Lee, others) are currently building stuff and fixing
up problems, it would be good to understand which versions the patches going
in to the autobuilder are intended for.
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] Recommended distros for autobuilder
In article <mpro.qg1iky002hsio1s3t.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> David Pitt, on 2 Sep, wrote:
> [snip]
> > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> Some examples from Ubuntu 18.04
> curl
>
> wget
> pdf
None of those are due to the version of Ubuntu you are using. The upstream
versions have changed so the patches need updating.
_______________________________________________
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
David Pitt <pittdj@pittdj.co.uk> wrote:
> David Pitt, on 2 Sep, wrote:
> [snip]
> > My general view is that little now builds on Ubuntu 20.04 or 18.04.
> Some examples from Ubuntu 18.04
> curl
>
> wget
None of those are due to the version of Ubuntu you are using. The upstream
versions have changed so the patches need updating.
_______________________________________________
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] Recommended distros for autobuilder
David Pitt, on 2 Sep, wrote:
[snip]
> My general view is that little now builds on Ubuntu 20.04 or 18.04.
Some examples from Ubuntu 18.04
curl
rsa-sign-tr.c: In function 'sec_equal':
rsa-sign-tr.c:243:3: error: 'for' loop initial declarations are only allowed
in C99 mode
rsa-sign-tr.c:243:3: note: use option -std=c99 or -std=gnu99 to compile your
code
Makefile:260: recipe for target 'rsa-sign-tr.o' failed
make[1]: *** [rsa-sign-tr.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/djp/gccsdk/build/libnettle6/nettle-3.4.1'
Makefile:49: recipe for target 'all' failed
make: *** [all] Error 2
Package libnettle6: ***Failure***
Dependency "libnettle6" failed for libgnutls30
Dependency "libgnutls30" failed for curl
Build for package "curl" failed
wget
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/unistd.in.h.p
patching file lib/unistd.in.h
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/hsts.c.p
patching file src/hsts.c
Hunk #1 succeeded at 562 (offset 2 lines).
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/link.c.p
patching file lib/link.c
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/ptimer.c.p
patching file src/ptimer.c
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/getgroups.c.p
patching file lib/getgroups.c
Autobuilder: Patches failed
pdf
Autobuilder: Building package: pdf
Autobuilder: Detected 8 CPUs: set AB_CPUS to use more or fewer (eg in case
build breaks)
Autobuilder: Fetching source for pdf
Autobuilder: Calling preprocess
cvs [checkout aborted]: connect to riscosopen.org(91.203.57.172):2401
failed: Connection refused
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[snip]
> My general view is that little now builds on Ubuntu 20.04 or 18.04.
Some examples from Ubuntu 18.04
curl
rsa-sign-tr.c: In function 'sec_equal':
rsa-sign-tr.c:243:3: error: 'for' loop initial declarations are only allowed
in C99 mode
rsa-sign-tr.c:243:3: note: use option -std=c99 or -std=gnu99 to compile your
code
Makefile:260: recipe for target 'rsa-sign-tr.o' failed
make[1]: *** [rsa-sign-tr.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/djp/gccsdk/build/libnettle6/nettle-3.4.1'
Makefile:49: recipe for target 'all' failed
make: *** [all] Error 2
Package libnettle6: ***Failure***
Dependency "libnettle6" failed for libgnutls30
Dependency "libgnutls30" failed for curl
Build for package "curl" failed
wget
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/unistd.in.h.p
patching file lib/unistd.in.h
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/hsts.c.p
patching file src/hsts.c
Hunk #1 succeeded at 562 (offset 2 lines).
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/link.c.p
patching file lib/link.c
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/ptimer.c.p
patching file src/ptimer.c
Autobuilder: RISC OS patch:
/home/djp/gccsdk/autobuilder/network/wget/getgroups.c.p
patching file lib/getgroups.c
Autobuilder: Patches failed
Autobuilder: Building package: pdf
Autobuilder: Detected 8 CPUs: set AB_CPUS to use more or fewer (eg in case
build breaks)
Autobuilder: Fetching source for pdf
Autobuilder: Calling preprocess
cvs [checkout aborted]: connect to riscosopen.org(91.203.57.172):2401
failed: Connection refused
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Recommended distros for autobuilder
alan buckley, on 2 Sep, wrote:
> Theo Markettos<mailto:theo@markettos.org.uk> wrote on 02 September 2020
> 16:42
>
>
> > On Wed, Sep 02, 2020 at 12:02:00PM +0100, Chris Gransden wrote:
> > > In article <20200902093453.57jkr4hskfed2pjt@chiark.greenend.org.uk>,
> > > Theo Markettos <theo@markettos.org.uk> wrote:
> > > > For those who have been (re)building autobuilder packages, what OS
> > > > are you currently building on? And which sources are you building?
> > >
> > > Mostly debian Bullseye using 'Stable' sources. Some packages fail to
> > > build on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
> > Thanks, that's useful.
>
> I've been building on Ubuntu 18.0.4 LTS for the packages I've been
> uploading. I find that I get some failures when building the packages
> Chris has just updated. So far most of the failures have been missing
> tools though.
My general view is that little now builds on Ubuntu 20.04 or 18.04.
As an example I have been unable to build otterbrowser on Ubuntu, with
either 20.04 or 18.04. It fails in libexpat with this :-
make[2]: Leaving directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat/xmlwf'
Making all in doc
make[2]: Entering directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat/doc'
ERROR: Configure with --with-docbook for "make dist".
Makefile:567: recipe for target 'xmlwf.1' failed
make[2]: *** [xmlwf.1] Error 1
make[2]: Leaving directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat/doc'
Makefile:558: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat'
Makefile:465: recipe for target 'all' failed
make: *** [all] Error 2
I am now off to try my luck with Ubuntu 16.04.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Theo Markettos<mailto:theo@markettos.org.uk> wrote on 02 September 2020
> 16:42
>
>
> > On Wed, Sep 02, 2020 at 12:02:00PM +0100, Chris Gransden wrote:
> > > In article <20200902093453.57jkr4hskfed2pjt@chiark.greenend.org.uk>,
> > > Theo Markettos <theo@markettos.org.uk> wrote:
> > > > For those who have been (re)building autobuilder packages, what OS
> > > > are you currently building on? And which sources are you building?
> > >
> > > Mostly debian Bullseye using 'Stable' sources. Some packages fail to
> > > build on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
> > Thanks, that's useful.
>
> I've been building on Ubuntu 18.0.4 LTS for the packages I've been
> uploading. I find that I get some failures when building the packages
> Chris has just updated. So far most of the failures have been missing
> tools though.
My general view is that little now builds on Ubuntu 20.04 or 18.04.
As an example I have been unable to build otterbrowser on Ubuntu, with
either 20.04 or 18.04. It fails in libexpat with this :-
make[2]: Leaving directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat/xmlwf'
Making all in doc
make[2]: Entering directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat/doc'
ERROR: Configure with --with-docbook for "make dist".
Makefile:567: recipe for target 'xmlwf.1' failed
make[2]: *** [xmlwf.1] Error 1
make[2]: Leaving directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat/doc'
Makefile:558: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/djp/gccsdk/build/libexpat1/libexpat-R_2_2_6/expat'
Makefile:465: recipe for target 'all' failed
make: *** [all] Error 2
I am now off to try my luck with Ubuntu 16.04.
--
David Pitt
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Recommended distros for autobuilder
Theo Markettos wrote on 02 September 2020 16:42
> On Wed, Sep 02, 2020 at 12:02:00PM +0100, Chris Gransden wrote:
> > In article <20200902093453.57jkr4hskfed2pjt@chiark.greenend.org.uk>,
> > Theo Markettos <theo@markettos.org.uk> wrote:
> > > For those who have been (re)building autobuilder packages, what OS are you
> > > currently building on? And which sources are you building?
> >
> > Mostly debian Bullseye using 'Stable' sources. Some packages fail to build
> > on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
> Thanks, that's useful.
I've been building on Ubuntu 18.0.4 LTS for the packages I've been uploading.
I find that I get some failures when building the packages Chris has just updated.
So far most of the failures have been missing tools though.
Regards,
Alan
Re: [gccsdk] Recommended distros for autobuilder
On Wed, Sep 02, 2020 at 12:02:00PM +0100, Chris Gransden wrote:
> In article <20200902093453.57jkr4hskfed2pjt@chiark.greenend.org.uk>,
> Theo Markettos <theo@markettos.org.uk> wrote:
> > For those who have been (re)building autobuilder packages, what OS are you
> > currently building on? And which sources are you building?
>
> Mostly debian Bullseye using 'Stable' sources. Some packages fail to build
> on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
Thanks, that's useful.
How common is it for packages to fail to build on bullseye, and what do the
failures look like? Are they simple fixes, or things that involve long
chains of dependency problems?
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
> In article <20200902093453.57jkr4hskfed2pjt@chiark.greenend.org.uk>,
> Theo Markettos <theo@markettos.org.uk> wrote:
> > For those who have been (re)building autobuilder packages, what OS are you
> > currently building on? And which sources are you building?
>
> Mostly debian Bullseye using 'Stable' sources. Some packages fail to build
> on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
Thanks, that's useful.
How common is it for packages to fail to build on bullseye, and what do the
failures look like? Are they simple fixes, or things that involve long
chains of dependency problems?
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] Recommended distros for autobuilder
In article <20200902093453.57jkr4hskfed2pjt@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:
> For those who have been (re)building autobuilder packages, what OS are you
> currently building on? And which sources are you building?
> I think historically the autobuilder has used Debian 'stable' sources, which
> meant an unexpected wave of breakage whenever Debian decided to release a
> new 'stable' distro. That appears to still be the case, is that right?
> In terms of build OS, is there any reason to use something other than the
> latest Ubuntu LTS (20.04)? Last time I set up mass builds I used Ubuntu
> 14.04, which is a bit old nowadays. Sometimes the packages needed for
> particular builds can vary between distros, and it would save effort if I
> could use whatever other people have got to work. What have you been using?
> To some degree using Debian 'stable' for the build distro as well makes some
> kind of sense, but I don't know if that's what people are doing.
Mostly debian Bullseye using 'Stable' sources. Some packages fail to build
on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <theo@markettos.org.uk> wrote:
> For those who have been (re)building autobuilder packages, what OS are you
> currently building on? And which sources are you building?
> I think historically the autobuilder has used Debian 'stable' sources, which
> meant an unexpected wave of breakage whenever Debian decided to release a
> new 'stable' distro. That appears to still be the case, is that right?
> In terms of build OS, is there any reason to use something other than the
> latest Ubuntu LTS (20.04)? Last time I set up mass builds I used Ubuntu
> 14.04, which is a bit old nowadays. Sometimes the packages needed for
> particular builds can vary between distros, and it would save effort if I
> could use whatever other people have got to work. What have you been using?
> To some degree using Debian 'stable' for the build distro as well makes some
> kind of sense, but I don't know if that's what people are doing.
Mostly debian Bullseye using 'Stable' sources. Some packages fail to build
on more recent distros. If this happens then Unbuntu 16.0.4 LTS.
_______________________________________________
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] Recommended distros for autobuilder
For those who have been (re)building autobuilder packages, what OS are you
currently building on? And which sources are you building?
I think historically the autobuilder has used Debian 'stable' sources, which
meant an unexpected wave of breakage whenever Debian decided to release a
new 'stable' distro. That appears to still be the case, is that right?
In terms of build OS, is there any reason to use something other than the
latest Ubuntu LTS (20.04)? Last time I set up mass builds I used Ubuntu
14.04, which is a bit old nowadays. Sometimes the packages needed for
particular builds can vary between distros, and it would save effort if I
could use whatever other people have got to work. What have you been using?
To some degree using Debian 'stable' for the build distro as well makes some
kind of sense, but I don't know if that's what people are doing.
Thanks
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
currently building on? And which sources are you building?
I think historically the autobuilder has used Debian 'stable' sources, which
meant an unexpected wave of breakage whenever Debian decided to release a
new 'stable' distro. That appears to still be the case, is that right?
In terms of build OS, is there any reason to use something other than the
latest Ubuntu LTS (20.04)? Last time I set up mass builds I used Ubuntu
14.04, which is a bit old nowadays. Sometimes the packages needed for
particular builds can vary between distros, and it would save effort if I
could use whatever other people have got to work. What have you been using?
To some degree using Debian 'stable' for the build distro as well makes some
kind of sense, but I don't know if that's what people are doing.
Thanks
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Subscribe to:
Posts (Atom)