[Rpcemu] Problematic SoundDMA buffers rate/size combination

Hi,

While experimenting with KinoAmp on RpcEmu (latest Windows version) I noticed that sound was to slow
and because sound and video where synchronized the video was played at half rate. This was curious
as an error sound before KinoAmp was fine and playing DigitalCD was fine too. It's actually a given
sample rate & buffer size combination which causes the problem due I think to the fact that more
than 100 buffers need to be filled per second.

My experiments shows:
28333Hz, 208 samples per buffer -> OK
44100Hz, 208 samples per buffer -> Problem
44100Hz, 512 samples per buffer -> OK

Kind Regards,
André Timmermans



This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, Atos' liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Belgium N.V./S.A. supplies goods and/or services of whatever nature, the General Terms and Conditions from Atos Belgium N.V./S.A . exclusively apply. The General Terms and Conditions shall be promptly submitted to you on your request.

Atos Belgium N.V/S.A
Da Vincilaan 5
B-1930 Zaventem
RPR-RPM Brussels
BTW/TVA: BE 0401 848 135
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] GCC version

In message <20151130191142.GB17806@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:

> On Mon, Nov 30, 2015 at 04:28:49PM +0000, Gavin Wraith wrote:
> > When I do
> > *gcc --version
> > I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4" .
> > But when I do
> > *show GCC$Version
> > I get "GCC$Version : 4.7.4 Release 1".
> > I think my !GCC.!Boot, which sets GCC$Version, is either too old
> > or wrong. Does anybody else have this?
>
> That's my fault for not knowing about that setting when I did the version
> bump.
>
> Does anything use GCC$Version?
>
> Theo
>

I guess I could of used it to improve on (the manual setting requirement of)

| !Run file for Cproto
If "<GCC$Dir>" = "" Then error gcc must be seen (filer_booted) first
RMEnsure SharedUnixLibrary 1.12 RMLoad SharedUnixLibrary
| for gcc 3
|TaskWindow "gcc --version" -Wimpslot 6000K -name Cproto

| for gcc 4.1.2
|TaskWindow "gcc --version" -Wimpslot 8000K -name Cproto

| for gcc 4.7.4
TaskWindow "gcc --version" -Wimpslot 15000K -name Cproto

p.s. I think 15000K is insufficient for g++ work, as mentioned earlier

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] [Bug 240] fork() & prog$heap failure

In message <E1a2IBw-0001Bb-V5@riscos.info>
bugzilla-daemon@riscos.info wrote:

> http://www.riscos.info/bugzilla3/show_bug.cgi?id=240
>
> Duncan Moore <duncan.moore@gmx.com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |duncan.moore@gmx.com
>
> --- Comment #1 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 04:31:56 PST ---
> Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.
> However, I've since noticed that !GCC.docs.libunixlib.README specifically says
> that fork() and *$heap does not work:
> "If the program calls fork() then it has to use the wimpslot."
> So this is probably not a bug as such, and can be removed.
>

I don't know what relationship the heap has to tasks, but -
I noticed once that fork() will only work if the window manager is running,
this sort of implied (to me) that it is using the RISC OS task manager, for
a child process. I think this may be reflected by the RISC OS task id's returned
rather than unix style.
I'm guessing the alternative would be a replacement (or ported) task manager
from a unix source to simulate the unix system.
There is a lot of low level unix compatibility stuff I dont know, it's
almost as if I'm missing a book on the subject.
Possibily my lack of programming experience in native RISC OS/wimp doesn't help.
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

Issue 2339 (case sensitivity has no effect)

I've come up with a solution that I think may be good enough. I'd
welcome a review and any suggestions for better ways.

The result of this change is that toggling case sensitivity has an
immediate effect, although it also resets the search to the start
of the list of targets. Since the list may well have changed, I
guess that's an OK consequence.

I also have some questions:

1) Are the first two additions necessary or desirable?

2) Do other platforms have the same problem?

Dave

diff --git a/riscos/search.c b/riscos/search.c
index 60b3716..f914b5c 100644
--- a/riscos/search.c
+++ b/riscos/search.c
@@ -173,6 +173,12 @@ bool ro_gui_search_click(wimp_pointer *pointer)
case ICON_SEARCH_CASE_SENSITIVE:
flags = SEARCH_FLAG_FORWARDS |
ro_gui_search_update_flags();
+ ro_gui_search_set_forward_state(true,
+ search_data.search_window);
+ ro_gui_search_set_back_state(true,
+ search_data.search_window);
+ browser_window_search_clear(
+ search_data.search_window);
browser_window_search(search_data.search_window, NULL,
flags,
ro_gui_get_icon_string(dialog_search,

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager

Re: [gccsdk] GCC 4.7.4 errors

On 30/11/15 20:01, alan buckley wrote:
> Lee Noar wrote on Mon, 30 Nov 2015 17:32:31 +0000
> > Subject: Re: [gccsdk] GCC 4.7.4 errors
> >

[snip]

> > It's more a case of how does make decide which compiler to use.
> > Normally, it's the source file suffix that determines it, so
> > file.c would cause make to invoke the rule for .c files which
> > would call the C compiler (gcc) and file.cpp would invoke the rule
> > for .cpp files which would call the C++ compiler (g++).
> >
> > It sounds like the project _is_ pure C and should be compiled
> > as pure C, but for some reason the C++ compiler is incorrectly
> > being called for one or more files.
> >
> > If you can zip up the project and email it to me, I'll have
> > a look and see if I can spot what's going wrong.
> >
> I don't know if it is relevant on RISC OS, but on linux I have
> occasionally had a problem where if the suffix was a capital
> c (i.e. file.C) it would compile it as c++.

That's a good point that I hadn't thought of, but I've now tried
the project that Gavin sent me, and the files are in a 'c' directory
rather than a 'C' one. It builds correctly for me on my RPi, so perhaps
Gavin has a fault in his installation somewhere.

Thanks,
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

Re: [gccsdk] GCC version

Theo Markettos, on 30 Nov, wrote:

> On Mon, Nov 30, 2015 at 04:28:49PM +0000, Gavin Wraith wrote:
> > When I do *gcc --version I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4"
> > . But when I do *show GCC$Version I get "GCC$Version : 4.7.4 Release 1".
> > I think my !GCC.!Boot, which sets GCC$Version, is either too old or
> > wrong. Does anybody else have this?
>
> That's my fault for not knowing about that setting when I did the version
> bump.
>
> Does anything use GCC$Version?

Not in any substantial way but see HelpScan Lite at :-
http://www.snowstone.org.uk/riscos/index.html

Isn't it part of Castle's "Application System Variables"?
http://www.iyonix.com/32bit/help.shtml
I don't know whether that is still policy under ROOL having failed to find
any recent mention of it.

--
David Pitt

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

Re: [gccsdk] GCC 4.7.4 errors

Lee Noar wrote on Mon, 30 Nov 2015 17:32:31 +0000
> Subject: Re: [gccsdk] GCC 4.7.4 errors
>
> On 30/11/15 16:19, Gavin Wraith wrote:
> > In message <565C58D2.4020703@sky.com>
> > Lee Noar <leenoar@sky.com> wrote:
> >
> >> The above symbols relate to C++ exceptions and are provided by
> >> libstdc++. If you link with g++, then these should be resolved.
> >
> >> That's all C++ stuff, are you sure they haven't switched to C++?
> >> Or is it still using g++ to compile lapi.c when it should be
> >> using gcc? Did you figure that one out?
> >
> > No.
> >
> > I don't know why GCC thinks it is encountering C++. I wanted
> > it to compile as C. I was surprised to see those output lines
> > beginning with g++ and not gcc. As far as I can see the sources
> > v5.3.1 (which compiled successfully as C) and v5.3.2 are
> > just pure C. Because it keeps compiling with g++ and not
> > gcc I wonder if there may be some system variable that
> > sets the choice? I cannot see what in the sources should
> > be responsible - there is nothing in the diff5.3.2-5.3.1
> > file to suggest such a change.
> >
> > How does GCC decide which compiler to use?
>
> It's more a case of how does make decide which compiler to use.
> Normally, it's the source file suffix that determines it, so
> file.c would cause make to invoke the rule for .c files which
> would call the C compiler (gcc) and file.cpp would invoke the rule
> for .cpp files which would call the C++ compiler (g++).
>
> It sounds like the project _is_ pure C and should be compiled
> as pure C, but for some reason the C++ compiler is incorrectly
> being called for one or more files.
>
> If you can zip up the project and email it to me, I'll have
> a look and see if I can spot what's going wrong.
>
I don't know if it is relevant on RISC OS, but on linux I have

occasionally had a problem where if the suffix was a capital

c (i.e. file.C) it would compile it as c++.

Regards,

Alan

Re: [gccsdk] GCC version

On Mon, Nov 30, 2015 at 04:28:49PM +0000, Gavin Wraith wrote:
> When I do
> *gcc --version
> I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4" .
> But when I do
> *show GCC$Version
> I get "GCC$Version : 4.7.4 Release 1".
> I think my !GCC.!Boot, which sets GCC$Version, is either too old
> or wrong. Does anybody else have this?

That's my fault for not knowing about that setting when I did the version
bump.

Does anything use GCC$Version?

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] GCC version

Gavin Wraith, on 30 Nov, wrote:

> When I do *gcc --version
> I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4" .
> But when I do
> *show GCC$Version
> I get "GCC$Version : 4.7.4 Release 1".
> I think my !GCC.!Boot, which sets GCC$Version, is either too old or wrong.
> Does anybody else have this?

Yes, !GCC.!Boot is in error.

--
David Pitt

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

Re: [gccsdk] GCC 4.7.4 errors

On 30/11/15 16:19, Gavin Wraith wrote:
> In message <565C58D2.4020703@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> The above symbols relate to C++ exceptions and are provided by
>> libstdc++. If you link with g++, then these should be resolved.
>
>> That's all C++ stuff, are you sure they haven't switched to C++?
>> Or is it still using g++ to compile lapi.c when it should be
>> using gcc? Did you figure that one out?
>
> No.
>
> I don't know why GCC thinks it is encountering C++. I wanted
> it to compile as C. I was surprised to see those output lines
> beginning with g++ and not gcc. As far as I can see the sources
> v5.3.1 (which compiled successfully as C) and v5.3.2 are
> just pure C. Because it keeps compiling with g++ and not
> gcc I wonder if there may be some system variable that
> sets the choice? I cannot see what in the sources should
> be responsible - there is nothing in the diff5.3.2-5.3.1
> file to suggest such a change.
>
> How does GCC decide which compiler to use?

It's more a case of how does make decide which compiler to use.
Normally, it's the source file suffix that determines it, so
file.c would cause make to invoke the rule for .c files which
would call the C compiler (gcc) and file.cpp would invoke the rule
for .cpp files which would call the C++ compiler (g++).

It sounds like the project _is_ pure C and should be compiled
as pure C, but for some reason the C++ compiler is incorrectly
being called for one or more files.

If you can zip up the project and email it to me, I'll have
a look and see if I can spot what's going wrong.

Lee.


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

[gccsdk] GCC version

When I do
*gcc --version
I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4" .
But when I do
*show GCC$Version
I get "GCC$Version : 4.7.4 Release 1".
I think my !GCC.!Boot, which sets GCC$Version, is either too old
or wrong. Does anybody else have this?
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

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

Re: [gccsdk] GCC 4.7.4 errors

In message <565C58D2.4020703@sky.com>
Lee Noar <leenoar@sky.com> wrote:

>The above symbols relate to C++ exceptions and are provided by
>libstdc++. If you link with g++, then these should be resolved.

>That's all C++ stuff, are you sure they haven't switched to C++?
>Or is it still using g++ to compile lapi.c when it should be
>using gcc? Did you figure that one out?

No.

I don't know why GCC thinks it is encountering C++. I wanted
it to compile as C. I was surprised to see those output lines
beginning with g++ and not gcc. As far as I can see the sources
v5.3.1 (which compiled successfully as C) and v5.3.2 are
just pure C. Because it keeps compiling with g++ and not
gcc I wonder if there may be some system variable that
sets the choice? I cannot see what in the sources should
be responsible - there is nothing in the diff5.3.2-5.3.1
file to suggest such a change.

How does GCC decide which compiler to use?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

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

Re: [gccsdk] GCC 4.7.4 errors

On 29/11/15 20:59, Gavin Wraith wrote:
> I tried compiling Lua with static linking of UnixLib. The linker threw
> this error:
>
> gcc -o lua6 -O2 -Wall -Wextra -mfpu=vfp -static -mtune=cortex-a7 -DRISCOS lua.o -Wl,-E liblua
> liblua(ldo.o): In function `luaD_throw(lua_State*, int)':
> ldo.c:(.text+0x104): undefined reference to `__cxa_allocate_exception'
> ldo.c:(.text+0x118): undefined reference to `__cxa_throw'
> liblua(ldo.o): In function `luaD_rawrunprotected(lua_State*, void (*)(lua_State*, void*), void*)':
> ldo.c:(.text+0x388): undefined reference to `__cxa_begin_catch'
> ldo.c:(.text+0x39c): undefined reference to `__cxa_end_catch'
> liblua(ldo.o):(.ARM.extab+0x30): undefined reference to `__gxx_personality_v0'
> liblua(ldo.o):(.rodata._ZTIP11lua_longjmp[typeinfo for lua_longjmp*]+0x0): undefined reference to `vtable for __cxxabiv1::__pointer_type_info'
> liblua(ldo.o):(.rodata._ZTI11lua_longjmp[typeinfo for lua_longjmp]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
> liblua(loadlib.o): In function `lookforfunc(lua_State*, char const*, char const*)':

The above symbols relate to C++ exceptions and are provided by
libstdc++. If you link with g++, then these should be resolved.


> loadlib.c:(.text+0x5d4): undefined reference to `dlsym'
> loadlib.c:(.text+0x608): undefined reference to `dlerror'
> loadlib.c:(.text+0x638): undefined reference to `dlopen'
> loadlib.c:(.text+0x6b4): undefined reference to `dlerror'
> liblua(loadlib.o): In function `gctm(lua_State*)':
> loadlib.c:(.text+0x8cc): undefined reference to `dlclose'
> collect2: error: ld returned 1 exit status
> makefile:67: recipe for target 'lua6' failed
> make: *** [lua6] Error 1

These are provided by libdl.

> The ldo.c errors seem to be related to the use of longjmp. The loadlib.c errors
> seem to imply that the linker cannot find !GCC.arm-unknown-riscos.include.h.dlfcn .

That's a compiler include file which the linker doesn't use; you
need -ldl when linking.

> Is it not possible to have dynamic loading with a statically linked UnixLib?

No, there is a static libdl for convenience, but it is a dummy library,
and the functions are NOOPs.
Imagine a binary statically linked to UnixLib which loads a library
at runtime that is dynamically linked to shared UnixLib. Hpw do you
resolve the two UnixLibs so that they are one? Bearing in mind that
the static one has already been resolved at build time and contains
no symbol data.

> Compiling without the -static flag I still get the ldo.c errors, as above.

You have a missing -ldl, but as I say, it's a dummy library that does
nothing useful.

> The source file ldo.c has changed in the update from v5.3.1 to v5.3.2
> but there is no non-ANSI C stuff in it. Is there some library that I have
> omitted from the makefile? v5.3.1 compiled without complaint, but now I
> am stuck. What is all this __cxa and vtable stuff?

That's all C++ stuff, are you sure they haven't switched to C++?
Or is it still using g++ to compile lapi.c when it should be
using gcc? Did you figure that one out?

Lee.


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

[gccsdk] Autobuilder library packaging

Can someone explain the difference between the three library packaging
streams? I've been trying to work out what's happening with DeskLib, and
I'm a bit confused.

There are three archives made:
autobuilder_libraries/desklib_svn_...tar
autobuilder_libraries/desklib_svn_...zip
autobuilder_packages/Library/desklib_svn...zip

I had assumed that autobuilder_packages/.../*.zip was for publication of RISC OS
builds that are destined for PackMan installation - ie should be RISC OS
applications containing files suitable for use by a compiler on RISC OS, ie
suffix swapping (h/foo).

I'd assumed that autobuilder_libraries was for downstream consumption by the
autobuilder - ie you can untar autobuilder_libraries/*.tar in your
GCCSDK_INSTALL_ENV to allow the cross compiler to use that library.

It seems that autobuilder_libraries/*.zip are getting suffix swapped, but
autobuilder_packages/**/*.zip are not. But autobuilder_libraries/*.zip are
not being packaged, they're just collections of header and library files.
So if users install the autobuilder_packages/**/*.zip then they have files
in RISC OS called include.foo/h which GCC won't find.

I can understand the need for two library packages, but three?
http://www.riscos.info/index.php/Autobuilder_development
just says 'Libraries: to be added'

Where is the right place to put suffix swapping so that combinations work
out? The Desklib setvars just says:

ab_package() {

ab_create_app DeskLib Apps/Library desklib

rsync -av --exclude='*/.svn*' ../\!DLUser $A/..
rsync -av --exclude='*/.svn*' ../\!DeskLib $A/..
rsync -av --exclude='*/.svn*' ../Examples $A/../\!DeskLib

$AB_HOME/add-riscpkg -name DeskLib -unixlib
}

Which looks pretty uncontroversial to me. I haven't looked at RISC OS
packages of other libraries, but imagine they're similarly affected.

I can figure some things out from the code, but was wondering what the
philosophy was supposed to be, so I don't end up breaking other things.

Thanks
Theo

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

Issue 2339 (case sensitivity has no effect)

I've just done some experiments which, I think, get us closer to
understanding the problem.

I've uploaded a new version of the test file "index.html" which now
puts the words onto separate lines, so that "Show all" shows better
the matching targets.

Search for "Ca", set "Show all" and toggle case sensitivity. The
highlights don't change. Make a change to the search target string,
though, and the matches are immediately updated.

I changed the code in ro_gui_search_click() so as to search for " "
immediately before searching for the real target. Now the highlights
are updated immediately the case sensitivity is toggled.

This suggests to me that the search term is being cached, and the
search command does nothing if the search term does not change. But
it /must/ search again if the flags are changed.

I can't see where the ultimate function is because it's called
"search(...)" which is too generic a name to search for.

I've updated Mantis with my findings.

Hth,

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

[gccsdk] GCC 4.7.4 errors

I tried compiling Lua with static linking of UnixLib. The linker threw
this error:

gcc -o lua6 -O2 -Wall -Wextra -mfpu=vfp -static -mtune=cortex-a7 -DRISCOS lua.o -Wl,-E liblua
liblua(ldo.o): In function `luaD_throw(lua_State*, int)':
ldo.c:(.text+0x104): undefined reference to `__cxa_allocate_exception'
ldo.c:(.text+0x118): undefined reference to `__cxa_throw'
liblua(ldo.o): In function `luaD_rawrunprotected(lua_State*, void (*)(lua_State*, void*), void*)':
ldo.c:(.text+0x388): undefined reference to `__cxa_begin_catch'
ldo.c:(.text+0x39c): undefined reference to `__cxa_end_catch'
liblua(ldo.o):(.ARM.extab+0x30): undefined reference to `__gxx_personality_v0'
liblua(ldo.o):(.rodata._ZTIP11lua_longjmp[typeinfo for lua_longjmp*]+0x0): undefined reference to `vtable for __cxxabiv1::__pointer_type_info'
liblua(ldo.o):(.rodata._ZTI11lua_longjmp[typeinfo for lua_longjmp]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
liblua(loadlib.o): In function `lookforfunc(lua_State*, char const*, char const*)':
loadlib.c:(.text+0x5d4): undefined reference to `dlsym'
loadlib.c:(.text+0x608): undefined reference to `dlerror'
loadlib.c:(.text+0x638): undefined reference to `dlopen'
loadlib.c:(.text+0x6b4): undefined reference to `dlerror'
liblua(loadlib.o): In function `gctm(lua_State*)':
loadlib.c:(.text+0x8cc): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
makefile:67: recipe for target 'lua6' failed
make: *** [lua6] Error 1

The ldo.c errors seem to be related to the use of longjmp. The loadlib.c errors
seem to imply that the linker cannot find !GCC.arm-unknown-riscos.include.h.dlfcn .

Is it not possible to have dynamic loading with a statically linked UnixLib?

Compiling without the -static flag I still get the ldo.c errors, as above.
The source file ldo.c has changed in the update from v5.3.1 to v5.3.2
but there is no non-ANSI C stuff in it. Is there some library that I have
omitted from the makefile? v5.3.1 compiled without complaint, but now I
am stuck. What is all this __cxa and vtable stuff?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

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

Re: Slightly odd behaviour #3225

In article
<OUT-56584FD6.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>, Chris
Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Thu, 26 Nov 2015 08:08:31 +0000 (GMT), Brian wrote:

> > Double clicking on an HTML icon now only loads NetSurf. A further
> > double click is now needed to load the HTML file. Previously, a single
> > double click on the file icon was all that was needed to load the file
> > into NerSurf.

> This was my fault, sorry, should now be fixed.

Ah, well done. Thanks.

I was beginning to think that I was having a brain storm or something.
Though it wouldn't have been much of a storm at my age. 8-)

Brian

[gccsdk] [Bug 255] GCC 4.7.4 Rel 1 Dev 2014-05-29: infinite loop with level 2 optimisation

http://www.riscos.info/bugzilla3/show_bug.cgi?id=255

--- Comment #2 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 05:04:58 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 253] GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget() failure

http://www.riscos.info/bugzilla3/show_bug.cgi?id=253

--- Comment #3 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 04:55:47 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 250] GCC 4.7.4 Rel 1 Dev 2014-01-08: sqrt function

http://www.riscos.info/bugzilla3/show_bug.cgi?id=250

--- Comment #10 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 04:47:49 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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: Slightly odd behaviour #3225

On Thu, 26 Nov 2015 08:08:31 +0000 (GMT), Brian wrote:

> Double clicking on an HTML icon now only loads NetSurf. A further double
> click is now needed to load the HTML file. Previously, a single double
> click on the file icon was all that was needed to load the file into
> NerSurf.

This was my fault, sorry, should now be fixed.

Chris

Re: netsurf: branch master updated. release/3.3-531-gd7907bf

On Fri, 27 Nov 2015 11:15:44 +0000, Daniel Silverstone wrote:

> This seems odd Chris.
>
> Instead of stopping consumption of arguments on the first non-configuration
> argument, it instead ends up swallowing the entire commandline rendering the
> rest of commandline processing worthless.
>
> Could you either fix this so that you get your desired behaviour while not
> breaking processing for the rest of us; or else revert the change?

I've reverted and fixed my problem a different way. The issue I was
having was the commandline processing was stopping on encountering -v,
so it was impossible to specify commandline options with logging
enabled, which seemed ridiculous. I hadn't appreciated that there was
such strict ordering for arguments, and code further down meant they
were now being obliterated. My apologies.

Chris

[gccsdk] [Bug 240] fork() & prog$heap failure

http://www.riscos.info/bugzilla3/show_bug.cgi?id=240

Duncan Moore <duncan.moore@gmx.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |duncan.moore@gmx.com

--- Comment #1 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 04:31:56 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.
However, I've since noticed that !GCC.docs.libunixlib.README specifically says
that fork() and *$heap does not work:
"If the program calls fork() then it has to use the wimpslot."
So this is probably not a bug as such, and can be removed.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 237] Ampersands in command line arguments.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=237

Duncan Moore <duncan.moore@gmx.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |duncan.moore@gmx.com

--- Comment #1 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 04:17:29 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 236] GCC 4.1.2 Rel 2 Dev 2012-05-01: fork/execvp/dup2 redirection problem

http://www.riscos.info/bugzilla3/show_bug.cgi?id=236

Duncan Moore <duncan.moore@gmx.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |duncan.moore@gmx.com

--- Comment #3 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 04:04:35 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 235] GCC 4.1.2 Rel 2 Dev 2012-05-01: Problem reading Archive image files.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=235

Duncan Moore <duncan.moore@gmx.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |duncan.moore@gmx.com

--- Comment #8 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 03:51:55 PST ---
I use !SparkFS now rather than !ArcFS. I've had no problems with !SparkFS, and
the test case works properly with it.

With !ArcFS and GCCSDK GCC 4.7.4 Release 2, the test case still doesn't work
properly, but I do at least now get the same output whether I redirect the
output or not. Here's the difference compared to !SparkFS:

*diff SparkFS_output ArcFS_output
11,13c11,13
< sprites.b9b -1
< spritet.b9b -1
< spriteu.b9b -1
---
> sprites.b9 -1
> spritet.b9 -1
> spriteu.b9 -1
35c35
< textk.b9b -1
---
> textk.b9Q -1

I hadn't noticed the truncation to 10 characters before (I suspect it was
there, but I didn't have the !SparkFS output to 'diff' against, so was doing it
by eye). Maybe this is more of a !ArcFS problem, than a gcc one?

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 228] SUL 1.12: system()/exec*() ignoring aliases of existing non-module commands.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=228

Duncan Moore <duncan.moore@gmx.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |duncan.moore@gmx.com

--- Comment #2 from Duncan Moore <duncan.moore@gmx.com> 2015-11-27 03:45:25 PST ---
Update: This is still an issue with GCCSDK GCC 4.7.4 Release 2, and
ShareUnixLibrary 1.14.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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: netsurf: branch master updated. release/3.3-531-gd7907bf

On Wed, Nov 25, 2015 at 00:12:06 +0000, NetSurf Browser Project wrote:
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=4ad94124a693528f2ac47a9b4b2e12880586aedf
> commit 4ad94124a693528f2ac47a9b4b2e12880586aedf
> Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Skip invalid commandline args instead of aborting
>
> diff --git a/utils/nsoption.c b/utils/nsoption.c
> index ccdd23a..c83f779 100644
> --- a/utils/nsoption.c
> +++ b/utils/nsoption.c
> @@ -734,8 +734,10 @@ nsoption_commandline(int *pargc, char **argv, struct nsoption_s *opts)
>
> /* check we have an option */
> /* option must start -- and be as long as the shortest option*/
> - if ((arglen < (2+5) ) || (arg[0] != '-') || (arg[1] != '-'))
> - break;
> + if ((arglen < (2+5) ) || (arg[0] != '-') || (arg[1] != '-')) {
> + idx++;
> + continue;
> + }
>
> arg += 2; /* skip -- */

This seems odd Chris.

Instead of stopping consumption of arguments on the first non-configuration
argument, it instead ends up swallowing the entire commandline rendering the
rest of commandline processing worthless.

Could you either fix this so that you get your desired behaviour while not
breaking processing for the rest of us; or else revert the change?

Previously the expectation was:

nsexecutable [nsoption arguments] [frontend specific arguments] [url to launch with]

Now we have:

nsexecutable [nsoption arguments] [anything else is ignored blithely]

Thanks,

Daniel.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

[gccsdk] autobuilder and vfp

There now seems to be a few programs in the autobuilder that

would benefit from VFP versions being made available for the

newer machines that can use it.

 

We still need the non-VFP versions for the large number of

people using old RISC OS kit or emulators.

 

Has anybody any ideas on what we can do to allow this?

 

My initial thought was a new AB_VFP flag to specify the build

would generate a VFP version. Then we would need to run the

autobuilder twice, once for each version.

 

I don't know what's involved to configure something for VFP to

know if that is a sensible suggestion.

 

The second way would be to have a separate item for the

VFP version in the autobuilder.

 

Once that has been determined it needs to be decided how it

is packaged for PackMan and the website.

 

I don't think there is a problem with shared libraries here as

the are installed to different locations and can stand beside

the non VFP versions. But they may need a different package

name so they can be selected as well.

 

For the main programs, my initial thought would be to give

them a different zip name, but keep that package name the

same and add a flag to the package control record to say

it's for VFP machines.

 

Then the flag can either be used to generate an autobuilder-vfp

list or (probably better) PackMan could use the flag and select

the VFP version on machines that have VFP.

 

Anyone have any thoughts or suggestions?

 

Regards,

Alan

 

Slightly odd behaviour #3225

Double clicking on an HTML icon now only loads NetSurf. A further double
click is now needed to load the HTML file. Previously, a single double
click on the file icon was all that was needed to load the file into
NerSurf.

Telecity in yet another fail

This was on El Reg a little while ago:

http://www.theregister.co.uk/2015/11/25/telecity_fix_fails_again/

Dave

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager

Re: Can't leave feedback on eBay

In message <f929c72755.harriet@blueyonder.co.uk>
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:

> On 23 Nov 2015 as I do recall,
> Fred Bambrough wrote:
>
> > In message <4286062755.harriet@blueyonder.co.uk>
> > Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> >
> > > I've received an item from an eBay seller that I'm very pleased
> > > with, and would like to leave feedback, but I can't find a way to do
> > > it any more.
> [snip]
>
>
> > I've just tried with Netsurf (I usually use Safari). It doesn't work
> > unless Ebay has a simpler layout route I missed. You should be able to
> > click on 'My eBay' at the top right of the homepage to get a list of
> > purchased items with buttons for feedback. All you get is the list
> > that should be to the left of your purchased items.
> >
> Yes, that's all I got - changed since last time I looked. :-(
>

They do that.

Re: Can't leave feedback on eBay

On 23 Nov 2015 as I do recall,
Fred Bambrough wrote:

> In message <4286062755.harriet@blueyonder.co.uk>
> Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
>
> > I've received an item from an eBay seller that I'm very pleased with,
> > and would like to leave feedback, but I can't find a way to do it any
> > more.
[snip]


> I've just tried with Netsurf (I usually use Safari). It doesn't work
> unless Ebay has a simpler layout route I missed. You should be able to
> click on 'My eBay' at the top right of the homepage to get a list of
> purchased items with buttons for feedback. All you get is the list that
> should be to the left of your purchased items.
>
Yes, that's all I got - changed since last time I looked. :-(

--
Harriet Bazley == Loyaulte me lie ==

"An American is a man with two arms and four wheels".

[gccsdk] [Bug 261] bug

http://www.riscos.info/bugzilla3/show_bug.cgi?id=261

David Spinelli <joanietrdickmannjhg3101@yahoo.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from David Spinelli <joanietrdickmannjhg3101@yahoo.com> 2015-11-23 16:45:31 PST ---
fixed

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 261] New: bug

http://www.riscos.info/bugzilla3/show_bug.cgi?id=261

Summary: bug
Product: Firefox
Version: unspecified
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: feature request
Priority: P1
Component: Crash or lock up
AssignedTo: peter@chocky.org
ReportedBy: joanietrdickmannjhg3101@yahoo.com
Estimated Hours: 0.0


Created attachment 85
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=85
file

bug

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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: Can't leave feedback on eBay

In message <4286062755.harriet@blueyonder.co.uk>
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:

> I've received an item from an eBay seller that I'm very pleased with,
> and would like to leave feedback, but I can't find a way to do it any
> more. I can find the original item page (I bought one of a batch), but
> there doesn't seem to be a 'leave feedback' link on that. I can't find
> a list of things I bought, let alone a list of things awaiting feedback
> - do I have to wait until eBay eventually sends me a reminder with a
> direct link? (And will even that work any more? If I use the 'View
> Order Details' link on the e-mail I was sent to confirm dispatch, the
> resulting page is blank save for the header.)
>

I've just tried with Netsurf (I usually use Safari). It doesn't work
unless Ebay has a simpler layout route I missed. You should be able to
click on 'My eBay' at the top right of the homepage to get a list of
purchased items with buttons for feedback. All you get is the list that
should be to the left of your purchased items.

Download window Fixed - Dev 3222

Thanks to all who worked on this. In fact you have future proofed it
for when the GigaByte downloads arrive :))

--
|)    [
|)ryn [vans mail to - BrynEvans@bryork.freeuk.com

Re: Not an important bug.

In a mad moment - Dave Higton mumbled :

> In message <ns0b9e6f2155.Bryn@yo.rk>
> Bryn Evans <netsurf@bryork.freeuk.com> wrote:

>>In a mad moment - Dave Higton mumbled :
>>
>>> In message <ns0a4de91f55.Bryn@yo.rk>
>>> Bryn Evans <netsurf@bryork.freeuk.com> wrote:
>>
>>
>>>> Since the arrival of the mapping App " !RiscOSM " downloads in the order
>>>> of 700Mb are frequent and it is currently not possible to read the the
>>>> number of hundreds to go. Adding an extra two digit space, OR changing the
>>>> Message " remaining " to " remains " would do it.
>>
>>> Please raise a Mantis issue for it, which will ensure it gets tracked
>>> and dealt with. I see no reason why we shouldn't fix this.
>>
>>> I want it in the tracker because we're knee deep in another issue at
>>> the moment, and I don't want your very reasonable request to get
>>> forgotten due to pressure of other stuff.
>>
>>Thanks - I logged it yesterday

> I've uploaded a fix. We just need to wait for it to work its way
> into a new build.

> Thanks for reporting the issue!

That was quick Thank you, I will try the latest build as soon as the
opportunity arises.

--
|)    [
|)ryn [vans mail to - BrynEvans@bryork.freeuk.com

Can't leave feedback on eBay

I've received an item from an eBay seller that I'm very pleased with, and
would like to leave feedback, but I can't find a way to do it any more. I
can find the original item page (I bought one of a batch), but there doesn't
seem to be a 'leave feedback' link on that. I can't find a list of things
I bought, let alone a list of things awaiting feedback - do I have to wait
until eBay eventually sends me a reminder with a direct link?
(And will even that work any more? If I use the 'View Order Details' link
on the e-mail I was sent to confirm dispatch, the resulting page is blank
save for the header.)

--
Harriet Bazley == Loyaulte me lie ==

Positive: Mistaken at the top of one's voice.

Re: Suggestion for priority of work

Dave Higton wrote

> One of the things that NetSurf users most miss, it seems to me, is to
> be able to configure small appliances via their web pages that rely
> heavily on Javascript. Examples are wifi clients and other network-
> related stuff. We keep seeing threads on newsgroups and mailing
> lists that always have to say "but you'll need Linux or Windows to
> set it up".

> How much work would be involved in supporting them, and is there other
> work that has a higher priority?

It would be convenient to be able to configure my Draytek
vigor2830n-plus router from NS.

I was able to use NetSurf for my previous router a Draytek Vigor2600G
with no problem. With the current one I can't get beyond login because
the submit for the login form is javascript dependent.

John


--
John Rickman - http://rickman.orpheusweb.co.uk/lynx

[gccsdk] [Bug 253] GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget() failure

http://www.riscos.info/bugzilla3/show_bug.cgi?id=253

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 255] GCC 4.7.4 Rel 1 Dev 2014-05-29: infinite loop with level 2 optimisation

http://www.riscos.info/bugzilla3/show_bug.cgi?id=255

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 15:04:42 PST ---
> With this program:
>
> #include <stdio.h>
> int main(void) {
> int i;
> for (i=0;i<6;++i)
> printf("%i\n",i);
> return 0;
> }
>
> I get an infinite loop with -O2 optimisation:

Has anything changed regarding this in GCCSDK 4.7.4 release 2? Do you have a
program binary that exhibits this?

Thanks
Theo

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 240] fork() & prog$heap failure

http://www.riscos.info/bugzilla3/show_bug.cgi?id=240

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 228] SUL 1.12: system()/exec*() ignoring aliases of existing non-module commands.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=228

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 236] GCC 4.1.2 Rel 2 Dev 2012-05-01: fork/execvp/dup2 redirection problem

http://www.riscos.info/bugzilla3/show_bug.cgi?id=236

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |leenoar@sky.com

--- Comment #2 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 14:59:27 PST ---
I'm just doing some housekeeping on old bugs. Is this still an outstanding
issue for you? Can you check if the recent GCC 4.7.4 release 2 is still
affected?

Thanks
Theo

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 257] GCC 4.7.4 fails when compling whetstone.c

http://www.riscos.info/bugzilla3/show_bug.cgi?id=257

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |leenoar@sky.com

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 237] Ampersands in command line arguments.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=237

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 259] DigitalRenderer module is reset on program exit

http://www.riscos.info/bugzilla3/show_bug.cgi?id=259

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |leenoar@sky.com

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 168] system() and '>' redirection conflict

http://www.riscos.info/bugzilla3/show_bug.cgi?id=168

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
CC| |bugzilla@markettos.org.uk
Resolution| |FIXED

--- Comment #6 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 14:55:31 PST ---
Thanks for reporting back that this bug is now resolved.

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 235] GCC 4.1.2 Rel 2 Dev 2012-05-01: Problem reading Archive image files.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=235

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

--- Comment #7 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 14:54:07 PST ---
(In reply to comment #0)
> GCCSDK GCC 4.1.2 Release 2 Development 2012-05-01
> SharedUnixLibrary 1.12
> VRPC RISC OS 4.39
> ArcFS version 0.75 M.Smith 15th March 2003
>
> Reading some Archive image files via !ArcFS is giving problems. The problems
> are repeatable. It seems to occur when (but not always) there are >32 files in
> a directory. Non-GCCSDK programs can read the image files properly. I only have
> the read-only version of !ArcFS so haven't been able to experiment too much.

I'm doing some housekeeping on old bugs. Is this still an outstanding issue for
you? Can you check if the recent GCC 4.7.4 release 2 is still affected?

Thanks
Theo

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 235] GCC 4.1.2 Rel 2 Dev 2012-05-01: Problem reading Archive image files.

http://www.riscos.info/bugzilla3/show_bug.cgi?id=235

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--- Comment #6 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 14:53:08 PST ---
(In reply to comment #0)
> GCCSDK GCC 4.1.2 Release 2 Development 2012-05-01
> SharedUnixLibrary 1.12
> VRPC RISC OS 4.39
> ArcFS version 0.75 M.Smith 15th March 2003
>
> Reading some Archive image files via !ArcFS is giving problems. The problems
> are repeatable. It seems to occur when (but not always) there are >32 files in
> a directory. Non-GCCSDK programs can read the image files properly. I only have
> the read-only version of !ArcFS so haven't been able to experiment too much.

I'm just doing some housekeeping on old bugs. Is this still an outstanding
issue for you? Can you check if the recent GCC 4.7.4 release 2 is still
affected?

Thanks
Theo
[

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 250] GCC 4.7.4 Rel 1 Dev 2014-01-08: sqrt function

http://www.riscos.info/bugzilla3/show_bug.cgi?id=250

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |gccsdk-bugzilla@markettos.o
| |rg.uk

--- Comment #9 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 14:51:49 PST ---
(In reply to comment #0)
> 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
>
> #include <stdio.h>
> #include <math.h>
> int main(void) {
> printf("%f\n",sqrt(2.0));
> return 0;
> }
>
> This is what I get:
>
> *gcc sqrt.c
> *a/out
> 1.437500
>
> This is what I should get:
> 1.414214

I'm just doing some housekeeping on old bugs. Is this still an outstanding
issue for you? Can you check if the recent GCC 4.7.4 release 2 is still
affected?

Thanks
Theo

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 245] SWI &4C4152 not know

http://www.riscos.info/bugzilla3/show_bug.cgi?id=245

--- Comment #3 from Theo Markettos <bugzilla@markettos.org.uk> 2015-11-22 14:49:33 PST ---
(In reply to comment #2)
> I am using the RPM Emu V0.8.9, with a WIMP Slot of 6044K.
>
> The RISC OS version is 5.19 and the GCC version is 4.1.2
>
> I use Sourcery to compile my projects (1.15), but will happen with the
> examples.
>
> It does happen when activating VRAM in the emulator, and once it starts will
> never succeed again until RISC OS is reset.

I'm just doing some housekeeping on old bugs. Is this still an outstanding
issue for you? Can you check if the recent GCC 4.7.4 release 2 is still
affected?

Thanks
Theo

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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] [Bug 245] SWI &4C4152 not know

http://www.riscos.info/bugzilla3/show_bug.cgi?id=245

Theo Markettos <bugzilla@markettos.org.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla@markettos.org.uk
AssignedTo|John.Tytgat@aaug.net |leenoar@sky.com

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
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

Suggestion for priority of work

One of the things that NetSurf users most miss, it seems to me, is to
be able to configure small appliances via their web pages that rely
heavily on Javascript. Examples are wifi clients and other network-
related stuff. We keep seeing threads on newsgroups and mailing
lists that always have to say "but you'll need Linux or Windows to
set it up".

How much work would be involved in supporting them, and is there other
work that has a higher priority?

As you see, it's a naive question.

Dave

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager

Re: Not an important bug.

In message <a71f372655.DaveMeUK@my.inbox.com>
Dave Higton <dave@davehigton.me.uk> wrote:

>In message <ns0b9e6f2155.Bryn@yo.rk>
> Bryn Evans <netsurf@bryork.freeuk.com> wrote:
>
>>In a mad moment - Dave Higton mumbled :
>>
>>> In message <ns0a4de91f55.Bryn@yo.rk>
>>> Bryn Evans <netsurf@bryork.freeuk.com> wrote:
>>
>>
>>>> Since the arrival of the mapping App " !RiscOSM " downloads in the order
>>>> of 700Mb are frequent and it is currently not possible to read the the
>>>> number of hundreds to go. Adding an extra two digit space, OR changing the
>>>> Message " remaining " to " remains " would do it.
>>
>>> Please raise a Mantis issue for it, which will ensure it gets tracked
>>> and dealt with. I see no reason why we shouldn't fix this.
>>
>>> I want it in the tracker because we're knee deep in another issue at
>>> the moment, and I don't want your very reasonable request to get
>>> forgotten due to pressure of other stuff.
>>
>>Thanks - I logged it yesterday
>
>I've uploaded a fix. We just need to wait for it to work its way
>into a new build.
>
>Thanks for reporting the issue!

It's in CI#3181 onwards.

Dave

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium

Re: Bug 2388

In message <8101b62655.DaveMeUK@my.inbox.com>
Dave Higton <dave@davehigton.me.uk> wrote:

>My fix for issue 2388 was rejected, apparently without looking at
>what I submitted. I /did/ submit the text source files for the
>templates.
>
>Please have another look!

The fix is in CI#3181.

Dave

____________________________________________________________
Share photos & screenshots in seconds...
TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if1
Works in all emails, instant messengers, blogs, forums and social networks.

Re: [gccsdk] libpng12-0

On Sun, Nov 22, 2015 at 07:07:20PM +0000, Chris Gransden wrote:
> The autobuilder has been updated with the above patch omitted. libpng12-0
> should build ok now.

I can confirm that Jenkins built it fine:
http://ci.riscos.info/job/packages/job/libpng12-0/

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

Bug 2388

My fix for issue 2388 was rejected, apparently without looking at
what I submitted. I /did/ submit the text source files for the
templates.

Please have another look!

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Re: [gccsdk] g++

On 22/11/15 15:55, Gavin Wraith wrote:
>> Note that CXX is the g++ compiler, which is why changing CC had no
>> effect.
>
> Why is it using g++ and not cc? There is a change from Lua 5.3.1
> to 5.3.2; namely a new header file lprefix.h containing

[snip]

> Could this be responsible?

No, a new header wouldn't alter the compiler used. Usually, it's the
source file extension that determines the compiler, but here all files
are .c and the makefile contains no C++ bits. So your question
"Why is it using g++ and not cc?" is a good one.

>> So you'd want something like:
>>
>> CXXFLAGS= -O2 -Wall -Wextra $(SYSCXXFLAGS) $(MYCXXFLAGS)
>> SYSCXXFLAGS= -mfpu=vfp -DRISCOS
>
> OK, I inserted this in the makefile, and the object files now
> have flag 0x600. However, compilation stopped with this error:
>
> liblua(ldo.o): In function `luaD_throw(lua_State*, int)':
> ldo.c:(.text+0x104): undefined reference to `__cxa_allocate_exception'
> ldo.c:(.text+0x118): undefined reference to `__cxa_throw'
> liblua(ldo.o): In function `luaD_rawrunprotected(lua_State*, void (*)(lua_State*, void*), void*)':
> ldo.c:(.text+0x388): undefined reference to `__cxa_begin_catch'
> ldo.c:(.text+0x39c): undefined reference to `__cxa_end_catch'
> liblua(ldo.o):(.ARM.extab+0x30): undefined reference to `__gxx_personality_v0'
> liblua(ldo.o):(.rodata._ZTIP11lua_longjmp[typeinfo for lua_longjmp*]+0x0): undefined reference to `vtable for __cxxabiv1::__pointer_type_info'
> liblua(ldo.o):(.rodata._ZTI11lua_longjmp[typeinfo for lua_longjmp]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
> collect2: error: ld returned 1 exit status
> makefile:67: recipe for target 'lua6' failed
> make: *** [lua6] Error 1
>
> This is evidently to do with longjump behaviour. I wonder if I can get the
> previous behaviour by setting LUA_USE_C89 or something like that? Is
> there a way of getting cc as the compiler instead of g++?

Probably better to forget what I said about adding CXXFLAGS, etc. It's
linking with gcc rather than g++, hence the missing symbols (no
libstdc++) and that's probably the way is supposed to be.

What you have to figure out is why it's using g++ for that file instead
of gcc. TBH, I can't see anything in the makefile that would explain it.

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

Re: [gccsdk] libpng12-0

In article <5651E540.5040200@macpcrepair.co.uk>,
John Ballance <jwb@macpcrepair.co.uk> wrote:
> Hi

> Building today shows libpng has changed upstream. In consequence one of
> the patches in

> libpng-1.2.43-apng.p needs omitting as code it patches isn't there
> like that any more:

> @@ -2159,8 +2252,8 @@
> #ifndef PNG_WRITE_WEIGHTED_FILTER_SUPPORTED
> if (png_ptr->row_number == 0 && filter_to_do == PNG_ALL_FILTERS)
> {
> - /* These will never be selected so we need not test them. */
> - filter_to_do &= ~(PNG_FILTER_UP | PNG_FILTER_PAETH);
> + /* These use previous row */
> + filter_to_do &= ~(PNG_FILTER_UP | PNG_FILTER_AVG | PNG_FILTER_PAETH);
> }
>

[gccsdk] g++

> Note that CXX is the g++ compiler, which is why changing CC had no
> effect.

Why is it using g++ and not cc? There is a change from Lua 5.3.1
to 5.3.2; namely a new header file lprefix.h containing

#if !defined(LUA_USE_C89) /* { */

#if !defined(_XOPEN_SOURCE)
#define _XOPEN_SOURCE 600
#elif _XOPEN_SOURCE == 0
#undef _XOPEN_SOURCE /* use -D_XOPEN_SOURCE=0 to undefine it */

[gccsdk] libpng12-0

Hi

Building today shows libpng has changed upstream. In consequence one of the patches in

 libpng-1.2.43-apng.p needs omitting as code it patches isn't there like that any more:

@@ -2159,8 +2252,8 @@
 #ifndef PNG_WRITE_WEIGHTED_FILTER_SUPPORTED
   if (png_ptr->row_number == 0 && filter_to_do == PNG_ALL_FILTERS)
   {
-      /* These will never be selected so we need not test them. */
-      filter_to_do &= ~(PNG_FILTER_UP | PNG_FILTER_PAETH);
+      /* These use previous row */
+      filter_to_do &= ~(PNG_FILTER_UP | PNG_FILTER_AVG | PNG_FILTER_PAETH);
   }
 

Re: [gccsdk] readelf

On 22/11/15 14:22, Gavin Wraith wrote:
> In message <5651B6B5.5000508@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> It seems that SYSCFLAGS is not referenced when the compile rule
>> in the makefile is invoked. Is it possible that the variable
>> name was changed in the update?
>> Perhaps you should post the whole makefile so we can try and
>> spot what's going on.
>
> I tried moving the -mfpu=vfp -mtune=cortex-a7 options from
> SYSCFLAGS to MYCFLAGS. No success. I even tried moving them
> to CC so that the makefile had
> CC= gcc -std=gnu99 -mfpu=vfp -mtune=cortex-a7
> Still no success.

lapi.c is built with g++ though, so you would have to add -mfpu=vfp
to the CXXFLAGS as well.
So you'd want something like:

CXXFLAGS= -O2 -Wall -Wextra $(SYSCXXFLAGS) $(MYCXXFLAGS)
SYSCXXFLAGS= -mfpu=vfp -DRISCOS

Note that CXX is the g++ compiler, which is why changing CC had no
effect.

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

Re: [gccsdk] readelf

In message <5651B6B5.5000508@sky.com>
Lee Noar <leenoar@sky.com> wrote:

>It seems that SYSCFLAGS is not referenced when the compile rule
>in the makefile is invoked. Is it possible that the variable
>name was changed in the update?
>Perhaps you should post the whole makefile so we can try and
>spot what's going on.

I tried moving the -mfpu=vfp -mtune=cortex-a7 options from
SYSCFLAGS to MYCFLAGS. No success. I even tried moving them
to CC so that the makefile had
CC= gcc -std=gnu99 -mfpu=vfp -mtune=cortex-a7
Still no success.

Here is the whole makefile:

# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT =======================

# Your platform. See PLATS for possible values.
PLAT= generic

CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= $(SYSLIBS) $(MYLIBS)

AR= ar rcu
RANLIB= ranlib
RM= rm -f

SYSCFLAGS= -mfpu=vfp -mtune=cortex-a7
SYSLDFLAGS=
SYSLIBS= -ldl

MYCFLAGS= -DRISCOS -v
MYLDFLAGS=
MYLIBS=
MYOBJS=

# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE =======

PLATS= aix bsd c89 freebsd generic linux macosx mingw posix solaris

LUA_A= liblua
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o \
lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o \
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o \
lmathlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o loadlib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)

LUA_T= lua6
LUA_O= lua.o

LUAC_T= luac6
LUAC_O= luac.o

ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)

# Targets start here.
default: $(PLAT)

all: $(ALL_T)

o: $(ALL_O)

a: $(ALL_A)

$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@

$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(LUA_O) -Wl,-E $(LUA_A) $(LIBS)

$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(LUAC_O) -Wl,-E $(LUA_A) $(LIBS)

clean:
$(RM) $(ALL_T) $(ALL_O)

depend:
@$(CC) $(CFLAGS) -MM l*.c

echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(SYSLDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"

# Convenience targets for popular platforms
ALL= all

none:
@echo "Please do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"

aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN" SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"

bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN" SYSLIBS="-Wl,-E"

c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo ''


freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -lreadline"

generic: $(ALL)
@echo "Starting ..."

linux:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl -lreadline"

macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX" SYSLIBS="-lreadline" CC=cc

mingw:
$(MAKE) "LUA_A=lua53.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe

posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"

solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN -D_REENTRANT" SYSLIBS="-ldl"

# list targets that do not create files (but not all makes understand .PHONY)
.PHONY: all $(PLATS) default o a clean depend echo none

# DO NOT DELETE

lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
# lbitlib.o: lbitlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h lfunc.h lobject.h llimits.h \
lgc.h lstate.h ltm.h lzio.h lmem.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h lobject.h llimits.h \
lstate.h ltm.h lzio.h lmem.h lundump.h ldebug.h lopcodes.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h

# (end of Makefile)

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

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