Re: RTEMS Bootstrap Error

2016-04-17 Thread Chris Johns 

On 18/04/2016 14:03, Olufowobi, Habeeb wrote:


Thanks so much for your response. That works and I have build successfully.



Did sb-bootstrap print an error message that let you fix the issue?

I am not sure if this is a suitable fix to push.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Bootstrap Error

2016-04-17 Thread Olufowobi, Habeeb 
Hi Chris,

Thanks so much for your response. That works and I have build successfully.

Regards,
Habeeb

On Sun, Apr 17, 2016 at 6:19 PM, Chris Johns  wrote:

> On 17/04/2016 14:13, Olufowobi, Habeeb wrote:
>
>>
>> I am trying to build RTEMS for ARM with the recent toolchain but I have
>> been receiving the below error when I run ./bootstrap. I think there is
>> some error in the bootstrap file.
>>
>> I have tried running the ./bootstrap script located in rtems, instead of
>> using sb-bootstrap but doesn't help.
>>
>
> What did ./bootstrap give as an error?
>
> Any ideas on how I can fix this?
>>
>> RTEMS Source Builder - RTEMS Bootstrap, 4.12 (6843e47ce339)
>>1/139: autoreconf: configure.ac 
>>2/139: autoreconf: cpukit/configure.ac 
>> Traceback (most recent call last):
>>File
>> "/home/dipupo/development/rtems/rsb/source-builder/sb-bootstrap", line
>> 28, in 
>>  bootstrap.run(sys.argv)
>>File
>> "/home/dipupo/development/rtems/rsb/source-builder/sb/bootstrap.py",
>> line 279, in run
>>  generate(topdir, opts.jobs > >(opts.defaults['_ncpus']))
>>File
>> "/home/dipupo/development/rtems/rsb/source-builder/sb/bootstrap.py",
>> line 188, in generate
>>  ac.post_process()
>>File
>> "/home/dipupo/development/rtems/rsb/source-builder/sb/bootstrap.py",
>> line 158, in post_process
>>  self.command.reraise()
>>File
>> "/home/dipupo/development/rtems/rsb/source-builder/sb/bootstrap.py",
>> line 119, in reraise
>>  raise self.result[0](self.result[1]).with_traceback(self.result[2])
>>File "/home/dipupo/development/rtems/rsb/source-builder/sb/error.py",
>> line 36, in __init__
>>  self.set_output('error: ' + what)
>>
>
> Can you try:
>
>   self.set_output('error: ' + str(what))
>
> and if that does not work:
>
>  self.set_output('error: ' + type(what))
>
> And let me know what the output it.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Libbsd update.

2016-04-17 Thread Chris Johns 
Hi

I have push some waf related changes libbsd. Please make sure you update the 
`rtems_waf` submodule after updating your local repo. A status indicating an 
update is needed is:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   rtems_waf (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

The command to update is:

$ git submodule update rtems_waf
Submodule path 'rtems_waf': checked out 
'9343280a61f0c0736e237168297b9d1490a66255

Note: make sure you use the exact submodule update command or you may end up 
cloning the FreeBSD source tree. If that happens just press ^C.

I suggest you do a `waf distclean` and configure again after updating. Also I 
recommend using waf 1.8.20.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: moxie C++ link error

2016-04-17 Thread Chris Johns 

On 18/04/2016 10:52, Joel Sherrill wrote:


Simulator reports an illegal instruction.


OK.


Gdb is alive but gives a Python error on backtrace.


Is this something in the unwinder in gdb which may be using Python  
https://sourceware.org/gdb/wiki/UnwinderAPI ?



I think it is a target BSP issue. I lean to linking at all is an
improvement. Perhaps a linker script issue past this. Better to commit
so we can move to an execution rather than linking issue.


Yes I agree. It improves the tier status of the target and so the arch.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: moxie C++ link error

2016-04-17 Thread Joel Sherrill 
On Apr 17, 2016 7:28 PM, "Chris Johns"  wrote:
>
> On 18/04/2016 10:18, Joel Sherrill wrote:
>>
>>
>> I have a fix to gcc and the bsp which lets C++ programs link but
>> both cdtest and cxx_iostream core dump now.
>
>
> Where do they core dump? Does the simulator code dump?

Simulator reports an illegal instruction. Gdb is alive but gives a Python
error on backtrace.

I think it is a target BSP issue. I lean to linking at all is an
improvement. Perhaps a linker script issue past this. Better to commit so
we can move to an execution rather than linking issue.

> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: moxie C++ link error

2016-04-17 Thread Chris Johns 

On 18/04/2016 10:18, Joel Sherrill wrote:


I have a fix to gcc and the bsp which lets C++ programs link but
both cdtest and cxx_iostream core dump now.


Where do they core dump? Does the simulator code dump?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

moxie C++ link error

2016-04-17 Thread Joel Sherrill 
Hi

I have a fix to gcc and the bsp which lets C++ programs link but
both cdtest and cxx_iostream core dump now.

Should I commit them and then let's work on the core dump?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RSB Git modified status

2016-04-17 Thread Chris Johns 

Hi,

At the moment the RSB says untracked files in a git repo is modified.

Is this valid or this is a distraction? For example if I have 'x' as a 
file in the repo it is seen as untracked and so modified and nothing in 
the RSB has been changed.


I am currently leaning to not modified.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd errors with the latest tools ...

2016-04-17 Thread Chris Johns 

On 15/04/2016 22:50, Joel Sherrill wrote:


Jeff and I both have built rtems-libbsd with the latest RSB tools for
i386 and
didn't see any issues.  Chris.. you got me through a waf submodule update
yesterday and it built fine after that.


I was on 4.11 and had not noticed.

I am on master now and cleaning up the build scripts generation. I am:

1. Finish moving the python code to Python2 and Python3.
2. Adding an RTEMS version number to libbsd.py and adding support to
rtems_waf to use this.
3. Removing makefile support and removing the Makefile.
4. Adding support to detect if CFLAGS, CC or other environment variables 
are set in rtems_waf. At the moment I will just raise a warning. Some 
variables can cause unexpected behaviour by overriding what rtems_waf 
does but there maybe a cases where this is useful.

5. Building on Windows.

I am testing with waf-1.8.20 (14c787c991e1d9badd9d302bc9eaa060e9d4b03c)


All I can say that I expected issues due to the feature guard changes and
as soon as Sebastian's patch set is in and there is a newlib snapshot, we
need to bump the tools again.

In the mean time, do we want the RSB to apply that patch?


Which patch is this?


We also have the crt0.c one.


The crt0.o one is in the RSB.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel