Fw: Atari builds

Hi guys,

although I don't use Netsurf and have no time to dig in, just out of curiosity, what do you mean by this:

On 06/02/2017 12:25, Vincent Sanders wrote:

> atari - The atari frontend is built for m68k and coldfire variants  >          using a variant of the netsurf cross compliation  >          toolchain/sdk. No serious updates have been made to this  >          toolchain in some time and it has become a burden.  >  >         Unless this is addressed before the next developer weekend the  >          frontend will be disabled in the CI and subsequently code  >          removed.

There's nothing wrong with our gcc, it's still 4.6.4 and every other Atari software developer uses it. It's old, yes, but there are some technical obstacles to move beyond that version (although this may be no longer the case, see http://d-bug.mooo.com/beyondbrown/post/gcc-6/).

So what exactly burdens you? Is your new code failing to compile on 4.6.4?

Regards,

Miro

Hello,

did somebody recognize the E-Mail below? It was in reply to the wrong
subject.

Greets,
Ole


Beginn der weitergeleiteten Nachricht:

Datum: Tue, 28 Feb 2017 14:13:39 +1000
Von: Miro Kropáček <miro.kropacek@gmail.com>
An: netsurf-dev@netsurf-browser.org
Betreff: Atari builds


Hi guys,

although I don't use Netsurf and have no time to dig in, just out of
curiosity, what do you mean by this:

On 06/02/2017 12:25, Vincent Sanders wrote:

>* atari - The atari frontend is built for m68k and coldfire variants
*>* using a variant of the netsurf cross compliation
*>* toolchain/sdk. No serious updates have been made to this
*>* toolchain in some time and it has become a burden.
*>>* Unless this is addressed before the next developer weekend
the *>* frontend will be disabled in the CI and subsequently
code *>* removed.*

There's nothing wrong with our gcc, it's still 4.6.4 and every other
Atari software developer uses it. It's old, yes, but there are some
technical obstacles to move beyond that version (although this may be
no longer the case, see http://d-bug.mooo.com/beyondbrown/post/gcc-6/).

So what exactly burdens you? Is your new code failing to compile on
4.6.4?

Regards,
Miro

[gccsdk] riscos.info service downtime this weekend

Due to a mixup between myself and the hosting company, I need to move
riscos.info to a new server this weekend, at somewhat shorter notice than I
had planned. So please be advised that all services are likely to have a
period of downtime while the transition is in progress.

I'll put status on http://www.markettos.org.uk/riscos.info/ if you want to
follow progress.

For any issues please mail me direct, since the list might not be accessible
during the transition.

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] Raspberry Pi and VFP builds

Lee Noar wrote on 06 March 2017 14:10:

> On 06/03/17 13:00, alan buckley wrote:
> > I'm looking at creating Raspberry Pi and VFP specific builds and package
> > lists and have something working, but would just like to see if anyone
> > has any objections before I check it in.

> That all sounds reasonable to me.

> As far as shared libraries are concerned, there's not much point in
> building a VFP version if the library contains no FP; the dynamic
> linker will not fault a missing VFP version, but will instead look
> for a normal version.

 

If it's not needed I agree there is no point in adding a VFP version

to the package.

Is there an easy way to tell if a shared library contains no FP?

> However, static builds are more problematic as the static linker
> doesn't allow the mixing of VFP/non-VFP object files. So will this
> force us to build VFP versions of all libraries regardless of FP
> content?

 

Yes, I can't see anyway around this unless we decide all autobuilder

application will use shared libraries and don't bother with static

libraries. But that will probably upset too many people - or  am

I mistaken here?

My thoughts were to just build VFP libraries as they are needed

for now. i.e. if I build a VFP static application and that needs

several static libraries, I'd upload new versions of the libraries

with the static VFP versions as well.

Also as with all of this, if someone asks for a VFP build of a

particular library then that would be done.

 

Regards,

Alan

Re: [gccsdk] Raspberry Pi and VFP builds

On 06/03/17 13:00, alan buckley wrote:
> I'm looking at creating Raspberry Pi and VFP specific builds and package
> lists and have something working, but would just like to see if anyone
> has any objections before I check it in.

That all sounds reasonable to me.

As far as shared libraries are concerned, there's not much point in
building a VFP version if the library contains no FP; the dynamic
linker will not fault a missing VFP version, but will instead look
for a normal version.
However, static builds are more problematic as the static linker
doesn't allow the mixing of VFP/non-VFP object files. So will this
force us to build VFP versions of all libraries regardless of FP
content?

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

[gccsdk] Raspberry Pi and VFP builds

I'm looking at creating Raspberry Pi and VFP specific builds and package

lists and have something working, but would just like to see if anyone

has any objections before I check it in.

 

I've added a new Architecture field to the package control file and

command line arguments and variables to support it in the GCCSDK

build files.

 

The new architecture field can be "rpi", "vfp" or "arm" with "arm"

being the default if nothing is specified.

 

These will end up producing three package lists.

autobuilt – the current list (architecture arm)

autobuilt-vfp – vfp programs + any programs not in this list that are on the autobuilt list

autobuilt-rpi – Raspberry Pi programs  + any programs not in this list that are on the autobuilt-vfp list

 

The website will produce a page for each architecture variant.

 

I intend to follow Lee Noar's established practice for the builds.

This entails:

- BUILD_NORMAL and BUILD_VFP variable in setvars to allow only one variant to be

 built, normally both will be set to "yes" to build both variants.

- Shared libraries will ship with both arm and vfp versions of the libraries.

- Static libraries include a vfp subdirectory with the VFP version of the static library.

 

With applications, 2 or possibly 3 packages will be built, 1 for each architecture.

 

Regards,

Alan

 

 

 

 

 

Submit button

I was sent an online survey and the form looks ok but there
is no submit button:

Is this not supported ?

<div class="fb-footer fb-item-alignment-center" id="fb-submit-button-div"
style="min-height: 1px;">
<input class="fb-button-special fb_cond_applied" id="fb-submit-button"
style="background-image:url('survey/theme/default/images/btn_submit.png');" type="submit"
data-regular="" data-valign="top" value="Submit" />
</div>
<input name="fb_form_custom_html" type="hidden" />
<input name="fb_form_embedded" type="hidden" />
<input name="fb_js_enable" id="fb_js_enable" type="hidden" />
<input name="fb_url_embedded" id="fb_url_embedded" type="hidden" />
</form>


Peter

[Rpcemu] OS X Networking

Hello,
Has anyone had networking working with OS X 10.12?

I'm using the Caliston 0.8.14-Dev1 build, however it seems the NAT
scripts to enable networking no longer work due to changes in the
commands within OS X.

Kind Regards,
Rob.

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu