false positive, but a workaround...
Ed Sutter
ed.sutter at alcatel-lucent.com
Wed Jun 24 15:44:23 UTC 2015
On 6/24/2015 10:57 AM, Joel Sherrill wrote:
>
>
> On 6/24/2015 9:40 AM, Ed Sutter wrote:
>> On 6/24/2015 10:41 AM, Jarielle Catbagan wrote:
>>> On Wed, Jun 24, 2015 at 6:10 AM, Ed Sutter
>>> <ed.sutter at alcatel-lucent.com> wrote:
>>>> Jarielle,
>>>> Well, it took almost 5 hours to build the tools last night.
>>>> Obviously I need
>>>> to upgrade the machine I have
>>>> this stuff running on at home!
>>>>
>>>> Anyway, this AM I was able to walk through what I thought I had
>>>> done in work
>>>> yesterday, and unfortunately due
>>>> to the fact that I am working in two different locations on two
>>>> different
>>>> machines (very very inefficient, but I'm
>>>> stuck in this mode at the moment); I fooled myself yesterday
>>>> thinking I had
>>>> stubbed out the __ctype_ptr__
>>>> declarations from docmd.c... Unfortunately, I didn't :-(, so what
>>>> I thought
>>>> built clean didn't.
>>>>
>>>> Anyway, I want to get you over this hump quickly 'cause this isn't
>>>> what I'd
>>>> like you to be working on. I really
>>>> want you to concentrate on beaglebone-specific stuff. That's the
>>>> important
>>>> stuff. Today I brought my beaglebone
>>>> board to the office, and I've got it working clean now using a
>>>> local set of
>>>> ctype.h and ctypetbl.c files as I had in
>>>> umon1.19. For now this is temporary, but it may turn out to be the
>>>> most
>>>> efficient way to get around this.
>>> These files would conflict with the licenses, am I right? Would a
>>> permanent solution be to implement a new local ctype.h?
>> Yep, that's exactly what I'm looking in to. :-)
>> Just wanted to get you rolling meanwhile...
>
> All code in newlib has appropriate licenses. It would be easier to
> selectively pull in files from there. We just need to be careful
> to ensure we know versions so updates can occur. But that's true
> for every place you could grab from.
>
> New software has new bugs.
>
> Do you happen to have a master list of what methods you used
> in the original source base?
Back when I originally gave Amar the tarball, I stripped out all that I
thought was questionable for RTEMS.
The two blocks of code that are not mine are zlib and glib.
zlib: I got this from Mark Adler decades ago (umon/main/zlib/README).
glib: subset of libc code i pulled in from a freebsd github
(umon/main/glib/getglib)
I have not updated them since original incorporation into uMon.
If necessary, I suppose I could update the glib files to be sourced from
newlib (lemme know).
Aside from a few other files that Cogent and a few other uMon users
contributed,
I wrote the rest.
>
>>>
>>>> So, attached to this are three files:
>>>> ctypetbl.c: put this under main/glib
>>>> ctype.h: put this under main/common
>>>> mydiffs: small list of diffs based on the tree after installing
>>>> your
>>>> initial set of 24 patches.
>>>> most of these changes you probably have, the
>>>> important
>>>> one is in main/make/common.make so that ctypetbl.c is built.
>>>>
>>>> If you can incorporate these changes into a tree that starts with
>>>> the master
>>>> and has your initial 24 patches applied,
>>>> you should be good to go. I know I should be using git to email you
>>>> patches, but I'm still trying to figure out how to
>>>> do that and I don't want you to be delayed by that.
>>>>
>>>> Does this make sense to you?
>>> Yes. Ok, I'll incorporate those files and I believe you are right
>>> that everything should be all set.
>>>
>>>> Ed
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> umon-devel mailing list
>>>> umon-devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>
>>
>
More information about the umon-devel
mailing list