false positive, but a workaround...

[Gedare Bloom]

On Wed, Jun 24, 2015 at 11:44 AM, Ed Sutter
<ed.sutter at alcatel-lucent.com> wrote:
> 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)
>

zlib is fine we include it's source in RTEMS too.

I don't know about glib, but if it is in freebsd / has BSD headers it
should be ok.


> 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
>>>
>>>
>>>
>>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel