Re: [gccsdk] An oddity

2018-04-15 Thread John Ballance
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

Re: [gccsdk] An oddity

2018-04-15 Thread Theo Markettos
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).

[gccsdk] An oddity

2018-04-15 Thread John Ballance
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

[gccsdk] Wimpslot oddity

2018-01-26 Thread Ron
I have a working port of telegram-cli, but compiling with either 4/1/2 or 4/7/4 and when the static binary runs, it doesn't complain about the wimpslot, but helps itself to 206112000 bytes. I have never seen a (largish) binary work without a wimpslot specified before. I noticed the wimpslot for