is from
https://www.riscos.info/packages/arm/Network/wget_1.20.3-2_arm.zip
Regards
Duncan Moore
gcc (GCCSDK GCC 4.7.4 Release 6) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISC OS 4.39
RPCEmu 0.9.3 RISC OS 5.24
___
GCCSDK mailing list gcc@gccs
Using --version with the utilities in !GCC.bin reports Release 5, rather
than Release 6.
Regards
Duncan Moore
gcc (GCCSDK GCC 4.7.4 Release 6) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISC OS 4.39
RPCEmu 0.9.3 RISC OS 5.24
___
GCCSDK mailing
tions or see the RISC OS User Guide for ways to
maximise memory.
(Memory cannot be moved)
After this, any ELF commands give the same error message.
Regards
Duncan Moore
gcc (GCCSDK GCC 4.7.4 Release 6) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISC OS 4.39
R
uot;%i\n",!!isspace('\n'));
printf("%i\n",!!space('\n'));
printf("%i\n",!!isblank('\n'));
printf("%i\n",!!blank('\n')); // Fails to link.
return 0;
}
should give:
1
1
0
0
whereas, if the 2 lines with comments are removed, I get:
1
1
1
and it fails to li
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
.$/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 m
I'm unable to access the GCCSDK buglist page
http://www.riscos.info/bugzilla/ .
This is what I get:
Not Found
The requested URL /bugzilla/ was not found on this server.
Apache/2.2.16 (Debian) Server at www.riscos.info Port 80
Has it been moved?
Duncan
On 11/11/2015 12:39, Gavin Wraith wrote:
I need some help. I am getting, after a few minutes
of running a wimp task, an error message
UnixLib detected recursion of signal SIGSEV. Exiting
After which other tasks start complaining. My task
is the Lua interpreter with the code for calling SWIs
On 07/10/2015 18:20, Gavin Wraith wrote:
The crunch line is
TARGET_TESTARCH=$(shell $(TARGET_CC) $(TARGET_TCFLAGS) -E lj_arch.h -dM)
followed by what is in effect a switch statement. The relevant branch,
apparently not taken is
ifneq (,$(findstring LJ_TARGET_ARM ,$(TARGET_TESTARCH)))
On 03/02/2015 16:11, Duncan Moore wrote:
The problem is with 'make'.
This code is in job.c:
#elif defined (__riscos__)
char default_shell[] = ;
int batch_mode_shell = 0;
#else
It's not just in the RISC OS version, but in the GNU make version itself.
If I remove this code (so default_shell
On 01/05/2015 01:52, Ron wrote:
Wimpslot is no help
I'm using 16MB for 4.7.4.
I didn't upgrade unixlib or !SharedLibs stuff from 4.1.2
Is that necessary?
I think unixlib was the same, so it shouldn't need updating.
Yes, you'll need the new !SharedLibs.
If you want gcc 4.1.2 compiled
On 17/03/2015 15:37, Duncan Moore wrote:
On 17/03/2015 13:05, Alex Macfarlane Smith wrote:
On 16/03/2015 03:05, Theo Markettos wrote:
On Mon, Mar 16, 2015 at 03:26:05PM +1300, Ron May wrote:
In article 5505980f.7020...@gmx.com,
Duncan Moore duncan.mo...@gmx.com wrote:
but on RISC OS
If the file qqq contains the single line:
abcdefghijklmnopq
then on Cygwin the following program gives what I would expect:
abcdefghijklmnopq
abcdefghi
abcdEfghijklmnopq
but on RISC OS gcc 4.7.4, VirtualRPC-Adjust RISCOS 4.39, ARM 710, the
last output line is wrong:
abcdefghijklmnopq
On 06/02/2015 07:34, WPB wrote:
I'm currently hitting an error when creating the dependencies file:
Fatal error: bits/c++config.h: No such file or directory
And it's true, when I look inside !GCC in include.c++.4/7/4.bits.h, I can
see no such file. There's c++0x_warning, but that's the
On 03/02/2015 22:00, WPB wrote:
On Tue, 03 Feb 2015 16:11:23 -, Duncan Mooreduncan.mo...@gmx.com
wrote:
On 31/01/2015 16:15, Duncan Moore wrote:
The problem is with 'make'.
This code is in job.c:
#elif defined (__riscos__)
char default_shell[] = ;
int batch_mode_shell = 0;
#else
On 02/02/2015 13:26, Theo Markettos wrote:
On Mon, Feb 02, 2015 at 11:29:24AM +, Duncan Moore wrote:
Yes, I think it is a bug. This page describes how to report bugs:
http://www.riscos.info/index.php/Bug_Reporting
Reporting the bug doesn't always mean there is someone at the other end
On 31/01/2015 16:15, Duncan Moore wrote:
On 31/01/2015 13:11, Duncan Moore wrote:
As to why \n is causing problems, I'm not sure. It looks like some weird
interaction between 'make' and 'printf'.
I'm wondering if it's due to 'make' calling exec() and then the argument
list being manipulated
On 02/02/2015 14:21, Ron wrote:
I've been able to replicate this now by putting the coreutils printf in
the path for the CLI to find.
Firstly, there is an error in the printf binary where it objects to a \
Are you sure the error is in the printf binary?
in the string and results in 'File
On 31/01/2015 16:31, WPB wrote:
CC = g++ FC = g++ PC = g++ CXX = g++So the command should at least
produce a different error to File -c not found. But the result of
make was exactly the same as before.
The -c is coming from the shell. Try this:
*set UnixEnv$.SHELLFLAGS
*make
printf
On 01/02/2015 13:02, WPB wrote:
On Sun, 01 Feb 2015 09:38:56 -, Duncan Moore duncan.mo...@gmx.com
wrote:
On 31/01/2015 16:31, WPB wrote:
CC = g++ FC = g++ PC = g++ CXX = g++So the command should at least
produce a different error to File -c not found. But the result of
make was exactly
-riscos/bits/os_defines.h
\
etc., etc.
You could try using my 'make' port
http://homepage.ntlworld.com/duncan-moore/riscos/zip/make-3-81-ro1.zip.
I always use these dependency files myself, and have tweaked 'make' to
handle these sorts of things more easily on RISC OS. The diff file
contains
On 31/01/2015 13:11, Duncan Moore wrote:
As to why \n is causing problems, I'm not sure. It looks like some weird
interaction between 'make' and 'printf'.
I'm wondering if it's due to 'make' calling exec() and then the argument
list being manipulated. I seem to recall that it quotes both
On 30/01/2015 14:13, WPB wrote:
With this very simple test case of a Makefile:
dir :
printf Making dir...\n
mkdir OBJECTS
You need the executable file 'printf' in your run path - check that it is.
The trouble then is with the \n. I could get it to work by just removing
On 22/03/2014 20:16, Bob Brand wrote:
Hello Duncan,
In message bug-250...@http.www.riscos.info/bugzilla3/ you wrote:
printf(%f\n,sqrt(2.0));
Looks like you have fallen in a classic C pitfall:
passing a double argument to a vararg/stdarg function
but interpreting it as float.
No, %f is
GCCSDK GCC 4.7.4 Release 1 Development 4.7.4 2014-01-08
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39
The execute permission bit for Text files has changed to be the same as
for other filetypes. So the
On 08/03/2014 17:33, John Tytgat wrote:
In message mpro.n24muc00igub60...@wingsandbeaks.org.uk.invalid
Jeremy Nicoll - ml roinfo jn.ml.roi...@wingsandbeaks.org.uk wrote:
John Tytgat john.tyt...@aaug.net wrote:
I think it would be better to derive this from RISC OS filetype, i.e.
On 05/03/2014 12:14, Lee Noar wrote:
On 04/03/14 11:51, Duncan Moore wrote:
On 03/03/2014 20:39, Lee Noar wrote:
The loop control instructions are missing as well as the function
epilogue; the compiler knew it was creating an infinite loop.
I assume you built the compiler yourself on the 8th
On 03/03/2014 20:39, Lee Noar wrote:
The loop control instructions are missing as well as the function
epilogue; the compiler knew it was creating an infinite loop.
I assume you built the compiler yourself on the 8th January?
No. I'm using
On 18/09/2012 08:21, Antoni Sawicki wrote:
I'm new to the list and RiscOS in general. I have a quick question. I
Welcome.
*gcc hello/c
hello/c: file not recognized: file format not recognized
collect2: ld returned 1 exit status
Have a look at the Examples directory that came with !GCC, for
Peter Naulls wrote:
Duncan Moore wrote:
I was expecting/hoping that both files would be filetyped as Pdf. The
reason is that if I write a program that I want to use Unix format
filenames, I unset __RISCOSIFY_NO_PROCESS and I get automatic
filetyping of newly created files. On the other hand
I've only recieved one email from the gcc list since 26th December.
The archive indicates that I should have recieved quite a few.
(My other emails seem to be unaffected.)
Is there a reason for this?
Duncan Moore
___
GCCSDK mailing list gcc
is from this new 'cat' command.
3) Load SharedUnixLib 1.10, and the output is as in 1) again.
Regards
Duncan Moore
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info
32 matches
Mail list logo
