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