<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 25, 2018, 8:07 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25/04/2018 17:57, Sebastian Huber wrote:<br>
> On 25/04/18 09:07, <a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a> wrote:<br>
>> Failures Report<br>
>> ===============<br>
>> 1 debug epiphany/epiphany_sim build:<br>
>> configure: /home/joel/rtems-work/rtems/configure --target=epiphany-\<br>
>> rtems5 --enable-rtemsbsp=epiphany_sim --prefix=/home/joel/rtems-\<br>
>> work/bsps --enable-debug<br>
>> error: cpukit/mghttpd/mongoose.c:674:1: internal compiler error: in<br>
>> epiphany_expand_prologue, at config/epiphany/epiphany.c:1830<br>
> <br>
> Ok, the clue is that this is built with networking enabled. This is not visible<br>
> here under "configure: ...".<br>
<br>
Are the default states considered a valid configuration or should the BSP<br>
builder always list the options it controls? The list is:<br>
<br>
<a href="https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini#n155" rel="noreferrer noreferrer" target="_blank">https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini#n155</a><br>
<br>
and adding the `no-*` variant should resolve this.<br>
<br>
> This ICE is a known problem. I always build with<br>
> networking disabled on this platform.<br>
<br>
How do we manage this?<br>
<br>
1. Leave networking available as a configuration for this BSP and allow the<br>
error? I do not like this, it is sloppy.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">In some cases, we silently disable code for architectures know to be broken or not supported.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Have configure raise an error on this arch if networking is enabled?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Possible. Tester still has to avoid the option.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Remove the option and always enable? Can this work with libbsd now the<br>
headers have moved?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think it might work but i don't want to do it. I prefer the view that the user is building a kernel. And then adds on their choice of a network stack. I would like that to be the new stack, the Legacy stack, or ltwp.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4. Remove the networking stack to a separate repo and move in the examples-v2 tests?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. Ideally and you mean network-demos.</div><div dir="auto"><br></div><div dir="auto">Also have to include drivers from BSPs</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
5. Something else?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">A separate Repository is the best long-term solution. It allows us to start deemphasizing the networking stack in the tree itself.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
<br>
<br>
<br>
<br>
</blockquote></div></div></div>