Re: Python problem
On Tue, Feb 9, 2016 at 1:58 AM, Joel Sherrill wrote: > This looks like the message gdb prints when the python development libraries > are not installed. Yes. It is a bad error message. Try this: > > https://docs.rtems.org/rsb/#_ubuntu > > --joel > > On Mon, Feb 8, 2016 at 10:35 AM, Gedare Bloom wrote: >> >> you might try ubuntu's community / support? >> >> On Mon, Feb 8, 2016 at 5:35 AM, punit vara wrote: >> > I am facing python problem since long time. I updated my system to >> > ubuntu 15.10 from 15.04 as I was facing python problem but eventually >> > I ended up with the same problem I came across before. >> > >> > Python -V shows python 2.7.10 >> > >> > But when Check error log it says >> > >> > checking for python... /usr/local/bin/python >> > checking for python2.7... no >> > configure: error: python is missing or unusable >> > Makefile:8643: recipe for target 'configure-gdb' failed >> > >> > When I try to do following >> > >> > $ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev >> > >> > In this I found out ubuntu is picking python2.7 instead of >> > python2.7-dev. It seems to me if anyhow I can force OS to pick >> > python2.7-dev then this problem can be solved But I don't know how to >> > do this.Can somebody please help regarding this? Any help would be >> > appreciated. >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > I already tried that Joel. I am facing the same problem one developer faced mentioned here in feedback. https://devel.rtems.org/wiki/GCI/Coding/HelloWorld for ubuntu 15.10 . I have to try ubuntu because I don't know exactly where I can force build-rep to build with python2.7-dev instead of python2.7 .For cent os someone already solved the problem here https://devel.rtems.org/ticket/2275. This is the only thing stopping me to contribute to RTEMS I hope I will soon find some solution. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Python problem
Hi, I was having the same problem yesterday and managed to find a fix by installing libpython2.7-dev: sudo apt-get install libpython2.7-dev Aun-Ali Zaidi ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Python problem
On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi wrote: > Hi, > > I was having the same problem yesterday and managed to find a fix by > installing libpython2.7-dev: > > sudo apt-get install libpython2.7-dev > > Aun-Ali Zaidi > Thanks Aun-Ali. I have tried but again I am getting same error. Because this package would get installed when you install python2.7-dev ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Python problem
On Tue, Feb 9, 2016 at 8:15 AM, punit vara wrote: > On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi wrote: > > Hi, > > > > I was having the same problem yesterday and managed to find a fix by > > installing libpython2.7-dev: > > > > sudo apt-get install libpython2.7-dev > > > > Aun-Ali Zaidi > > > > Thanks Aun-Ali. I have tried but again I am getting same error. > Because this package would get installed when you install > python2.7-dev > Can you look in the config.log for gdb where the failure occurred? Or even at the configure.in/ac script in its source. It is looking for a very specific file to link against and failing. yum have a "provides" subcommand to search for which package provides a specific file. Apt must have a similar capability. So you can figure out the file gdb needs to link and the corresponding package which includes it. --joel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC 2016: Call for Mentors
Potential GSoC Mentors, Please send me a brief email indicating your interest to be a mentor. I'm just looking for a quick head count. If there are particular projects that will interest you, then you may like to go to the https://devel.rtems.org/wiki/Developer/OpenProjects page to ensure the project has a linked description. We should also attempt to highlight/promote high-value, mentor-ready projects. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB Quick Start Distributing and Archiving?
Any particularly good reason for including the section "Distributing and Archiving A Build" [1] in the quick start? This seems to me to belong in its own section unrelated to a typical user's needs to just get a working tool chain. [1] https://docs.rtems.org/rsb/#_distributing_and_archiving_a_build Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2016: Call for Mentors
Gedare, I will be happy to be mentor if a suitable project gets picked. wkr, Thomas. - Ursprüngliche Mail - Von: "Gedare Bloom" An: us...@rtems.org, "rtems-de...@rtems.org" Gesendet: Dienstag, 9. Februar 2016 16:51:58 Betreff: GSOC 2016: Call for Mentors Potential GSoC Mentors, Please send me a brief email indicating your interest to be a mentor. I'm just looking for a quick head count. If there are particular projects that will interest you, then you may like to go to the https://devel.rtems.org/wiki/Developer/OpenProjects page to ensure the project has a linked description. We should also attempt to highlight/promote high-value, mentor-ready projects. Gedare ___ users mailing list us...@rtems.org http://lists.rtems.org/mailman/listinfo/users -- -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
x86_64 BSP as GSOC2016 project
Hi, I think this is early for this but I need to enquire if x86_64_BSP ( https://devel.rtems.org/wiki/Developer/Projects/Open/x86_64_BSP ) could be taken as a GSOC project this year. Regards, Saket Sinha ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP as GSOC2016 project
On Tue, Feb 9, 2016 at 12:08 PM, Saket Sinha wrote: > Hi, > > I think this is early for this but I need to enquire if x86_64_BSP ( > https://devel.rtems.org/wiki/Developer/Projects/Open/x86_64_BSP ) > could be taken as a GSOC project this year. > > Yes. Assuming you mean the x86_64 bit port and accompanying BSP. If you noticed my post yesterday, we have tripped across a new embedded PC without legacy PCI BIOS support. Beyond the obvious port, for the purposes of your effort, there are a couple of bugs and some modernization needed by the pc386 BSP which you will likely have to address. + PCI BIOS uses legacy support. Needs to support new and old for 32-bit and new only for 64 bit. + Better APIC support. pc386 uses legacy PIC and some LPIC for SMP. Probably Ok for both 32 and 64 bit to support APIC only. + i386 does not have Thread Local Support. Both should have it. + i386 has a ticket for SMP synchronization during context switch. The code does not use atomics. Should be fixed and x86_64 follow the correct pattern. Basically x86_64 should assume a modern (non-legacy) PC and pc386 needs updating to support newer systems. Common hardware platform so hopefully the software is standard. I was going to write this up as a "PC386 Modernization" Project but some of it makes sense as a side-effect of your project. That project idea also included killing AT bus NICs which you wouldn't have any reason to get near. You need a subtask list (e.g. todo list) and we need to help you flesh it out. I only hit a few non-obvious highlights. Does that help? > Regards, > Saket Sinha > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB Quick Start Distributing and Archiving?
On Tue, Feb 9, 2016 at 11:20 AM, Gedare Bloom wrote: > Any particularly good reason for including the section "Distributing > and Archiving A Build" [1] in the quick start? This seems to me to > belong in its own section unrelated to a typical user's needs to just > get a working tool chain. > > I think it is more common than you think. Many users are actually the "systems guy" in a group. They are responsible for providing the properly built BSP and tools in the group. This could be on a single server, a VM which is copied or pre-built tools. This is not a typical use case for us as developers or self-supporting students. > [1] https://docs.rtems.org/rsb/#_distributing_and_archiving_a_build > > Gedare > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP as GSOC2016 project
Hi Joel, Thanks for your inputs. On Wed, Feb 10, 2016 at 1:06 AM, Joel Sherrill wrote: > > > On Tue, Feb 9, 2016 at 12:08 PM, Saket Sinha > wrote: >> >> Hi, >> >> I think this is early for this but I need to enquire if x86_64_BSP ( >> https://devel.rtems.org/wiki/Developer/Projects/Open/x86_64_BSP ) >> could be taken as a GSOC project this year. >> > > Yes. Assuming you mean the x86_64 bit port and accompanying BSP. > > If you noticed my post yesterday, we have tripped across a new embedded PC > without legacy PCI BIOS support. > Could you provide the link. I am not able to locate it on mailing list or your blog. > Beyond the obvious port, for the purposes of your effort, there are > a couple of bugs and some modernization needed by the pc386 BSP which > you will likely have to address. > > + PCI BIOS uses legacy support. Needs to support new and old for 32-bit > and new only for 64 bit. > + Better APIC support. pc386 uses legacy PIC and some LPIC for SMP. > Probably Ok for both 32 and 64 bit to support APIC only. > + i386 does not have Thread Local Support. Both should have it. > + i386 has a ticket for SMP synchronization during context switch. > The code does not use atomics. Should be fixed and x86_64 follow the > correct pattern. > So now my question is that could these be solved on an emulator like qemu-x86, atleast for an initial POC ? I mean is a x86_64 hardware required for it( though I have a Minnowmax board.) > Basically x86_64 should assume a modern (non-legacy) PC and pc386 > needs updating to support newer systems. Common hardware platform > so hopefully the software is standard. > > I was going to write this up as a "PC386 Modernization" Project but some > of it makes sense as a side-effect of your project. That project idea also > included killing AT bus NICs which you wouldn't have any reason to get > near. > > You need a subtask list (e.g. todo list) and we need to help you flesh it > out. I only hit a few non-obvious highlights. > Let me know how to dig deeper on this. Looking at the code, right but than exactly what sections ? Regards, Saket Sinha ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
