On 27 Apr, cj wrote in message
<56ef67beabchris@chris-johnson.org.uk>:
> In article <9e0265ef56.jim@6.abbeypress.net>,
> Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> > Anybody concur with me?
>
> Yes - this has been present since the dark ages. I thought it had been
> reported many years ago.
I'm fairly sure (without going to check) that it's both known about and has
been stated that it is being ignored until the component responsible is
replaced as part of the road to Javascript. I'm guessing the layout engine,
but I could easily be wrong on that -- as Chris says, it has been many
years.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Friday, 27 April 2018
Re: bad linebreaks
On 27 Apr 2018 Jim Nagel wrote:
> Anybody concur with me?
Yes I've raised bug reports about it in the past.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> Anybody concur with me?
Yes I've raised bug reports about it in the past.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: bad linebreaks
In article <9e0265ef56.jim@6.abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Anybody concur with me?
Yes - this has been present since the dark ages. I thought it had
been reported many years ago.
--
Chris Johnson
Edinburgh
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Anybody concur with me?
Yes - this has been present since the dark ages. I thought it had
been reported many years ago.
--
Chris Johnson
Edinburgh
bad linebreaks
I raised a report on the bug-tracker about really bad linebreaks that
Netsurf sometimes commits.
This isn't a new thing. I'm using #4316 but fault has existed since
many many versions ago and as far as I know has never been reported.
My theory is that the Netsurf code thinks it's OK to start a new line
when text reaches nearly the edge of the frame and that it can perform
the break not only at a wordspace but also at an HTML tag, i.e. at "<"
or ">" or "&xxx;". (Hmm, what about ?)
You too often see a word like "John’s" with the apostrophe-s or
just the -s on the next line. Or a split in the middle of something
like "<i>x</i><sup>2</sup>=4<i>y</i>". Or "(<a href=...> blabla</a>)"
can leave the opening or closing parenthesis on a different line. Or
worse.
It obviously depends on the width of the window, so you might have to
drag the width to see it happen (presuming of course that it's not a
fixed-width page). Try a news page from http://theregister.co.uk as
an example.
Anybody concur with me?
--
Jim Nagel www.archivemag.co.uk
Netsurf sometimes commits.
This isn't a new thing. I'm using #4316 but fault has existed since
many many versions ago and as far as I know has never been reported.
My theory is that the Netsurf code thinks it's OK to start a new line
when text reaches nearly the edge of the frame and that it can perform
the break not only at a wordspace but also at an HTML tag, i.e. at "<"
or ">" or "&xxx;". (Hmm, what about ?)
You too often see a word like "John’s" with the apostrophe-s or
just the -s on the next line. Or a split in the middle of something
like "<i>x</i><sup>2</sup>=4<i>y</i>". Or "(<a href=...> blabla</a>)"
can leave the opening or closing parenthesis on a different line. Or
worse.
It obviously depends on the width of the window, so you might have to
drag the width to see it happen (presuming of course that it's not a
fixed-width page). Try a news page from http://theregister.co.uk as
an example.
Anybody concur with me?
--
Jim Nagel www.archivemag.co.uk
Re: Netsurf Disc Cache
In article <56ef43aa6dnetsurf@avisoft.f9.co.uk>,
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> If anyone wants to try my small program which produces file and directory
> statistics for the disc cache, plus an obey file which if run will delete
> all empty directories, please email me.
Yes please.
I have, on a few occasions, simply deleted <Cache$Dir>.Netsurf and
released several GB of space. Deleting the whole cache causes no
noticeable problem.
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> If anyone wants to try my small program which produces file and directory
> statistics for the disc cache, plus an obey file which if run will delete
> all empty directories, please email me.
Yes please.
I have, on a few occasions, simply deleted <Cache$Dir>.Netsurf and
released several GB of space. Deleting the whole cache causes no
noticeable problem.
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Netsurf Disc Cache
I know from previous posts that using the Netsurf v3.7 disc cache on my
Iyonix running RISC OS is probably not improving performance, depending
on how low my internet speed is. I am using it to gain experience in the
hope that newer, faster hardware will bring some performance benefits.
After running with a Disc cache of 500MB and expiry of 30 days for about
2 years it was holding around 6,000 files using about 580MB. Old unused
files are being deleted, so these numbers seem stable and acceptable.
But it was using 45,000 directories ... 23,000 of which were empty (or
just contained other empty directories) occupying 45MB of disc space. I
realise these figures are small on today's large discs, but I am still
concerned that there is no 'clean up' process for unused empty
directories, so they will just grow and grow.
Earlier this month I deleted all empty directories, with no problems.
If anyone wants to try my small program which produces file and directory
statistics for the disc cache, plus an obey file which if run will delete
all empty directories, please email me.
Martin
Iyonix running RISC OS is probably not improving performance, depending
on how low my internet speed is. I am using it to gain experience in the
hope that newer, faster hardware will bring some performance benefits.
After running with a Disc cache of 500MB and expiry of 30 days for about
2 years it was holding around 6,000 files using about 580MB. Old unused
files are being deleted, so these numbers seem stable and acceptable.
But it was using 45,000 directories ... 23,000 of which were empty (or
just contained other empty directories) occupying 45MB of disc space. I
realise these figures are small on today's large discs, but I am still
concerned that there is no 'clean up' process for unused empty
directories, so they will just grow and grow.
Earlier this month I deleted all empty directories, with no problems.
If anyone wants to try my small program which produces file and directory
statistics for the disc cache, plus an obey file which if run will delete
all empty directories, please email me.
Martin
Sunday, 22 April 2018
Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
On 20/04/2018 17:00, Lee Noar wrote:
> On 19/04/18 12:51, Theo Markettos wrote:
>> On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
>>> I have ELF and Absolute binaries getting different values of
>>> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
>>> binary that is giving the wrong result, and it only seems to happen when the
>>> binary is run via a RISC OS variable containing the full pathname of the
>>> binary.
>> Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
>> see elf2aif is simply slapping a pre-baked header on the ELF which does
>> zero-initialisation and then jumps to the ELF's entry point. Beyond a
>> handful of instructions they're identical.
>>
>> __riscosify_control is a weak symbol so there *could* be something different
>> in linking, but here the linked binary is static and the difference is shown
>> with the same linked binary, with and without header.
>>
>> So my guess is either that the header has some subtle side effect on the OS
>> that causes it to do different things, or that SOManager is changing things
>> when a statically linked ELF is run directly.
>>
>> Lee, do you have any thoughts?
> Yes, in the last AIF one, the code that constructs the system variable
> name in Unixlib takes the program name as <Test$pathname>, so it's
> looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
> obviously fails.
Shouldn't Unixlib really be expanding <Test$pathname> to the full
pathname, getting the leafname, and then looking for a variable called
UnixEnv$leafname$nonametrans?
_______________________________________________
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 19/04/18 12:51, Theo Markettos wrote:
>> On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
>>> I have ELF and Absolute binaries getting different values of
>>> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
>>> binary that is giving the wrong result, and it only seems to happen when the
>>> binary is run via a RISC OS variable containing the full pathname of the
>>> binary.
>> Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
>> see elf2aif is simply slapping a pre-baked header on the ELF which does
>> zero-initialisation and then jumps to the ELF's entry point. Beyond a
>> handful of instructions they're identical.
>>
>> __riscosify_control is a weak symbol so there *could* be something different
>> in linking, but here the linked binary is static and the difference is shown
>> with the same linked binary, with and without header.
>>
>> So my guess is either that the header has some subtle side effect on the OS
>> that causes it to do different things, or that SOManager is changing things
>> when a statically linked ELF is run directly.
>>
>> Lee, do you have any thoughts?
> Yes, in the last AIF one, the code that constructs the system variable
> name in Unixlib takes the program name as <Test$pathname>, so it's
> looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
> obviously fails.
Shouldn't Unixlib really be expanding <Test$pathname> to the full
pathname, getting the leafname, and then looking for a variable called
UnixEnv$leafname$nonametrans?
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 20 April 2018
Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
On 19/04/18 12:51, Theo Markettos wrote:
> On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
>> This is a bug report, but since the bug reporting list has been out of
>> action for some time, I'm sending it here.
>
> Thanks. We should probably start a new issue tracker on github and migrate
> across. (apologies for closing some of your bugs on the old system BTW - I
> wasn't denying they were valid, just trying to reduce the amount of spamming
> I was getting from bugzilla)
>
>> I have ELF and Absolute binaries getting different values of
>> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
>> binary that is giving the wrong result, and it only seems to happen when the
>> binary is run via a RISC OS variable containing the full pathname of the
>> binary.
>
> Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
> see elf2aif is simply slapping a pre-baked header on the ELF which does
> zero-initialisation and then jumps to the ELF's entry point. Beyond a
> handful of instructions they're identical.
>
> __riscosify_control is a weak symbol so there *could* be something different
> in linking, but here the linked binary is static and the difference is shown
> with the same linked binary, with and without header.
>
> So my guess is either that the header has some subtle side effect on the OS
> that causes it to do different things, or that SOManager is changing things
> when a statically linked ELF is run directly.
>
> Lee, do you have any thoughts?
Yes, in the last AIF one, the code that constructs the system variable
name in Unixlib takes the program name as <Test$pathname>, so it's
looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
obviously fails.
When SOManager is responsible for starting the program, Test$pathname
is being expanded to the full filename, probably by the DDEUtils module,
so Unixlib finds the leaf name correctly.
So you're write that SOManager is changing things, but I don't think
it could be called a bug.
The best work around is to explicitly name the program in the code:
const char *const __program_name="testbin";
Unixlib will then always use this instead of the CLI.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
>> This is a bug report, but since the bug reporting list has been out of
>> action for some time, I'm sending it here.
>
> Thanks. We should probably start a new issue tracker on github and migrate
> across. (apologies for closing some of your bugs on the old system BTW - I
> wasn't denying they were valid, just trying to reduce the amount of spamming
> I was getting from bugzilla)
>
>> I have ELF and Absolute binaries getting different values of
>> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
>> binary that is giving the wrong result, and it only seems to happen when the
>> binary is run via a RISC OS variable containing the full pathname of the
>> binary.
>
> Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
> see elf2aif is simply slapping a pre-baked header on the ELF which does
> zero-initialisation and then jumps to the ELF's entry point. Beyond a
> handful of instructions they're identical.
>
> __riscosify_control is a weak symbol so there *could* be something different
> in linking, but here the linked binary is static and the difference is shown
> with the same linked binary, with and without header.
>
> So my guess is either that the header has some subtle side effect on the OS
> that causes it to do different things, or that SOManager is changing things
> when a statically linked ELF is run directly.
>
> Lee, do you have any thoughts?
Yes, in the last AIF one, the code that constructs the system variable
name in Unixlib takes the program name as <Test$pathname>, so it's
looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
obviously fails.
When SOManager is responsible for starting the program, Test$pathname
is being expanded to the full filename, probably by the DDEUtils module,
so Unixlib finds the leaf name correctly.
So you're write that SOManager is changing things, but I don't think
it could be called a bug.
The best work around is to explicitly name the program in the code:
const char *const __program_name="testbin";
Unixlib will then always use this instead of the CLI.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 19 April 2018
Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
> This is a bug report, but since the bug reporting list has been out of
> action for some time, I'm sending it here.
Thanks. We should probably start a new issue tracker on github and migrate
across. (apologies for closing some of your bugs on the old system BTW - I
wasn't denying they were valid, just trying to reduce the amount of spamming
I was getting from bugzilla)
> I have ELF and Absolute binaries getting different values of
> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
> binary that is giving the wrong result, and it only seems to happen when the
> binary is run via a RISC OS variable containing the full pathname of the
> binary.
Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
see elf2aif is simply slapping a pre-baked header on the ELF which does
zero-initialisation and then jumps to the ELF's entry point. Beyond a
handful of instructions they're identical.
__riscosify_control is a weak symbol so there *could* be something different
in linking, but here the linked binary is static and the difference is shown
with the same linked binary, with and without header.
So my guess is either that the header has some subtle side effect on the OS
that causes it to do different things, or that SOManager is changing things
when a statically linked ELF is run directly.
Lee, do you have any thoughts?
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
> This is a bug report, but since the bug reporting list has been out of
> action for some time, I'm sending it here.
Thanks. We should probably start a new issue tracker on github and migrate
across. (apologies for closing some of your bugs on the old system BTW - I
wasn't denying they were valid, just trying to reduce the amount of spamming
I was getting from bugzilla)
> I have ELF and Absolute binaries getting different values of
> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
> binary that is giving the wrong result, and it only seems to happen when the
> binary is run via a RISC OS variable containing the full pathname of the
> binary.
Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
see elf2aif is simply slapping a pre-baked header on the ELF which does
zero-initialisation and then jumps to the ELF's entry point. Beyond a
handful of instructions they're identical.
__riscosify_control is a weak symbol so there *could* be something different
in linking, but here the linked binary is static and the difference is shown
with the same linked binary, with and without header.
So my guess is either that the header has some subtle side effect on the OS
that causes it to do different things, or that SOManager is changing things
when a statically linked ELF is run directly.
Lee, do you have any thoughts?
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
Wednesday, 18 April 2018
[gccsdk] Absolute binaries giving incorrect __riscosify_control
This is a bug report, but since the bug reporting list has been out of
action for some time, I'm sending it here.
action for some time, I'm sending it here.
I have ELF and Absolute binaries getting different values of
__riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
binary that is giving the wrong result, and it only seems to happen when
the binary is run via a RISC OS variable containing the full pathname of
the binary.
This demonstrates the problem:
*Type c.noprocess
#include <stdio.h>
#include <unixlib/local.h>
int __riscosify_control;
int main(int argc,char** argv) {
(void) argc;
printf("%s\t ",argv[0]);
printf("%s\n",(__riscosify_control&__RISCOSIFY_NO_PROCESS) ? "RISCOS"
: "UNIX");
return 0;
}
*Type run (a TaskObey file)
Dir <Obey$Dir>
Set Test$dirname <Obey$Dir>
Set Test$pathname <Test$dirname>.testbin
gcc -o testbin -static -Wl,-s noprocess.c
Set UnixEnv$testbin$nonametrans ""
Echo Binary is ELF
testbin
<Test$dirname>.testbin
<Test$pathname>
Echo Binary is Absolute
elf2aif testbin
testbin
<Test$dirname>.testbin
<Test$pathname>
This is the output I get:
Binary is ELF
HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS
HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS
HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS
Binary is Absolute
HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS
HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS
/HostFS::HardDisc4.$/MyFiles/Transfer/testbin UNIX
The binary should output the same text each time, but is wrong the last
time.
I'm using:
gcc (GCCSDK GCC 4.7.4 Release 3) 4.7.4
SharedUnixLibrary 1.14
VirtualRPC-AdjustSA RISCOS 4.39
Regards
Duncan Moore
_______________________________________________
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
Sunday, 15 April 2018
Re: [gccsdk] An oddity
For the record, switching jenkins from svn 1.4 to svn 1.8 resolved the build issue
Thanks
JB
On 15/04/2018 16:39, John Ballance wrote:
Thanks Theo
Trying that
Jenkins default svn is 1.4 .. have now set to 1.8 to see what happens
On 15/04/2018 14:48, Theo Markettos wrote:
On Sun, Apr 15, 2018 at 02:23:42PM +0100, John Ballance wrote:svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof' is too old (format 8) to work with client version '1.9.7 (r1800392)' (expects format 31). You need to upgrade the working copy first.The Jenkins SVN plugin does its own thing in Java, it doesn't run the 'svn' command line client. It's checking out the repo in an older format. Upgrade the SVN plugin to the latest, then set the most recent version you can in: Manage Jenkins -> Configure System -> Subversion -> Subversion Workspace Version ci.riscos.info has this set as 1.8, but then it's mostly running on Ubuntu 14.04 which has an older svn. If your local 'svn' is still too new, your script needs to do 'svn upgrade' in the checkout directory. An alternative is to downgrade your 'svn' client, or install a build of an older version somewhere on the Jenkins slaves' path. 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
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
_______________________________________________ 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
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] An oddity
Thanks Theo
Trying that
Jenkins default svn is 1.4 .. have now set to 1.8 to see what happens
On 15/04/2018 14:48, Theo Markettos wrote:
On Sun, Apr 15, 2018 at 02:23:42PM +0100, John Ballance wrote:svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof' is too old (format 8) to work with client version '1.9.7 (r1800392)' (expects format 31). You need to upgrade the working copy first.The Jenkins SVN plugin does its own thing in Java, it doesn't run the 'svn' command line client. It's checking out the repo in an older format. Upgrade the SVN plugin to the latest, then set the most recent version you can in: Manage Jenkins -> Configure System -> Subversion -> Subversion Workspace Version ci.riscos.info has this set as 1.8, but then it's mostly running on Ubuntu 14.04 which has an older svn. If your local 'svn' is still too new, your script needs to do 'svn upgrade' in the checkout directory. An alternative is to downgrade your 'svn' client, or install a build of an older version somewhere on the Jenkins slaves' path. 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
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] An oddity
On Sun, Apr 15, 2018 at 02:23:42PM +0100, John Ballance wrote:
> svn: E155036: Please see the 'svn upgrade' command
> svn: E155036: The working copy at
> '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof'
> is too old (format 8) to work with client version '1.9.7 (r1800392)'
> (expects format 31). You need to upgrade the working copy first.
The Jenkins SVN plugin does its own thing in Java, it doesn't run the 'svn'
command line client. It's checking out the repo in an older format.
Upgrade the SVN plugin to the latest, then set the most recent version you
can in:
Manage Jenkins -> Configure System -> Subversion -> Subversion Workspace
Version
ci.riscos.info has this set as 1.8, but then it's mostly running on Ubuntu
14.04 which has an older svn.
If your local 'svn' is still too new, your script needs to do 'svn upgrade'
in the checkout directory.
An alternative is to downgrade your 'svn' client, or install a build of an
older version somewhere on the Jenkins slaves' path.
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
> svn: E155036: Please see the 'svn upgrade' command
> svn: E155036: The working copy at
> '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof'
> is too old (format 8) to work with client version '1.9.7 (r1800392)'
> (expects format 31). You need to upgrade the working copy first.
The Jenkins SVN plugin does its own thing in Java, it doesn't run the 'svn'
command line client. It's checking out the repo in an older format.
Upgrade the SVN plugin to the latest, then set the most recent version you
can in:
Manage Jenkins -> Configure System -> Subversion -> Subversion Workspace
Version
ci.riscos.info has this set as 1.8, but then it's mostly running on Ubuntu
14.04 which has an older svn.
If your local 'svn' is still too new, your script needs to do 'svn upgrade'
in the checkout directory.
An alternative is to downgrade your 'svn' client, or install a build of an
older version somewhere on the Jenkins slaves' path.
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
[gccsdk] An oddity
Hi
Building gccsdk, i've 2 approaches.
1) use jenkins to run my scripts including the svn co
2 use jenkins to do the svn co. of the gcc4 thing, which then goes and gets:
svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch gcc-trunk
in the first case I get:
U gcc-trunk
Checked out revision 259385.
In the second:
U gcc-trunk
Checked out revision 259389.
I wonder why its different?
(command is build_world && make ronative && create-gcckit)
Revision 385 builds right through , 389 fails in make ronative with the following complaint
Any suggestions
Making all in decaof
make[5]: Entering directory '/home/jb/jenkins_gccsdk/gcc4/builddir/cross/asasm/decaof'
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof'
is too old (format 8) to work with client version '1.9.7 (r1800392)' (expects format 31). You need to upgrade the working copy first.
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof'
is too old (format 8) to work with client version '1.9.7 (r1800392)' (expects format 31). You need to upgrade the working copy first.
svnversion: E155036: The working copy at '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof'
is too old (format 8) to work with client version '1.9.7 (r1800392)' (expects format 31). You need to upgrade the working copy first.
make all-am
make[6]: Entering directory '/home/jb/jenkins_gccsdk/gcc4/builddir/cross/asasm/decaof'
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jb/jenkins_gccsdk/gcc4/riscos/asasm/decaof'
is too old (format 8) to work with client version '1.9.7 (r1800392)' (expects format 31). You need to upgrade the working copy first.
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: URL crashes Netsurf
> Date: Sat, 14 Apr 2018 16:10:42 +0100
> From: Peter Young <pnyoung@ormail.co.uk>
> Subject: Re: URL crashes Netsurf
> To: netsurf-users@netsurf-browser.org
> Message-ID: <e58cabe856.pnyoung@pnyoung.ormail.co.uk>
> On 14 Apr 2018 Brian <bbailey@argonet.co.uk> wrote:
>
> > In article <56e87f0c06bbailey@argonet.co.uk>, Brian
> > <bbailey@argonet.co.uk> wrote:
> >> In article <56e81c01ccLists@Torrens.org>, Richard Torrens (lists)
> >> <Lists@Torrens.org> wrote:
> >>> This URL
>
> >>> www.siemens-home.bsh-group.com/uk
>
> >>> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>
> >>> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does
> >>> do a reset.
>
> >>> Does it happen to anyone else?
>
> >> No, not here. VRPC 4.02.
>
> > Well, it does now!
>
> Not here, 4.02 on VRPC
>
> Best wishes,
>
> Peter (in sunny Valencia!).
>
>
It's ok on Atari build 4321.
Peter
> From: Peter Young <pnyoung@ormail.co.uk>
> Subject: Re: URL crashes Netsurf
> To: netsurf-users@netsurf-browser.org
> Message-ID: <e58cabe856.pnyoung@pnyoung.ormail.co.uk>
> On 14 Apr 2018 Brian <bbailey@argonet.co.uk> wrote:
>
> > In article <56e87f0c06bbailey@argonet.co.uk>, Brian
> > <bbailey@argonet.co.uk> wrote:
> >> In article <56e81c01ccLists@Torrens.org>, Richard Torrens (lists)
> >> <Lists@Torrens.org> wrote:
> >>> This URL
>
> >>> www.siemens-home.bsh-group.com/uk
>
> >>> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>
> >>> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does
> >>> do a reset.
>
> >>> Does it happen to anyone else?
>
> >> No, not here. VRPC 4.02.
>
> > Well, it does now!
>
> Not here, 4.02 on VRPC
>
> Best wishes,
>
> Peter (in sunny Valencia!).
>
>
It's ok on Atari build 4321.
Peter
Saturday, 14 April 2018
Re: URL crashes Netsurf
In message <mpro.p7510b004krvh06hi.pittdj@pittdj.co.uk>
David Pitt <pittdj@pittdj.co.uk> wrote:
>David Pitt, on 13 Apr, wrote:
>
>Bug reported :-
>
>http://bugs.netsurf-browser.org/mantis/view.php?id=2593
>
>The thing was not totally reproducible here, the page sometime rendered on
>the Titanium. I tried JavaScript and other content blocking on and off
>without identifying anything useful.
>
>Please feel free to add to the bug report.
CI#4321 fixes it for me.
Dave
David Pitt <pittdj@pittdj.co.uk> wrote:
>David Pitt, on 13 Apr, wrote:
>
>Bug reported :-
>
>http://bugs.netsurf-browser.org/mantis/view.php?id=2593
>
>The thing was not totally reproducible here, the page sometime rendered on
>the Titanium. I tried JavaScript and other content blocking on and off
>without identifying anything useful.
>
>Please feel free to add to the bug report.
CI#4321 fixes it for me.
Dave
Re: [gccsdk] gcc from gccsdk
On Thu, Apr 12, 2018 at 11:32:42PM +0100, John Ballance wrote:
> Hi Theo
>
> Yes, this is what I'm seeing.
>
> The abort (ref google) appears to be due to the absence of some of the
> builtins referred to at line 54 of pngshim.c
>
> If I rearrange the conditional it'll go past that, then fails around line
> 110 calling the routine determined by line54 et al .. seems to be looking
> for a builtin that isn't 'responding'. gcc source suggests the builtin
> should be there..
>
> This is the patch pngshim.c.p I used to get past the abort .. cludgy I know
In view of the amount of breakage the recent Debian release is likely to
cause (not just this problem but others), I've set the autobuilder to fetch
packages from Debian 'stable' and 'oldstable', which should mean we're not
quite so bleeding edge. It won't have the very latest versions of things,
but they're more likely to build at all.
Jenkins is now doing a full rebuild, which should hopefully shake out which
packages are broken (the usual answer being 'rather a lot' :( )
http://ci.riscos.info/job/packages/
That's not to say we shouldn't work out why __builtin_shuffle is failing, of
course.
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
> Hi Theo
>
> Yes, this is what I'm seeing.
>
> The abort (ref google) appears to be due to the absence of some of the
> builtins referred to at line 54 of pngshim.c
>
> If I rearrange the conditional it'll go past that, then fails around line
> 110 calling the routine determined by line54 et al .. seems to be looking
> for a builtin that isn't 'responding'. gcc source suggests the builtin
> should be there..
>
> This is the patch pngshim.c.p I used to get past the abort .. cludgy I know
In view of the amount of breakage the recent Debian release is likely to
cause (not just this problem but others), I've set the autobuilder to fetch
packages from Debian 'stable' and 'oldstable', which should mean we're not
quite so bleeding edge. It won't have the very latest versions of things,
but they're more likely to build at all.
Jenkins is now doing a full rebuild, which should hopefully shake out which
packages are broken (the usual answer being 'rather a lot' :( )
http://ci.riscos.info/job/packages/
That's not to say we shouldn't work out why __builtin_shuffle is failing, of
course.
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: URL crashes Netsurf
On 14 Apr 2018 Brian <bbailey@argonet.co.uk> wrote:
> In article <56e87f0c06bbailey@argonet.co.uk>, Brian
> <bbailey@argonet.co.uk> wrote:
>> In article <56e81c01ccLists@Torrens.org>, Richard Torrens (lists)
>> <Lists@Torrens.org> wrote:
>>> This URL
>>> www.siemens-home.bsh-group.com/uk
>>> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>>> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does
>>> do a reset.
>>> Does it happen to anyone else?
>> No, not here. VRPC 4.02.
> Well, it does now!
Not here, 4.02 on VRPC
Best wishes,
Peter (in sunny Valencia!).
--
Peter Young (zfc Ir) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> In article <56e87f0c06bbailey@argonet.co.uk>, Brian
> <bbailey@argonet.co.uk> wrote:
>> In article <56e81c01ccLists@Torrens.org>, Richard Torrens (lists)
>> <Lists@Torrens.org> wrote:
>>> This URL
>>> www.siemens-home.bsh-group.com/uk
>>> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>>> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does
>>> do a reset.
>>> Does it happen to anyone else?
>> No, not here. VRPC 4.02.
> Well, it does now!
Not here, 4.02 on VRPC
Best wishes,
Peter (in sunny Valencia!).
--
Peter Young (zfc Ir) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: URL crashes Netsurf
In article <56e87f0c06bbailey@argonet.co.uk>, Brian
<bbailey@argonet.co.uk> wrote:
> In article <56e81c01ccLists@Torrens.org>, Richard Torrens (lists)
> <Lists@Torrens.org> wrote:
> > This URL
> > www.siemens-home.bsh-group.com/uk
> > causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> > The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does
> > do a reset.
> > Does it happen to anyone else?
> No, not here. VRPC 4.02.
Well, it does now!
<bbailey@argonet.co.uk> wrote:
> In article <56e81c01ccLists@Torrens.org>, Richard Torrens (lists)
> <Lists@Torrens.org> wrote:
> > This URL
> > www.siemens-home.bsh-group.com/uk
> > causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> > The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does
> > do a reset.
> > Does it happen to anyone else?
> No, not here. VRPC 4.02.
Well, it does now!
Re: URL crashes Netsurf
In message <56e81c01ccLists@Torrens.org>
"Richard Torrens (lists)" <Lists@Torrens.org> wrote:
>This URL
>
>www.siemens-home.bsh-group.com/uk
>
>causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>
>The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
>reset.
>
>Does it happen to anyone else?
Yes, with NS CI#4320, BBxM, RO 5.23 (02-Apr-18) which IIUC is a release
candidate.
Completely stiffs the machine - no response to Alt-Break, no disc
activity.
Dave
"Richard Torrens (lists)" <Lists@Torrens.org> wrote:
>This URL
>
>www.siemens-home.bsh-group.com/uk
>
>causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>
>The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
>reset.
>
>Does it happen to anyone else?
Yes, with NS CI#4320, BBxM, RO 5.23 (02-Apr-18) which IIUC is a release
candidate.
Completely stiffs the machine - no response to Alt-Break, no disc
activity.
Dave
Re: URL crashes Netsurf
In article <56e81c01ccLists@Torrens.org>,
Richard Torrens (lists) <Lists@Torrens.org> wrote:
> This URL
> www.siemens-home.bsh-group.com/uk
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
> reset.
> Does it happen to anyone else?
No, not here. VRPC 4.02.
Richard Torrens (lists) <Lists@Torrens.org> wrote:
> This URL
> www.siemens-home.bsh-group.com/uk
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
> reset.
> Does it happen to anyone else?
No, not here. VRPC 4.02.
Friday, 13 April 2018
Re: URL crashes Netsurf
David Pitt, on 13 Apr, wrote:
Bug reported :-
http://bugs.netsurf-browser.org/mantis/view.php?id=2593
The thing was not totally reproducible here, the page sometime rendered on
the Titanium. I tried JavaScript and other content blocking on and off
without identifying anything useful.
Please feel free to add to the bug report.
--
David Pitt
Bug reported :-
http://bugs.netsurf-browser.org/mantis/view.php?id=2593
The thing was not totally reproducible here, the page sometime rendered on
the Titanium. I tried JavaScript and other content blocking on and off
without identifying anything useful.
Please feel free to add to the bug report.
--
David Pitt
Re: URL crashes Netsurf
David Pitt, on 13 Apr, wrote:
> There is a log, which can be found after a restart. There is garbage at
> the end of the log!
>
> http://www.pittdj.co.uk/temp/nslog.zip
Oops, I managed to zip the wrong file. Now corrected, the zip does contain
the log now.
Sorry!
--
David Pitt
> There is a log, which can be found after a restart. There is garbage at
> the end of the log!
>
> http://www.pittdj.co.uk/temp/nslog.zip
Oops, I managed to zip the wrong file. Now corrected, the zip does contain
the log now.
Sorry!
--
David Pitt
Re: URL crashes Netsurf
On 13 Apr 2018 David Pitt wrote:
> There is a log, which can be found after a restart. There is garbage at the
> end of the log!
My startup sequence includes running NetSuft which starts a fresh log
file. It would be an improvement if NetSurf saved one previous version
of the log.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> There is a log, which can be found after a restart. There is garbage at the
> end of the log!
My startup sequence includes running NetSuft which starts a fresh log
file. It would be an improvement if NetSurf saved one previous version
of the log.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: URL crashes Netsurf
In message <b42e26e856.John@rickman.argonet..co.uk>
John Rickman <rickman@argonet.co.uk> wrote:
> In message <56e81c01ccLists@Torrens.org>
> "Richard Torrens (lists)" <Lists@Torrens.org> wrote:
>> This URL
>> www.siemens-home.bsh-group.com/uk
>> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>> Does it happen to anyone else?
> Works for me with:
> ARMX6 with 5.23 (18-Feb-18)
> NetSurf 3.8 #4235
Javascript enabled
--
John Rickman
John Rickman <rickman@argonet.co.uk> wrote:
> In message <56e81c01ccLists@Torrens.org>
> "Richard Torrens (lists)" <Lists@Torrens.org> wrote:
>> This URL
>> www.siemens-home.bsh-group.com/uk
>> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>> Does it happen to anyone else?
> Works for me with:
> ARMX6 with 5.23 (18-Feb-18)
> NetSurf 3.8 #4235
Javascript enabled
--
John Rickman
Re: URL crashes Netsurf
In message <56e81c01ccLists@Torrens.org>
"Richard Torrens (lists)" <Lists@Torrens.org> wrote:
> This URL
> www.siemens-home.bsh-group.com/uk
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> Does it happen to anyone else?
Works for me with:
ARMX6 with 5.23 (18-Feb-18)
NetSurf 3.8 #4235
John
--
John Rickman
"Richard Torrens (lists)" <Lists@Torrens.org> wrote:
> This URL
> www.siemens-home.bsh-group.com/uk
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> Does it happen to anyone else?
Works for me with:
ARMX6 with 5.23 (18-Feb-18)
NetSurf 3.8 #4235
John
--
John Rickman
Re: URL crashes Netsurf
"Richard Torrens (lists)", on 13 Apr, wrote:
> This URL
>
> www.siemens-home.bsh-group.com/uk
>
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>
> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
> reset.
>
> Does it happen to anyone else?
It certainly does.
There is a log, which can be found after a restart. There is garbage at the
end of the log!
http://www.pittdj.co.uk/temp/nslog.zip
HTH.
--
David Pitt
> This URL
>
> www.siemens-home.bsh-group.com/uk
>
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
>
> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
> reset.
>
> Does it happen to anyone else?
It certainly does.
There is a log, which can be found after a restart. There is garbage at the
end of the log!
http://www.pittdj.co.uk/temp/nslog.zip
HTH.
--
David Pitt
Re: URL crashes Netsurf
On 13 Apr 2018 Richard Torrens (lists) wrote:
> This URL
> www.siemens-home.bsh-group.com/uk
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
> reset.
> Does it happen to anyone else?
I can get the first page but when I clicked on one of the images
NetSurf aborted with a "serious error" and stiffed the machine.
#4319 RO 5.23
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> This URL
> www.siemens-home.bsh-group.com/uk
> causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
> The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
> reset.
> Does it happen to anyone else?
I can get the first page but when I clicked on one of the images
NetSurf aborted with a "serious error" and stiffed the machine.
#4319 RO 5.23
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: URL crashes Netsurf
On 13/04/18 14:02, Richard Torrens (lists) wrote:
> www.siemens-home.bsh-group.com/uk
>
> causes NetSurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
Works for me with the GTK front end on Linux.
What version of NetSurf are you using, and have you tried the
latest development build?
Cheers,
--
Michael Drake http://www.codethink.co.uk/
> www.siemens-home.bsh-group.com/uk
>
> causes NetSurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
Works for me with the GTK front end on Linux.
What version of NetSurf are you using, and have you tried the
latest development build?
Cheers,
--
Michael Drake http://www.codethink.co.uk/
URL crashes Netsurf
This URL
www.siemens-home.bsh-group.com/uk
causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
reset.
Does it happen to anyone else?
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
www.siemens-home.bsh-group.com/uk
causes Netsurf to totally crash on the ARMX6 with 5.23 (18-Feb-18).
The crash is total, no log file, Alt-Brk does nothing. Ctrl-Brk does do a
reset.
Does it happen to anyone else?
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Thursday, 12 April 2018
Re: [gccsdk] gcc from gccsdk
Hi Theo
Yes, this is what I'm seeing.
The abort (ref google) appears to be due to the absence of some of the builtins referred to at line 54 of pngshim.c
If I rearrange the conditional it'll go past that, then fails around line 110 calling the routine determined by line54 et al .. seems to be looking for a builtin that isn't 'responding'. gcc source suggests the builtin should be there..
This is the patch pngshim.c.p I used to get past the abort .. cludgy I know ..
JB
--- src/sfnt/pngshim.c.orig 2017-09-16 14:01:48.000000000 +0100
+++ src/sfnt/pngshim.c 2018-04-12 21:24:14.397961733 +0100
@@ -61,16 +61,13 @@
/* predates clang; the `__BYTE_ORDER__' preprocessor symbol was */
/* introduced in gcc 4.6 and clang 3.2, respectively. */
/* `__builtin_shuffle' for gcc was introduced in gcc 4.7.0. */
-#if ( ( defined( __GNUC__ ) && \
- ( ( __GNUC__ >= 5 ) || \
- ( ( __GNUC__ == 4 ) && ( __GNUC_MINOR__ >= 7 ) ) ) ) || \
- ( defined( __clang__ ) && \
- ( ( __clang_major__ >= 4 ) || \
- ( ( __clang_major__ == 3 ) && ( __clang_minor__ >= 2 ) ) ) ) ) && \
- defined( __OPTIMIZE__ ) && \
- __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#ifdef __GNUC__
+#if ( ( __GNUC__ >= 5 ) || ( ( __GNUC__ == 4 ) && ( __GNUC_MINOR__ >= 7 ) ) )
+#ifdef __clang__
+#if ( ( __clang_major__ >= 4 ) || ( ( __clang_major__ == 3 ) && ( __clang_minor__ >= 2 ) ) )
+#ifdef __OPTIMIZE__
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
-#ifdef __clang__
/* the clang documentation doesn't cover the two-argument case of */
/* `__builtin_shufflevector'; however, it is is implemented since */
/* version 2.8 */
@@ -78,6 +75,11 @@
#else
#define vector_shuffle __builtin_shuffle
Re: [gccsdk] gcc from gccsdk
On Thu, Apr 12, 2018 at 10:19:38PM +0100, John Ballance wrote:
> Advice appreciated
>
> I have recently built gcc etc on a (more modern) linux machine.
>
> build seems fine
>
> gcc version reports as arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 3)
> 4.7.4
>
> However the __builtin_shuffle built in function appear missing (as needed at
> libfreetype6 src/sfnt/pngshim.c
>
> The package builds fine in jenkins on ci.riscos.info so I have to assume
> something failed or is configured out in my build
The build on ci.riscos.info was 9 months old and didn't work.
I just built it again and it reports:
https://ci.riscos.info/job/packages/job/libfreetype6/10/console
./builds/unix/libtool --mode=compile /home/riscos/env/arm-unknown-riscos-gcc -pedantic -ansi -I/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/autofit -I/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/objs -I./builds/unix -I/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/include -c -Wall -O3 -I/home/riscos/env/include -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DFT_CONFIG_OPTION_USE_BZIP2 -I/usr/include/libpng12 -DFT_CONFIG_OPTION_USE_PNG -DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>" -o /home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/objs/autofit.lo /home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/autofit/autofit.c
In file included from /home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/sfnt/sfnt.c:22:0:
/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/sfnt/pngshim.c: In function 'premultiply_data':
/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/sfnt/pngshim.c:54:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gccsdk.riscos.info/> for instructions.
so something Isn't Happy. But I'm not sure if it's a different kind of Not
Happy from what you're seeing.
The build is picking up some antique dependencies, so I'm rebuilding those
to see if that makes a difference.
I don't think the changes I made recently (supporting a new gperf, allowing
automake to run with a newer perl) will have materially changed things. The
ci.riscos.info build environment at least hasn't changed.
It seems the last successful build in Jenkins was the Debian 'stretch'
package which was libfreetype6 2.6.3, while the current attempt is 'buster's
2.8.1. In the interim the __builtin_shuffle code was introduced.
So I suspect GCC's __builtin_shuffle is indeed broken in some way.
Does anyone know about this code?
There is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378
but that relates to C++.
A workaround is to patch libfreetype6 to avoid the use of __builtin_shuffle.
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
> Advice appreciated
>
> I have recently built gcc etc on a (more modern) linux machine.
>
> build seems fine
>
> gcc version reports as arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 3)
> 4.7.4
>
> However the __builtin_shuffle built in function appear missing (as needed at
> libfreetype6 src/sfnt/pngshim.c
>
> The package builds fine in jenkins on ci.riscos.info so I have to assume
> something failed or is configured out in my build
The build on ci.riscos.info was 9 months old and didn't work.
I just built it again and it reports:
https://ci.riscos.info/job/packages/job/libfreetype6/10/console
./builds/unix/libtool --mode=compile /home/riscos/env/arm-unknown-riscos-gcc -pedantic -ansi -I/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/autofit -I/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/objs -I./builds/unix -I/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/include -c -Wall -O3 -I/home/riscos/env/include -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DFT_CONFIG_OPTION_USE_BZIP2 -I/usr/include/libpng12 -DFT_CONFIG_OPTION_USE_PNG -DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>" -o /home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/objs/autofit.lo /home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/autofit/autofit.c
In file included from /home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/sfnt/sfnt.c:22:0:
/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/sfnt/pngshim.c: In function 'premultiply_data':
/home/jenkins-slave/workspace/packages/libfreetype6/autobuilder/libfreetype6/freetype-2.8.1/src/sfnt/pngshim.c:54:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gccsdk.riscos.info/> for instructions.
so something Isn't Happy. But I'm not sure if it's a different kind of Not
Happy from what you're seeing.
The build is picking up some antique dependencies, so I'm rebuilding those
to see if that makes a difference.
I don't think the changes I made recently (supporting a new gperf, allowing
automake to run with a newer perl) will have materially changed things. The
ci.riscos.info build environment at least hasn't changed.
It seems the last successful build in Jenkins was the Debian 'stretch'
package which was libfreetype6 2.6.3, while the current attempt is 'buster's
2.8.1. In the interim the __builtin_shuffle code was introduced.
So I suspect GCC's __builtin_shuffle is indeed broken in some way.
Does anyone know about this code?
There is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378
but that relates to C++.
A workaround is to patch libfreetype6 to avoid the use of __builtin_shuffle.
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
[gccsdk] gcc from gccsdk
Advice appreciated
I have recently built gcc etc on a (more modern) linux machine.
build seems fine
gcc version reports as arm-unknown-riscos-gcc (GCCSDK GCC 4.7.4 Release 3) 4.7.4
However the __builtin_shuffle built in function appear missing (as needed at libfreetype6 src/sfnt/pngshim.c
The package builds fine in jenkins on ci.riscos.info so I have to assume something failed or is configured out in my build
Any thoughts appreciated
Thanks
John
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] Debugging --- gdb ?
On Wed, Apr 11, 2018 at 07:04:13PM +0200, Michael Grunditz wrote:
> It works!
> http://safir.amigaos.se/bildgalleri/users2/17060_20180411_185547.jpg
Nice :)
Now, if you feel like writing a setvars script we can put it in the
autobuilder...
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
> It works!
> http://safir.amigaos.se/bildgalleri/users2/17060_20180411_185547.jpg
Nice :)
Now, if you feel like writing a setvars script we can put it in the
autobuilder...
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
Wednesday, 11 April 2018
Re: [gccsdk] Debugging --- gdb ?
It works!
http://safir.amigaos.se/bildgalleri/users2/17060_20180411_185547.jpg
On 11 April 2018 at 12:59, Michael Grunditz <michael.grunditz@gmail.com> wrote:
> Hello
>
> I managed to build something (e-uae, the other (better) options failed
> miserably ). But it crash very early.
> http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg
>
> I noticed gdb server being built. Is there a document somewhere that
> describes what client I need?
>
> I am using this little project as a relaxing break form ethernet work
> for my RK3288 port :)
>
> Michael
_______________________________________________
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
http://safir.amigaos.se/bildgalleri/users2/17060_20180411_185547.jpg
On 11 April 2018 at 12:59, Michael Grunditz <michael.grunditz@gmail.com> wrote:
> Hello
>
> I managed to build something (e-uae, the other (better) options failed
> miserably ). But it crash very early.
> http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg
>
> I noticed gdb server being built. Is there a document somewhere that
> describes what client I need?
>
> I am using this little project as a relaxing break form ethernet work
> for my RK3288 port :)
>
> Michael
_______________________________________________
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] Debugging --- gdb ?
On Wed, Apr 11, 2018 at 12:59:11PM +0200, Michael Grunditz wrote:
> Hello
>
> I managed to build something (e-uae, the other (better) options failed
> miserably ). But it crash very early.
> http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg
>
> I noticed gdb server being built. Is there a document somewhere that
> describes what client I need?
I'm not familiar with it, but there's a README in SVN here:
http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Friscos%2Fgdbserver%2FREADME
That suggests a regular Linux gdb will work. I don't know if it needs to be
compiled with ARM support.
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
> Hello
>
> I managed to build something (e-uae, the other (better) options failed
> miserably ). But it crash very early.
> http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg
>
> I noticed gdb server being built. Is there a document somewhere that
> describes what client I need?
I'm not familiar with it, but there's a README in SVN here:
http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Friscos%2Fgdbserver%2FREADME
That suggests a regular Linux gdb will work. I don't know if it needs to be
compiled with ARM support.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
On 11 April 2018 at 00:21, John Ballance <jwb@macpcrepair.co.uk> wrote:
> For what it is worth, in setvars,
>
> AB_URL:http://archive.ubuntu.com/ubuntu/pool/main/libp/libpng/libpng_1.2.54.orig.tar.xz
>
> builds fine
>
> Agreed.. now target of libpng16 sounds a good idea
>
> JB
>
>
> On 10/04/2018 23:08, Ron wrote:
>
> In article <20180410214222.GD23712@chiark.greenend.org.uk>,
> Theo Markettos <theo@markettos.org.uk> wrote:
>
> On Tue, Apr 10, 2018 at 10:35:15AM +0200, Michael Grunditz wrote:
>
> Autobuilder: Using existing Sources.gz (testing/main)
> Autobuilder: Using existing Sources.gz (testing/contrib)
> Autobuilder: Using existing Sources.gz (stable/main)
> Autobuilder: Using existing Sources.gz (stable/contrib)
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> AutoBuilder: Package not found
> Package libpng12-0: ***Failure***
> Build for package "libpng12-0" failed
>
> Where is libpng?
>
> It seems like Debian have moved to libpng16, which is why it's not finding
> any sources. It's in the 'oldstable' distro. You can:
>
> Change autobuilder/fetch-program line:
> distros="testing stable"
> to be:
> distros="testing stable oldstable"
>
> but the longer term solution is to fix up the build for the current Debian
> package which is libpng16-16. This may have implications if what you're
> trying to build will only work with libpng 1.2 not 1.6
>
> Theo
>
> I sent a post to gcc@sdk.riscos ,info last night outlining how to get
> libpng12, but I dont see it showing this morning.
> I changed the default Pluto of replying to the OP and CCing to
> gcc@gccsdk.riscos.info maybe I introduced a typo
>
>
> Anyway continuing on from Theo, wouldn't we now make a new autobuilder
> package called libpng16 and leave the old one until it is no longer needed?
> Using (build unverified) one line
> AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/
> libpng_1.2.50.orig.tar.xz
> would keep it going for a while.
>
I would like to add that freetype 2.8.1 gives me a ICE, but earlier
versions works fine.
Part of SDL ttf dependence
_______________________________________________
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
> For what it is worth, in setvars,
>
> AB_URL:http://archive.ubuntu.com/ubuntu/pool/main/libp/libpng/libpng_1.2.54.orig.tar.xz
>
> builds fine
>
> Agreed.. now target of libpng16 sounds a good idea
>
> JB
>
>
> On 10/04/2018 23:08, Ron wrote:
>
> In article <20180410214222.GD23712@chiark.greenend.org.uk>,
> Theo Markettos <theo@markettos.org.uk> wrote:
>
> On Tue, Apr 10, 2018 at 10:35:15AM +0200, Michael Grunditz wrote:
>
> Autobuilder: Using existing Sources.gz (testing/main)
> Autobuilder: Using existing Sources.gz (testing/contrib)
> Autobuilder: Using existing Sources.gz (stable/main)
> Autobuilder: Using existing Sources.gz (stable/contrib)
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> AutoBuilder: Package not found
> Package libpng12-0: ***Failure***
> Build for package "libpng12-0" failed
>
> Where is libpng?
>
> It seems like Debian have moved to libpng16, which is why it's not finding
> any sources. It's in the 'oldstable' distro. You can:
>
> Change autobuilder/fetch-program line:
> distros="testing stable"
> to be:
> distros="testing stable oldstable"
>
> but the longer term solution is to fix up the build for the current Debian
> package which is libpng16-16. This may have implications if what you're
> trying to build will only work with libpng 1.2 not 1.6
>
> Theo
>
> I sent a post to gcc@sdk.riscos ,info last night outlining how to get
> libpng12, but I dont see it showing this morning.
> I changed the default Pluto of replying to the OP and CCing to
> gcc@gccsdk.riscos.info maybe I introduced a typo
>
>
> Anyway continuing on from Theo, wouldn't we now make a new autobuilder
> package called libpng16 and leave the old one until it is no longer needed?
> Using (build unverified) one line
> AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/
> libpng_1.2.50.orig.tar.xz
> would keep it going for a while.
>
I would like to add that freetype 2.8.1 gives me a ICE, but earlier
versions works fine.
Part of SDL ttf dependence
_______________________________________________
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] Debugging --- gdb ?
Hello
I managed to build something (e-uae, the other (better) options failed
miserably ). But it crash very early.
http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg
I noticed gdb server being built. Is there a document somewhere that
describes what client I need?
I am using this little project as a relaxing break form ethernet work
for my RK3288 port :)
Michael
_______________________________________________
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 managed to build something (e-uae, the other (better) options failed
miserably ). But it crash very early.
http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg
I noticed gdb server being built. Is there a document somewhere that
describes what client I need?
I am using this little project as a relaxing break form ethernet work
for my RK3288 port :)
Michael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Tuesday, 10 April 2018
Re: [gccsdk] gccsdk gcc4 fails to build
For what it is worth, in setvars,
builds fineAB_URL:http://archive.ubuntu.com/ubuntu/pool/main/libp/libpng/libpng_1.2.54.orig.tar.xz
Agreed.. now target of libpng16 sounds a good idea
JB
On 10/04/2018 23:08, Ron wrote:
In article <20180410214222.GD23712@chiark.greenend.org.uk>, Theo Markettos <theo@markettos.org.uk> wrote:On Tue, Apr 10, 2018 at 10:35:15AM +0200, Michael Grunditz wrote:Autobuilder: Using existing Sources.gz (testing/main) Autobuilder: Using existing Sources.gz (testing/contrib) Autobuilder: Using existing Sources.gz (stable/main) Autobuilder: Using existing Sources.gz (stable/contrib) Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz... Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz... Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz... Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz... AutoBuilder: Package not found Package libpng12-0: ***Failure*** Build for package "libpng12-0" failed Where is libpng?It seems like Debian have moved to libpng16, which is why it's not finding any sources. It's in the 'oldstable' distro. You can:Change autobuilder/fetch-program line: distros="testing stable" to be: distros="testing stable oldstable"but the longer term solution is to fix up the build for the current Debian package which is libpng16-16. This may have implications if what you're trying to build will only work with libpng 1.2 not 1.6TheoI sent a post to gcc@sdk.riscos ,info last night outlining how to get libpng12, but I dont see it showing this morning. I changed the default Pluto of replying to the OP and CCing to gcc@gccsdk.riscos.info maybe I introduced a typo Anyway continuing on from Theo, wouldn't we now make a new autobuilder package called libpng16 and leave the old one until it is no longer needed? Using (build unverified) one line AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/ libpng_1.2.50.orig.tar.xz would keep it going for a while. Ron M _______________________________________________ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] gccsdk gcc4 fails to build
In article <20180410214222.GD23712@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:
> On Tue, Apr 10, 2018 at 10:35:15AM +0200, Michael Grunditz wrote:
> > Autobuilder: Using existing Sources.gz (testing/main)
> > Autobuilder: Using existing Sources.gz (testing/contrib)
> > Autobuilder: Using existing Sources.gz (stable/main)
> > Autobuilder: Using existing Sources.gz (stable/contrib)
> > Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> > Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> > Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> > Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> > AutoBuilder: Package not found
> > Package libpng12-0: ***Failure***
> > Build for package "libpng12-0" failed
> >
> > Where is libpng?
> It seems like Debian have moved to libpng16, which is why it's not finding
> any sources. It's in the 'oldstable' distro. You can:
> Change autobuilder/fetch-program line:
> distros="testing stable"
> to be:
> distros="testing stable oldstable"
> but the longer term solution is to fix up the build for the current Debian
> package which is libpng16-16. This may have implications if what you're
> trying to build will only work with libpng 1.2 not 1.6
> Theo
I sent a post to gcc@sdk.riscos ,info last night outlining how to get
libpng12, but I dont see it showing this morning.
I changed the default Pluto of replying to the OP and CCing to
gcc@gccsdk.riscos.info maybe I introduced a typo
Anyway continuing on from Theo, wouldn't we now make a new autobuilder
package called libpng16 and leave the old one until it is no longer needed?
Using (build unverified) one line
AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/
libpng_1.2.50.orig.tar.xz
would keep it going for a while.
Ron M
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <theo@markettos.org.uk> wrote:
> On Tue, Apr 10, 2018 at 10:35:15AM +0200, Michael Grunditz wrote:
> > Autobuilder: Using existing Sources.gz (testing/main)
> > Autobuilder: Using existing Sources.gz (testing/contrib)
> > Autobuilder: Using existing Sources.gz (stable/main)
> > Autobuilder: Using existing Sources.gz (stable/contrib)
> > Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> > Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> > Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> > Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> > AutoBuilder: Package not found
> > Package libpng12-0: ***Failure***
> > Build for package "libpng12-0" failed
> >
> > Where is libpng?
> It seems like Debian have moved to libpng16, which is why it's not finding
> any sources. It's in the 'oldstable' distro. You can:
> Change autobuilder/fetch-program line:
> distros="testing stable"
> to be:
> distros="testing stable oldstable"
> but the longer term solution is to fix up the build for the current Debian
> package which is libpng16-16. This may have implications if what you're
> trying to build will only work with libpng 1.2 not 1.6
> Theo
I sent a post to gcc@sdk.riscos ,info last night outlining how to get
libpng12, but I dont see it showing this morning.
I changed the default Pluto of replying to the OP and CCing to
gcc@gccsdk.riscos.info maybe I introduced a typo
Anyway continuing on from Theo, wouldn't we now make a new autobuilder
package called libpng16 and leave the old one until it is no longer needed?
Using (build unverified) one line
AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/
libpng_1.2.50.orig.tar.xz
would keep it going for a while.
Ron M
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
On Tue, Apr 10, 2018 at 10:35:15AM +0200, Michael Grunditz wrote:
> Autobuilder: Using existing Sources.gz (testing/main)
> Autobuilder: Using existing Sources.gz (testing/contrib)
> Autobuilder: Using existing Sources.gz (stable/main)
> Autobuilder: Using existing Sources.gz (stable/contrib)
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> AutoBuilder: Package not found
> Package libpng12-0: ***Failure***
> Build for package "libpng12-0" failed
>
> Where is libpng?
It seems like Debian have moved to libpng16, which is why it's not finding
any sources. It's in the 'oldstable' distro. You can:
Change autobuilder/fetch-program line:
distros="testing stable"
to be:
distros="testing stable oldstable"
but the longer term solution is to fix up the build for the current Debian
package which is libpng16-16. This may have implications if what you're
trying to build will only work with libpng 1.2 not 1.6
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
> Autobuilder: Using existing Sources.gz (testing/main)
> Autobuilder: Using existing Sources.gz (testing/contrib)
> Autobuilder: Using existing Sources.gz (stable/main)
> Autobuilder: Using existing Sources.gz (stable/contrib)
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> AutoBuilder: Package not found
> Package libpng12-0: ***Failure***
> Build for package "libpng12-0" failed
>
> Where is libpng?
It seems like Debian have moved to libpng16, which is why it's not finding
any sources. It's in the 'oldstable' distro. You can:
Change autobuilder/fetch-program line:
distros="testing stable"
to be:
distros="testing stable oldstable"
but the longer term solution is to fix up the build for the current Debian
package which is libpng16-16. This may have implications if what you're
trying to build will only work with libpng 1.2 not 1.6
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
[gccsdk] setvsrs for LevelDB 1.2 build
autobuilder/db/leveldb setvars to enable LevelDB1.2 to build ...
# LevelDB is a fast key-value storage library written at Google that
# provides an ordered mapping from string keys to string values.
AB_INSTALL=env
export TARGET_OS="RISC_OS"
export PREFIX=$GCCSDK_INSTALL_ENV
install_headers()
{
local src_header_dir
local dst_header_dir
src_header_dir=$1
dst_header_dir=$2
HERE=`pwd`
cd $src_header_dir
mkdir -p $dst_header_dir/h
for f in *
do
if [ -d "$f" ] ; then
install_headers $src_header_dir/$f $dst_header_dir/$f
else
filename=$(basename "$f")
extension="${filename##*.}"
filename="${filename%.*}"
cp -v -T $f $dst_header_dir/h/$filename
fi
done
cd $HERE
}
ab_package() {
ab_create_app leveldb Library libleveldb-dev
install_headers $GCCSDK_INSTALL_ENV/include/leveldb $A
cp $S/out-static/*.a $A
$AB_HOME/add-riscpkg -package "libleveldb-dev" -unixlib -name LibLevelDB-Dev
if [ "$RO_SHAREDLIBS" == "yes" ] ; then
ab_create_sharedlib_skeleton libleveldb
AB_COMPONENTS=""
ab_add_sharedlib $S/out-shared libleveldb.so.1
$AB_HOME/add-riscpkg -package libleveldb -name LibLevelDB -depends SharedLibs \
-section Library
fi
echo ab_package done
}
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] gccsdk gcc4 fails to build
On 10/04/2018 10:36, Ron wrote:
<snip>Is there a reason why the source things brought in by the autoloader no longer yield libpng12? It is an issue here too..
Autobuilder: Using existing Sources.gz (testing/main) Autobuilder: Using existing Sources.gz (testing/contrib) Autobuilder: Using existing Sources.gz (stable/main) Autobuilder: Using existing Sources.gz (stable/contrib) Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz... Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz... Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz... Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz... AutoBuilder: Package not found Package libpng12-0: ***Failure*** Build for package "libpng12-0" failedWhere is libpng?If the standard system is not retreiving for whatever reason, you can put a line like AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz at the top of the setvars file in the respective autobuilder directory. ftp address's also work. I usually search for 'debian source <packagename>' to get staight to a choice of wheezy jessie or sid debian sources. You need the link to <package>.orig.tar.gz or .xz or .bz2 Note that newer version could be incompatible with existing patch files, and you could have to drop back to wheezy or jessie archives. The above libpng directory also has libpng_1.2.49.orig.tar.bz2 if needed. If working on a package you can put a copy of the archive on a local ftp server and get it rapidly everytime. HTH Ron M.
Thanks
JB
_______________________________________________ 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
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
[gccsdk] leveldb fails to build
Hi Theo
The resolution for leveldb not building is to add a lie to the build_detect_platform.p file at autobuilder/libraries/db/leveldb to include port/port_posix_sse.cc as below. In leveldb1.20 this is now needed
JB
--- build_detect_platform.orig 2018-04-09 22:58:02.775136374 +0100
+++ build_detect_platform 2018-04-09 23:32:19.802746920 +0100
@@ -171,6 +171,13 @@
PLATFORM_LIBS="-lpthread"
PORT_FILE=port/port_posix.cc
;;
+ RISC_OS)
+ PLATFORM=OS_RISCOS
+ COMMON_FLAGS="$MEMCMP_FLAG -D_REENTRANT -DOS_LINUX -DOS_RISCOS -DLEVELDB_PLATFORM_POSIX"
+ PORT_FILE=port/port_posix.cc
+ PORT_SSE_FILE=port/port_posix_sse.cc
+ CROSS_COMPILE=true
+ ;;
*)
echo "Unknown platform!" >&2
exit 1
On 09/04/2018 20:29, Theo Markettos wrote:
On Mon, Apr 09, 2018 at 08:18:04PM +0100, John Ballance wrote:Hi Thanks Theo Build confirmed I then tried building QT5, which used to build. Fails at first fence, autoconf v1.11 expected.. I have v1.15 in my distribution. Quick patch to resolve that (apt-get wouldn't seem to let me at 1.11) and past that stageI'm afraid, as you've discovered, that changing OS underneath the autobuilder is not to be undertaken lightly, for all these kinds of reasons. We don't have the manpower to chase moving targets of different platforms (or indeed, fix many of the hundreds of packages to build at all - though the Jenkins setup helps know what the problems are). We're happy to accept patches of course!Attempt to build libraries/db/leveldb not happy. Of course I may have a silly here, but would appreciate a sanity check.. I used to jenkins build gccsdk and otter weekly. Otter has been failing for a while but not as early as this ..Hmm, our Jenkins build from July worked: https://ci.riscos.info/job/packages/job/leveldb/12/ I've just started a new build. Please post questions about packages to the list not to me directly. Alan is mostly looking after them these days and he may have more insights. Theo
--
Stop press! Just announced -
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
Jan 2018: Which? rates us No.1 for satisfied energy customers, and No.1 for Home Phone, Broadband, and mobile
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] gccsdk gcc4 fails to build
In article
<CAAqgp_SLiVcYmDzmi=e7iGJUcr0N4zQ9J+B8F+m1pUV9gF07VQ@mail.gmail.com>,
Michael Grunditz <michael.grunditz@gmail.com> wrote:
> On 10 April 2018 at 00:05, Theo Markettos <theo@markettos.org.uk> wrote:
> > On Mon, Apr 09, 2018 at 11:13:48PM +0200, Michael Grunditz wrote:
> >> If I want to build applications that use SDL, should I build SDL with
> >> autobuilder or manually? I tried building it from source and it
> >> complained that it couldn't find "os.h".
> >
> > Alan probably knows more about this than me, but if you're cross-compiling
> > you can autobuild SDL and it should install into /home/riscos/env (or
> > wherever your GCCSDK tree is) so you can then link your program with it in
> > the normal GCC way (-lSDL).
> >
> > There isn't much to be gained by doing it manually, unless you want to
> > customise for some reason.
> >
> > I think the error about 'os.h' might be because it depends on OSLib (and
> > khronos). The autobuilder will build the prerequisites for you to satisfy
> > those dependencies.
> >
> > Theo
> Autobuilder: Using existing Sources.gz (testing/main)
> Autobuilder: Using existing Sources.gz (testing/contrib)
> Autobuilder: Using existing Sources.gz (stable/main)
> Autobuilder: Using existing Sources.gz (stable/contrib)
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> AutoBuilder: Package not found
> Package libpng12-0: ***Failure***
> Build for package "libpng12-0" failed
> Where is libpng?
If the standard system is not retreiving for whatever reason, you can put a
line like
AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
at the top of the setvars file in the respective autobuilder directory.
ftp address's also work.
I usually search for 'debian source <packagename>' to get staight to a
choice of wheezy jessie or sid debian sources.
You need the link to <package>.orig.tar.gz or .xz or .bz2
Note that newer version could be incompatible with existing patch files,
and you could have to drop back to wheezy or jessie archives.
The above libpng directory also has libpng_1.2.49.orig.tar.bz2 if needed.
If working on a package you can put a copy of the archive on a local ftp
server and get it rapidly everytime.
HTH Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
<CAAqgp_SLiVcYmDzmi=e7iGJUcr0N4zQ9J+B8F+m1pUV9gF07VQ@mail.gmail.com>,
Michael Grunditz <michael.grunditz@gmail.com> wrote:
> On 10 April 2018 at 00:05, Theo Markettos <theo@markettos.org.uk> wrote:
> > On Mon, Apr 09, 2018 at 11:13:48PM +0200, Michael Grunditz wrote:
> >> If I want to build applications that use SDL, should I build SDL with
> >> autobuilder or manually? I tried building it from source and it
> >> complained that it couldn't find "os.h".
> >
> > Alan probably knows more about this than me, but if you're cross-compiling
> > you can autobuild SDL and it should install into /home/riscos/env (or
> > wherever your GCCSDK tree is) so you can then link your program with it in
> > the normal GCC way (-lSDL).
> >
> > There isn't much to be gained by doing it manually, unless you want to
> > customise for some reason.
> >
> > I think the error about 'os.h' might be because it depends on OSLib (and
> > khronos). The autobuilder will build the prerequisites for you to satisfy
> > those dependencies.
> >
> > Theo
> Autobuilder: Using existing Sources.gz (testing/main)
> Autobuilder: Using existing Sources.gz (testing/contrib)
> Autobuilder: Using existing Sources.gz (stable/main)
> Autobuilder: Using existing Sources.gz (stable/contrib)
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
> Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
> AutoBuilder: Package not found
> Package libpng12-0: ***Failure***
> Build for package "libpng12-0" failed
> Where is libpng?
If the standard system is not retreiving for whatever reason, you can put a
line like
AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
at the top of the setvars file in the respective autobuilder directory.
ftp address's also work.
I usually search for 'debian source <packagename>' to get staight to a
choice of wheezy jessie or sid debian sources.
You need the link to <package>.orig.tar.gz or .xz or .bz2
Note that newer version could be incompatible with existing patch files,
and you could have to drop back to wheezy or jessie archives.
The above libpng directory also has libpng_1.2.49.orig.tar.bz2 if needed.
If working on a package you can put a copy of the archive on a local ftp
server and get it rapidly everytime.
HTH Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
On 10 April 2018 at 00:05, Theo Markettos <theo@markettos.org.uk> wrote:
> On Mon, Apr 09, 2018 at 11:13:48PM +0200, Michael Grunditz wrote:
>> If I want to build applications that use SDL, should I build SDL with
>> autobuilder or manually? I tried building it from source and it
>> complained that it couldn't find "os.h".
>
> Alan probably knows more about this than me, but if you're cross-compiling
> you can autobuild SDL and it should install into /home/riscos/env (or
> wherever your GCCSDK tree is) so you can then link your program with it in
> the normal GCC way (-lSDL).
>
> There isn't much to be gained by doing it manually, unless you want to
> customise for some reason.
>
> I think the error about 'os.h' might be because it depends on OSLib (and
> khronos). The autobuilder will build the prerequisites for you to satisfy
> those dependencies.
>
> Theo
Autobuilder: Using existing Sources.gz (testing/main)
Autobuilder: Using existing Sources.gz (testing/contrib)
Autobuilder: Using existing Sources.gz (stable/main)
Autobuilder: Using existing Sources.gz (stable/contrib)
Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
AutoBuilder: Package not found
Package libpng12-0: ***Failure***
Build for package "libpng12-0" failed
Where is libpng?
_______________________________________________
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 Mon, Apr 09, 2018 at 11:13:48PM +0200, Michael Grunditz wrote:
>> If I want to build applications that use SDL, should I build SDL with
>> autobuilder or manually? I tried building it from source and it
>> complained that it couldn't find "os.h".
>
> Alan probably knows more about this than me, but if you're cross-compiling
> you can autobuild SDL and it should install into /home/riscos/env (or
> wherever your GCCSDK tree is) so you can then link your program with it in
> the normal GCC way (-lSDL).
>
> There isn't much to be gained by doing it manually, unless you want to
> customise for some reason.
>
> I think the error about 'os.h' might be because it depends on OSLib (and
> khronos). The autobuilder will build the prerequisites for you to satisfy
> those dependencies.
>
> Theo
Autobuilder: Using existing Sources.gz (testing/main)
Autobuilder: Using existing Sources.gz (testing/contrib)
Autobuilder: Using existing Sources.gz (stable/main)
Autobuilder: Using existing Sources.gz (stable/contrib)
Autobuilder: Searching for libpng12-0 in ../Sources-testing-main.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-testing-contrib.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-stable-main.gz...
Autobuilder: Searching for libpng12-0 in ../Sources-stable-contrib.gz...
AutoBuilder: Package not found
Package libpng12-0: ***Failure***
Build for package "libpng12-0" failed
Where is libpng?
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Monday, 9 April 2018
Re: [gccsdk] gccsdk gcc4 fails to build
On Mon, Apr 09, 2018 at 11:13:48PM +0200, Michael Grunditz wrote:
> If I want to build applications that use SDL, should I build SDL with
> autobuilder or manually? I tried building it from source and it
> complained that it couldn't find "os.h".
Alan probably knows more about this than me, but if you're cross-compiling
you can autobuild SDL and it should install into /home/riscos/env (or
wherever your GCCSDK tree is) so you can then link your program with it in
the normal GCC way (-lSDL).
There isn't much to be gained by doing it manually, unless you want to
customise for some reason.
I think the error about 'os.h' might be because it depends on OSLib (and
khronos). The autobuilder will build the prerequisites for you to satisfy
those dependencies.
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
> If I want to build applications that use SDL, should I build SDL with
> autobuilder or manually? I tried building it from source and it
> complained that it couldn't find "os.h".
Alan probably knows more about this than me, but if you're cross-compiling
you can autobuild SDL and it should install into /home/riscos/env (or
wherever your GCCSDK tree is) so you can then link your program with it in
the normal GCC way (-lSDL).
There isn't much to be gained by doing it manually, unless you want to
customise for some reason.
I think the error about 'os.h' might be because it depends on OSLib (and
khronos). The autobuilder will build the prerequisites for you to satisfy
those dependencies.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
On 9 April 2018 at 21:39, Theo Markettos <theo@markettos.org.uk> wrote:
> On Mon, Apr 09, 2018 at 04:05:12PM +0200, Michael Grunditz wrote:
>> I tried to build with !GCC now and got this:
>>
>> cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
>> make: * [src/arosrom.o] Error 1
>
> I think you're running into Wimpslot limits. You aren't running on a 26 bit
> machine are you?
>
>> Also build log for GCC4 attached..
>
> You seem to be building GCC 4.1.2, which is very old.
> I suggest using GCC 4.7.4 instead.
>
> (I fixed the 'Using GCCSDK' wiki page to make this clearer yesterday.
> 4.7.4 has actually been stable for a long while now)
>
OK: Thanks. I am rebuilding now.
If I want to build applications that use SDL, should I build SDL with
autobuilder or manually? I tried building it from source and it
complained that it couldn't find "os.h".
_______________________________________________
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 Mon, Apr 09, 2018 at 04:05:12PM +0200, Michael Grunditz wrote:
>> I tried to build with !GCC now and got this:
>>
>> cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
>> make: * [src/arosrom.o] Error 1
>
> I think you're running into Wimpslot limits. You aren't running on a 26 bit
> machine are you?
>
>> Also build log for GCC4 attached..
>
> You seem to be building GCC 4.1.2, which is very old.
> I suggest using GCC 4.7.4 instead.
>
> (I fixed the 'Using GCCSDK' wiki page to make this clearer yesterday.
> 4.7.4 has actually been stable for a long while now)
>
OK: Thanks. I am rebuilding now.
If I want to build applications that use SDL, should I build SDL with
autobuilder or manually? I tried building it from source and it
complained that it couldn't find "os.h".
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
On Mon, Apr 09, 2018 at 04:05:12PM +0200, Michael Grunditz wrote:
> I tried to build with !GCC now and got this:
>
> cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
> make: * [src/arosrom.o] Error 1
I think you're running into Wimpslot limits. You aren't running on a 26 bit
machine are you?
> Also build log for GCC4 attached..
You seem to be building GCC 4.1.2, which is very old.
I suggest using GCC 4.7.4 instead.
(I fixed the 'Using GCCSDK' wiki page to make this clearer yesterday.
4.7.4 has actually been stable for a long while now)
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> I tried to build with !GCC now and got this:
>
> cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
> make: * [src/arosrom.o] Error 1
I think you're running into Wimpslot limits. You aren't running on a 26 bit
machine are you?
> Also build log for GCC4 attached..
You seem to be building GCC 4.1.2, which is very old.
I suggest using GCC 4.7.4 instead.
(I fixed the 'Using GCCSDK' wiki page to make this clearer yesterday.
4.7.4 has actually been stable for a long while now)
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
Hi again,
Last email was big .. I am trying on my uni shell acount now. Right
now it builds unixlib so I guess it works.
On 9 April 2018 at 16:05, Michael Grunditz <michael.grunditz@gmail.com> wrote:
> I tried to build with !GCC now and got this:
>
> cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
> make: * [src/arosrom.o] Error 1
>
> Also build log for GCC4 attached..
>
> On 9 April 2018 at 01:36, Michael Grunditz <michael.grunditz@gmail.com> wrote:
>> In message <20180408125106.GM22697@chiark.greenend.org.uk>
>> Theo Markettos <theo@markettos.org.uk> wrote:
>>
>>> On Sat, Apr 07, 2018 at 10:46:08AM +0200, Michael Grunditz wrote:
>>>> xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
>>>> 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
>>>> x86_64 x86_64 GNU/Linux
>>>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
>>
>>> Are you able to send a full log?
>>
>>> Typing 'script <filename>' will log everything you type in a shell to a
>>> file.
>>
>>> I'm upgrading my WSL install to Ubuntu 16.04 to investigate but WSL's disc
>>> I/O is so slow it's going to be a long time.
>>
>>> Theo
>> Thanks
>>
>> I will try it next time I am in windows.
>>
>> I need to fix my linux booter for RISC OS so I can use my ARMX6 for
>> linux tasks as well. I can boot up linux but USB keep failing :/
>>
>> --
>> Michael Grunditz
_______________________________________________
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
Last email was big .. I am trying on my uni shell acount now. Right
now it builds unixlib so I guess it works.
On 9 April 2018 at 16:05, Michael Grunditz <michael.grunditz@gmail.com> wrote:
> I tried to build with !GCC now and got this:
>
> cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
> make: * [src/arosrom.o] Error 1
>
> Also build log for GCC4 attached..
>
> On 9 April 2018 at 01:36, Michael Grunditz <michael.grunditz@gmail.com> wrote:
>> In message <20180408125106.GM22697@chiark.greenend.org.uk>
>> Theo Markettos <theo@markettos.org.uk> wrote:
>>
>>> On Sat, Apr 07, 2018 at 10:46:08AM +0200, Michael Grunditz wrote:
>>>> xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
>>>> 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
>>>> x86_64 x86_64 GNU/Linux
>>>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
>>
>>> Are you able to send a full log?
>>
>>> Typing 'script <filename>' will log everything you type in a shell to a
>>> file.
>>
>>> I'm upgrading my WSL install to Ubuntu 16.04 to investigate but WSL's disc
>>> I/O is so slow it's going to be a long time.
>>
>>> Theo
>> Thanks
>>
>> I will try it next time I am in windows.
>>
>> I need to fix my linux booter for RISC OS so I can use my ARMX6 for
>> linux tasks as well. I can boot up linux but USB keep failing :/
>>
>> --
>> Michael Grunditz
_______________________________________________
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
[Rpcemu] Mauser does not work in RPCEmu pre release test version 0.8.102
I just noticed that my favourite module, Mauser, does not
work properly on RPCEmu. Not sure why I never noticed that
before.
work properly on RPCEmu. Not sure why I never noticed that
before.
I tried with RO5 and RO4 as well as RPCEmu 0.8.102 and 0.8.15.
Neither the "move window when pressing/holding middle mouse
button together with left/right mouse button no matter where
on the window you click" nor the other functions work
(usually activated by pressing right CTRL key together
with a key on the numerical keypad).
I would be eternally grateful if this could be fixed...
Mauser can be downloaded from here:
http://legacy.huber-net.de/iyonix/mauser.zip
(I did not write it, only 32bitted it a long time ago!)
Help for the module is German only, I can provide a
translation if needed for a fix!
Steffen
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] RPCEmu pre release test version 0.8.102 crashes on trying to delete locked directory in HostFS
RPCEmu 0.8.102 (Windows 10) just crashed on me with the
following when trying to delete files on HostFS:
following when trying to delete files on HostFS:
MinGW Runtime Assertion
Assertion failed!
Program: D:\...\RPCEmu-Recompiler.exe
File: ..\hostfs.c, Line 1623
Expression: d
It looks like (for unknown reasons) a directory was marked
as locked in Windows, which lead to this problem.
Steffen
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 8 April 2018
Re: [gccsdk] gccsdk gcc4 fails to build
In message <20180408125106.GM22697@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
> On Sat, Apr 07, 2018 at 10:46:08AM +0200, Michael Grunditz wrote:
>> xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
>> 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
>> x86_64 x86_64 GNU/Linux
>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
> Are you able to send a full log?
> Typing 'script <filename>' will log everything you type in a shell to a
> file.
> I'm upgrading my WSL install to Ubuntu 16.04 to investigate but WSL's disc
> I/O is so slow it's going to be a long time.
> Theo
Thanks
I will try it next time I am in windows.
I need to fix my linux booter for RISC OS so I can use my ARMX6 for
linux tasks as well. I can boot up linux but USB keep failing :/
--
Michael Grunditz
_______________________________________________
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 Sat, Apr 07, 2018 at 10:46:08AM +0200, Michael Grunditz wrote:
>> xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
>> 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
>> x86_64 x86_64 GNU/Linux
>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
> Are you able to send a full log?
> Typing 'script <filename>' will log everything you type in a shell to a
> file.
> I'm upgrading my WSL install to Ubuntu 16.04 to investigate but WSL's disc
> I/O is so slow it's going to be a long time.
> Theo
Thanks
I will try it next time I am in windows.
I need to fix my linux booter for RISC OS so I can use my ARMX6 for
linux tasks as well. I can boot up linux but USB keep failing :/
--
Michael Grunditz
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] gccsdk gcc4 fails to build
On Sat, Apr 07, 2018 at 10:46:08AM +0200, Michael Grunditz wrote:
> xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
> 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
> x86_64 x86_64 GNU/Linux
> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
Are you able to send a full log?
Typing 'script <filename>' will log everything you type in a shell to a
file.
I'm upgrading my WSL install to Ubuntu 16.04 to investigate but WSL's disc
I/O is so slow it's going to be a long time.
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
> xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
> 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
> x86_64 x86_64 GNU/Linux
> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
Are you able to send a full log?
Typing 'script <filename>' will log everything you type in a shell to a
file.
I'm upgrading my WSL install to Ubuntu 16.04 to investigate but WSL's disc
I/O is so slow it's going to be a long time.
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
[gccsdk] Fwd: gccsdk gcc4 fails to build
---------- Forwarded message ----------
From: Michael Grunditz <michael.grunditz@gmail.com>
Date: 7 April 2018 at 10:46
Subject: Re: [gccsdk] gccsdk gcc4 fails to build
To: Theo Markettos <theo@markettos.org.uk>
On 7 April 2018 at 00:30, Theo Markettos <theo@markettos.org.uk> wrote:
> On Fri, Apr 06, 2018 at 11:18:55PM +0100, John Ballance wrote:
>> FWIW it has just failed here.. building in jenkins on ubuntu 17.10 new
>> install
>>
>> tail of log is
>>
>> autoreconf: running: automake --no-force
>> Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/jb/jenkins_gccsdk/gcc4/builddir/installed-buildtools-for-gcc/bin/automake line 4113.
>> autoreconf: automake failed with exit status: 255
>> Makefile:545: recipe for target 'src-gcc-copied' failed
>> make[1]: *** [src-gcc-copied] Error 1
>> make[1]: Leaving directory '/home/jb/jenkins_gccsdk/gcc4'
>> Makefile:255: recipe for target 'getenv' failed
>> make: *** [getenv] Error 2
>>
>> Does this help?
>
> That seems to be a different problem. What version(s) of
> automake/autoconf/aclocal do you have installed?
>
> Forgot to ask: Michael, what OS/distro are you building GCCSDK with?
>
> For reference, I think ci.riscos.info is currently building with Ubuntu
> 14.04.
xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
x86_64 x86_64 GNU/Linux
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
Michael
_______________________________________________
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
From: Michael Grunditz <michael.grunditz@gmail.com>
Date: 7 April 2018 at 10:46
Subject: Re: [gccsdk] gccsdk gcc4 fails to build
To: Theo Markettos <theo@markettos.org.uk>
On 7 April 2018 at 00:30, Theo Markettos <theo@markettos.org.uk> wrote:
> On Fri, Apr 06, 2018 at 11:18:55PM +0100, John Ballance wrote:
>> FWIW it has just failed here.. building in jenkins on ubuntu 17.10 new
>> install
>>
>> tail of log is
>>
>> autoreconf: running: automake --no-force
>> Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/jb/jenkins_gccsdk/gcc4/builddir/installed-buildtools-for-gcc/bin/automake line 4113.
>> autoreconf: automake failed with exit status: 255
>> Makefile:545: recipe for target 'src-gcc-copied' failed
>> make[1]: *** [src-gcc-copied] Error 1
>> make[1]: Leaving directory '/home/jb/jenkins_gccsdk/gcc4'
>> Makefile:255: recipe for target 'getenv' failed
>> make: *** [getenv] Error 2
>>
>> Does this help?
>
> That seems to be a different problem. What version(s) of
> automake/autoconf/aclocal do you have installed?
>
> Forgot to ask: Michael, what OS/distro are you building GCCSDK with?
>
> For reference, I think ci.riscos.info is currently building with Ubuntu
> 14.04.
xenial running in Windows Linux environment : Linux DESKTOP-NTNO7SV
4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64
x86_64 x86_64 GNU/Linux
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
Michael
_______________________________________________
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)